Re: [O] Using allowframebreaks in org-beamer
Stephen J. Barr stev...@uw.edu writes: I agree with the less stuff part. The first pass in my slides is for content, second pass is for formatting :-). For now, I did manual division of the sides. I am using both org-beamer and org-reveal ( https://github.com/yjwen/org-reveal) and ideally they would have optimized (and possibly different) slide breaks. E.g. perhaps beamer breaks 9 elements into 3 3-elements slides whereas reveal breaks into 2 slides, one with 5 elements and one of 4 elements. I'll look around for the previous post but in the mean time I think I will stick with method 0. To summarise the previous post (i.e. from the thread I started for this bug), all you have to do is simply include the following on any slide for which you want frame breaks: --8---cut here---start-8--- * A long frame with breaks :PROPERTIES: :BEAMER_opt: allowframebreaks,label= :END: --8---cut here---end---8--- Method 0 is, in principle, desirable, but I actually find that beamer does a really nice job on automatic frame breaks in most cases and it makes writing some types of presentations much easier! An example, from my own usage, is the solution to some example problem when teaching. I can simply write down all the steps, e.g. as an enumerated list, and let beamer worry about the breaks. Using automatic frame breaks, for me, is just the obvious extension of org (or LaTeX): let me worry about the content and let the system worry about the formatting! From LyX: what you see is what you mean :-) -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.2-180-g71152d
Re: [O] [BUG][PATCH] Marker points into wrong buffer
Rasmus ras...@gmx.us writes: Rasmus ras...@gmx.us writes: If anyone can figure out what is wrong on the Org side or what broke in Emacs-Core it would be great! Luckily it's an all-C commit so I don't know how to proceed from here. . . This really stupid patch allows me to export the document I was unable to export yesterday with emacs-bzr r115062 (latest or almost latest) and the latest version Org. Eric F., would you mind testing it with your slides? I will be very happy to! I'm just about to head off to give a 2 hour lecture and then busy all afternoon with meetings but I'll try to check this out today at some point. Thanks, eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.2-180-g71152d
Re: [O] Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)]
Bastien,
I apologize for the mishaps of sending from the wrong address that time
and for somehow leaving off the commentary that I thought was sent with
the code block.
Is it a trivial fix to alter drawer and possibly other element regexps
to never match anything inside of a code block, or should I add it to
http://orgmode.org/tmp/worg/org-issues.html ?
Tod
b...@altern.org writes:
Hi Tod,
Tod Middlebrook whatifits...@gmail.com writes:
* stuff for bug report
#+BEGIN_SRC emacs-lisp
(setq org-capture-templates
(quote
(
(c Contacts entry (file+headline ~/my-stuff/file.org
Contacts)
* %^{Name: }
:PROPERTIES:
:EMAIL: %^{Email}
:PHONE: %^{Phone number}
:NAME: %^{Full Name}
:END:
%?
#+END_SRC
:PROPERTIES:
:NAME: org-capture-templates
:DEPENDS: org
:END:
Simply put property drawers right after the headline, or just don't
put source-code-blocks-containing-property-drawers between headline
and real property drawers.
Re: [O] Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)]
Hi Tod, Tod Middlebrook todmiddlebr...@gmail.com writes: Is it a trivial fix to alter drawer and possibly other element regexps to never match anything inside of a code block, or should I add it to http://orgmode.org/tmp/worg/org-issues.html ? It is not trivial, but your best chance is to describe the bug on this mailing list so that someone is convince (1) it's not just some weird use-case and (2) it's worth a fix. 2 cents, -- Bastien
Re: [O] help me get started with org-publish?
Bastien b...@gnu.org writes: Hi Jay, Jay Dixit di...@aya.yale.edu writes: Thanks. I disabled smex, and now when I m-x org-publish, I get: Publishing file /Users/jay/blog-test/my-blog.org using `org-html-publish-to-html' org-html-publish-to-html: Wrong number of arguments: #[(format plist filename pub-dir) ÆÇ!ˆÈ !„ That's weird. Something must be broken in your configuration. How did you install Org? Through git or through ELPA? Can you reproduce the problem with only one test small file file from your publishing directory, and the bare minimum Org config? Also testing with an uncompiled Org will help getting a more readable backtrace. ISTR that Jay had parentheses around org-html-publish-to-html in his template, thereby making it (wrongly) into a function call. Somebody (don't remember who, sorry) pointed that out but maybe it's worth bringing it up again. -- Nick
Re: [O] help me get started with org-publish?
Hi Nick, Nick Dokos ndo...@gmail.com writes: ISTR that Jay had parentheses around org-html-publish-to-html in his template, thereby making it (wrongly) into a function call. Somebody (don't remember who, sorry) pointed that out but maybe it's worth bringing it up again. Yep, I remember Robert Klein suggested this, but parentheses here are fine, :publishing-function can be set to a list of functions (even if there is just one function in the list!) So... I guess we still need more info! -- Bastien
Re: [O] M-return = org-insert-heading in item list scrolls buffer down 1 line
Am 11.11.2013 17:58, schrieb Bastien: Hi Rainer, Rainer Stengele rainer.steng...@online.de writes: That might be a bug. Did you re-compile Emacs recently? This looks like a bug in the display engine that I've noticed too a while ago. Hi Bastien, no, I use GNU Emacs 24.3.50.1 (i386-mingw-nt6.1.7601) of 2013-03-14 on VBOX sice several months. Rainer
Re: [O] help me get started with org-publish?
Bastien b...@gnu.org writes: Hi Nick, Nick Dokos ndo...@gmail.com writes: ISTR that Jay had parentheses around org-html-publish-to-html in his template, thereby making it (wrongly) into a function call. Somebody (don't remember who, sorry) pointed that out but maybe it's worth bringing it up again. Yep, I remember Robert Klein suggested this, but parentheses here are fine, :publishing-function can be set to a list of functions (even if there is just one function in the list!) Ah, OK - I forgot about that. Sorry about the noise. So... I guess we still need more info! Yes, a backtrace would be nice. -- Nick
Re: [O] Bug dragging lines in tag-restricted agenda
Hi, Bastien, Thanks for giving this your attention. I'm afraid I'm still seeing the same behavior described in the bug report. Best, Thomas
Re: [O] Babel: the disappearing hline
On 2013-11-12 01:16, Jarmo Hurri wrote:
Eric Schulte schulte.e...@gmail.com writes:
There are two paces to specify header arguments in a call line, the
arguments in the [] are applied to the input-table function, *not* to
the call line, so they change the inputs. The trailing header
arguments are applied to the call line.
So there is an implicit post-processing function that takes the result
of the called block as input, and hline pruning is applied in this
function?
I put on the table a suggestion that the default behaviour of #+CALL
w.r.t. the handling of hlines is changed from removing hlines in output
to not removing them. I am suggesting this partly because I don't
understand why the default behaviour is as it is now, and secondly
because the current behavious differs from the way hlines are handled
in
other block evaluations:
This behavior is controlled globally by the value of
`org-babel-default-header-args'. This is overriden by the value of
`org-babel-default-header-args:{lang}' and of course, the setting on
individual source blocks and call lines. As you can see from the below
output, the default is =:hlines no=. Note that in versions of org-mode
prior to commit 6857d139 of 2013-09-28 (below), this was overridden in
the setting of `org-babel-default-header-args:emacs-lisp, so this may
be why you are seeing and inconsistency between the call line and
the emacs-lisp source block.
If you want hlines to be included by default, you can modify the value
of `org-babel-default-header-args'.
I have attached an org file i have been working on to see the results
of various settings of =colnames= and =hlines= on table evaluation in
various languages, you may find it useful.
rick
--
commit 6857d139e1b5ea5c235e3555dbe15aeab227aaef
Author: Eric Schulte schulte.e...@gmail.com
Date: Sat Sep 28 06:37:54 2013 -0600
set default emacs-lisp header args to nil
The difference between elisp and every other language was causing
confusion, so simpler just to set these to nil.
* lisp/ob-emacs-lisp.el (org-babel-default-header-args:emacs-lisp):
Set to nil.
1 file changed, 1 insertion(+), 2 deletions(-)
lisp/ob-emacs-lisp.el | 3 +--
Modified lisp/ob-emacs-lisp.el
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index 886645d..4505129 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -28,8 +28,7 @@
;;; Code:
(require 'ob)
-(defvar org-babel-default-header-args:emacs-lisp
- '((:hlines . yes) (:colnames . no))
+(defvar org-babel-default-header-args:emacs-lisp nil
Default arguments for evaluating an emacs-lisp source block.)
(declare-function orgtbl-to-generic org-table (table params))
#+TITLE: Colnames handling
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+AUTHOR: Rick Frankel
#+EMAIL: ut0598@rtasdv12
#+OPTIONS: ':nil *:t -:t ::t :t H:3 \n:nil ^:t arch:headline
#+OPTIONS: author:t c:nil creator:comment d:(not LOGBOOK) date:t
#+OPTIONS: e:t email:nil f:t inline:t num:nil p:nil pri:nil stat:t
#+OPTIONS: tags:t tasks:t tex:t timestamp:nil toc:t todo:t |:t
#+DESCRIPTION:
#+EXCLUDE_TAGS: noexport
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export
Evaluate the subtree [[Test generator]] with =org-babel-execute-subtree= (=C-c C-v C-s=).
It will:
1. Run [[generate-colnames-and-hlines-tests]] to create the [[colnames and
hlines]] tests.
2. Run the tests.
Note that it will automatically require the file ob-{lang} for
each language block specified in [[Language functions]] below.
* Language functions
:PROPERTIES:
:results: silent
:exports: code
:var: table=table
:ID: LANGUAGES
:END:
This function should modify each cell of the input table by appending
/-o/ to the value of the cell and convert ='hline= rows in the
input to the literal /hline/, so it appears in the output table.
Create one for each babel language to be tested.
#+CAPTION: emacs-lisp
#+BEGIN_SRC emacs-lisp
(mapcar
(lambda (r)
(if (sequencep r)
(mapcar
(lambda (c)
(if (integerp c)
(format %d-o c)
(concat c -o)))
r)
(list r)))
table)
#+END_SRC
#+CAPTION: perl
#+BEGIN_SRC perl :results value
return [map {
ref $_ ? [map { $_ . -o } @$_] : $_
} @$table];
#+END_SRC
#+CAPTION: python
#+name: python
#+BEGIN_SRC python
return [isinstance(r,list) and [str(c)+-o for c in r] or [r] for r in table]
#+END_SRC
#+CAPTION: ruby
#+BEGIN_SRC ruby
table.collect do |r|
r.instance_of?(Array) ? r.collect { |c| #{c}-o } : [r]
end
#+END_SRC
* Test generator
#+CAPTION: Input table
#+name: table
| a | b | c |
|---+---+---|
| 1 | 2 | 3 |
| 4 | 5 | 6 |
|---+---+---|
| 7 | 8 | 9 |
#+CAPTION: Function to list default header args by language
#+name: list-defaults
#+HEADER: :var val='org-babel-default-header-args :eval never :exports code
#+BEGIN_SRC emacs-lisp :colnames '(option value)
(or
(mapcar
(lambda (x) (list (car x) (cdr x))) (eval val)) '(( )))
#+END_SRC
#+name:
Re: [O] Bug dragging lines in tag-restricted agenda
Hi Thomas, Thomas Morgan t...@ziiuu.com writes: I'm afraid I'm still seeing the same behavior described in the bug report. You're right, there are still annoying bugs after filtering. I'll have a look when I have more time at hand. Best, -- Bastien
Re: [O] Babel: the disappearing hline
Rick Frankel r...@rickster.com writes: Greetings Rick. Note that in versions of org-mode prior to commit 6857d139 of 2013-09-28 (below), this was overridden in the setting of `org-babel-default-header-args:emacs-lisp, so this may be why you are seeing and inconsistency between the call line and the emacs-lisp source block. If I understand correctly, you are referring to the possibility that the inconsistency would be caused by an old version of org. I do not think that this is the case: I have been pulling the newest version every day. Below is the output of the test, including a printout of my org version number. Or is there something weird in my setup? Do you get a different output with my test cases? I will look at the other stuff you sent a bit later. All the best, Jarmo # -- * hline pruning in output # test org version #+BEGIN_SRC emacs-lisp (org-version) #+END_SRC #+RESULTS: : 8.2.3a # case 1: hlines are retained by default when a source code block is # defined and evaluated #+NAME: func #+BEGIN_SRC emacs-lisp (list '(a) '(b) 'hline '(c)) #+END_SRC #+RESULTS: func | a | | b | |---| | c | # case 2: hlines are retained by default when source code is called # by post #+BEGIN_SRC emacs-lisp :post func() #+END_SRC #+RESULTS: | a | | b | |---| | c | # case 3: but hlines are removed by default when source code is # called by #+CALL #+CALL: func() #+RESULTS: | a | | b | | c |
[O] links to attachments don't export anymore
Hi, This used to work, back in August but I just updated today and Something Has Changed. After setting this option: (setq org-link-abbrev-alist '((att . org-attach-expand-link))) It was possible to insert a link to an attachment like this: [[att:FigureA.jpg]] and clicking on it would show the file (still works), and it would show up in the exported document (no longer happens). Inspecting the output shows that the link is wrong: /home/myles/myorg/FigureA.jpg When it should be: /home/myles/myorg/data/ad/c7f168-33bb-4e38-83fa-6aea6708563b/FigureA.jpg Can anyone tell me how to get the link exported correctly? (And why has the indenting of this email gone weird?) Thanks, Myles
Re: [O] [BUG][PATCH] Marker points into wrong buffer
Rasmus ras...@gmx.us writes: [...] This really stupid patch allows me to export the document I was unable to export yesterday with emacs-bzr r115062 (latest or almost latest) and the latest version Org. Eric F., would you mind testing it with your slides? I've tested it with three files, one a beamer presentation, another a large LaTeX document and the last one a very small LaTeX file. The first with octave code and the other two with emacs lisp. Two with call_xxx() construct and one with #+call:. All cases worked perfectly fine! Thanks! eric -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.2.2-181-gf31eb4.dirty
Re: [O] Babel: the disappearing hline
On 2013-11-12 11:09, Jarmo Hurri wrote: Rick Frankel r...@rickster.com writes: Greetings Rick. Note that in versions of org-mode prior to commit 6857d139 of 2013-09-28 (below), this was overridden in the setting of `org-babel-default-header-args:emacs-lisp, so this may be why you are seeing and inconsistency between the call line and the emacs-lisp source block. If I understand correctly, you are referring to the possibility that the inconsistency would be caused by an old version of org. I do not think that this is the case: I have been pulling the newest version every day. Below is the output of the test, including a printout of my org version number. I don't think 8.2.3a is the lastest version from git, containing the change eric made to the header args: % git diff release_8.2.3a..6857d139 lisp/ob-emacs-lisp.el|cat diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el index 886645d..4505129 100644 --- a/lisp/ob-emacs-lisp.el +++ b/lisp/ob-emacs-lisp.el @@ -28,8 +28,7 @@ ;;; Code: (require 'ob) -(defvar org-babel-default-header-args:emacs-lisp - '((:hlines . yes) (:colnames . no)) +(defvar org-babel-default-header-args:emacs-lisp nil Default arguments for evaluating an emacs-lisp source block.) (declare-function orgtbl-to-generic org-table (table params)) what is the output of: #+BEGIN_SRC emacs-lisp (mapcar 'list org-babel-default-header-args:emacs-lisp)) #+END_SRC Regardless, I get the same results you do. I think the issue is this: hlines are stripped in the input to a block and added back after depending on the value of the :hlines header argument. Since your code is outputting literal hlines, there is no processing on output from the literal block as there where no inputs. However, if you do the following you will see that the hlines follow the header rules (stripping the hlines by default: #+BEGIN_SRC emacs-lisp :var data=func() data #+END_SRC #+RESULTS: | a | | b | | c | As to the call lines, think of the output of the called block as being input to an anonymous block (the #+call), so the hlines are stripped. Or is there something weird in my setup? Do you get a different output with my test cases? No, nothing weird, but the issue is not specific to call lines, it's just related to the way babel processes input and output tablular data. It's not entirely obvious (and affects colnames as well as hlines). Again, the solution is to globally set the :hline property to =yes= instead of the default =no=, and you will get the results you want. Change the value of `org-babel-default-header-args' in your startup or just change the :hlines property on a file or headline basis: #+PROPERTY: hlines yes or * hline pruning in output :PROPERTIES: :hlines: yes :END: I will look at the other stuff you sent a bit later. All the best, Jarmo # -- * hline pruning in output # test org version #+BEGIN_SRC emacs-lisp (org-version) #+END_SRC #+RESULTS: : 8.2.3a # case 1: hlines are retained by default when a source code block is # defined and evaluated #+NAME: func #+BEGIN_SRC emacs-lisp (list '(a) '(b) 'hline '(c)) #+END_SRC #+RESULTS: func | a | | b | |---| | c | # case 2: hlines are retained by default when source code is called # by post #+BEGIN_SRC emacs-lisp :post func() #+END_SRC #+RESULTS: | a | | b | |---| | c | # case 3: but hlines are removed by default when source code is # called by #+CALL #+CALL: func() #+RESULTS: | a | | b | | c |
Re: [O] [BUG] Marker points into wrong buffer
Rasmus writes: I bisected emacs-bzr to find the revision where it breaks for me (cf. attached test case). It's this one: committer: Dmitry Antipov dmanti...@yandex.ru Please report this as an Emacs bug. I can find no bug that this change is fixing and it clearly alters (undocumented, AFAICS) behaviour, specifically turning something into an error that the original code silently allowed. There may have been agood reason for this, but this would then be NEWS-worthy since code using markers would have to be checked for this. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)]
Bastien,
When there is no property drawer before the code block, C-c C-x p
affects the code block and either doesn't create a property drawer or it
leaves the 'real' property drawer unaffected.
An example for the second case, where org-set-property matches the code
block, despite an existing property drawer that happens to be below
it. The wrong NAME is matched, and DEPENDS isn't matched at
all. This could throw off for example org-dotemacs, where it would
tangle code blocks in the wrong order without the DEPENDS matching.
* stuff for bug report
#+BEGIN_SRC emacs-lisp
(setq org-capture-templates
(quote
(
(c Contacts entry (file+headline ~/my-stuff/file.org Contacts)
* %^{Name: }
:PROPERTIES:
:EMAIL: %^{Email}
:PHONE: %^{Phone number}
:NAME: %^{Full Name}
:END:
%?
#+END_SRC
:PROPERTIES:
:NAME: org-capture-templates
:DEPENDS: org
:END:
Thanks,
Tod
b...@gnu.org writes:
Hi Tod,
Tod Middlebrook todmiddlebr...@gmail.com writes:
The bug below prevents me from easily using dependencies in org-dotemacs.
To reproduce,
start with this entry:
*** stuff for bug report
#+BEGIN_SRC emacs-lisp
(setq org-capture-templates
(quote
(
(c Contacts entry (file+headline ~/my-stuff/file.org
Contacts)
* %^{Name: }
:PROPERTIES:
:EMAIL: %^{Email}
:PHONE: %^{Phone number}
:END:
%?
#+END_SRC
Then do C-c C-x p EMAIL [RET] TestValue, and get the same block, with
the properties drawer folded. When expanded, there is:
*** stuff for bug report
#+BEGIN_SRC emacs-lisp
(setq org-capture-templates
(quote
(
(c Contacts entry (file+headline ~/my-stuff/file.org
Contacts)
* %^{Name: }
:PROPERTIES:
:EMAIL:TestValue
:PHONE: %^{Phone number}
:END:
%?
#+END_SRC
I'm not sure to understand what the problem is exactly: if the problem
is that `C-x C-c p' works in the context of source code blocks, we can
easily fix it. If the problems is that such properties are matched in
contexts where they should not, we need more information about when
you observe the wrong behavior, i.e. in what context do you see the
properties taken into account while you expect them to be ignored?
Thanks in advance for further details,
[O] adapted org-flag-drawer to hide newlines of consecutive drawers to save lines
Often several consecutive drawers follow the headline in my setup. Maybe this code to hide newlines after drawers is of some use. When drawers are hidden this wastes three lines of screen real estate : * heading : :LOGBOOK:... : :CLOCK:... : :PROPERTIES:... per line. I adapted org-flag-drawer to hide the newlines as well if another drawer is following: : * heading : :LOGBOOK:...:CLOCK:...:PROPERTIES:... This lead to a much denser editing experience. Maybe this is not the best way to do this. But this trick caused no troubles for me during the last months. All the best! Gregor #+BEGIN_SRC emacs-lisp (defun org-flag-drawer (flag) When FLAG is non-nil, hide the drawer we are within, including the newline at end of a drawer, yet only if another drawer is following. If FLAG is nil, make drawer it visible. (save-excursion (beginning-of-line 1) (when (looking-at ^[ \t]*:[a-zA-Z][a-zA-Z0-9]*:) (let ((b (match-end 0)) (selective-display-ellipses nil)) (if (re-search-forward ^[ \t]*:END: (save-excursion (outline-next-heading) (point)) t) (outline-flag-region b (save-excursion (forward-line) (if (looking-at org-drawer-regexp) (point-at-bol) (match-end 0))) flag) (error :END: line missing at position %s in buffer %s b (buffer-name))) #+END_SRC Refererences -- org.el::org-cycle-hide-drawers --
[O] (invalid-function org-with-silent-modifications) despite reinstall
To: emacs-orgmode@gnu.org Subject: Bug: Debugger entered--Lisp error: (invalid-function org-with-silent-modifications) despite reinstall [8.2.3a (8.2.3a-elpaplus @ c:/Users/Dexter/.emacs.d/elpa/org-plus-contrib-2013/)] From: odta...@yahoo.com --text follows this line-- Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. all of a sudden I started receiving this error when trying to display the agenda. Everything has been working great up to now. I had not changed my installation, except adding awk to the babel languages, but despite trying the latest org-plus-contrib tarball and reinstalling ELPA (fresh emacs), the error will not stop. Please help, thanks Dex PS I see the org-mode-hook looks weird ?? Emacs : GNU Emacs 24.3.1 (i386-mingw-nt6.2.9200) of 2013-03-17 on MARVIN Package: Org-mode version 8.2.3a (8.2.3a-elpaplus @ c:/Users/Dexter/.emacs.d/elpa/org-plus-contrib-2013/) current state: == (setq org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-agenda-skip-scheduled-if-done t org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-babel-pre-tangle-hook '(save-buffer) org-agenda-diary-file ~/org/appts.org org-occur-hook '(org-first-headline-recenter) org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-default-notes-file c:/Users/Dexter/org/notes.org org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-agenda-include-diary t org-mode-hook '(#[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil \300\301\302\303\304$\207 [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes) org-from-is-user-regexp nil org-metadown-hook '(org-babel-pop-to-session-maybe) org-agenda-files '(~/org) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-after-todo-state-change-hook '(org-clock-out-if-current) org-babel-tangle-lang-exts '((awk . awk) (emacs-lisp . el)) org-babel-load-languages '((awk . t)) org-confirm-shell-link-function 'yes-or-no-p )
Re: [O] [BUG][PATCH] Marker points into wrong buffer
Rasmus writes: Rasmus ras...@gmx.us writes: If anyone can figure out what is wrong on the Org side or what broke in Emacs-Core it would be great! Luckily it's an all-C commit so I don't know how to proceed from here. . . This really stupid patch allows me to export the document I was unable to export yesterday with emacs-bzr r115062 (latest or almost latest) and the latest version Org. Here's a better patch (I hope). From c297d59c7ec6ce04ebba3cbeb9641217d1ff5cf1 Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Tue, 12 Nov 2013 21:55:53 +0100 Subject: [PATCH] ob-ref: Fix Marker points into wrong buffer error * lisp/ob-ref.el (org-babel-ref-parse): If `org-babel-current-src-block-location' is a marker, it can be from another buffer, use marker-position instead in this case. Introduced with r114064 on Emacs trunk. Not sure if this is a bug in Org or Emacs, but the patch restores the previous behaviour. --- lisp/ob-ref.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el index 5a3c8ba..251fa55 100644 --- a/lisp/ob-ref.el +++ b/lisp/ob-ref.el @@ -85,7 +85,9 @@ (defun org-babel-ref-parse (assignment) (cons (intern var) (let ((out (save-excursion (when org-babel-current-src-block-location - (goto-char org-babel-current-src-block-location)) + (goto-char (if (markerp org-babel-current-src-block-location) + (marker-position org-babel-current-src-block-location) + org-babel-current-src-block-location))) (org-babel-read ref (if (equal out ref) (if (string-match ^\.*\$ ref) -- 1.8.4.2 Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Using Multiple TODO Keywords
bzg Hi Kenneth, Hello, Bastien! Sorry to have taken so long to reply ... When I use `t' or C-c C-t, the keywords change from TODO, to PENDING, to CANCELED, and then repeat *only those three states*. Shouldn't I be able to use the above to mark the this week's task as DONE? bzg If you use fast TODO selection like this bzg #+SEQ_TODO: TODO PENDING | CANCELED DONE(d) bzg (note the (d) after DONE) then you'll be able to set the task DONE, Great minds think alike? ;-) That's what I ended up using soon after my ML posting. bzg but the presence of the repeater will still let the TODO state bzg switch to the next one, namely TODO. Yes. I'm still a bit baffled by the behavior of repeaters ... bzg Maybe we should introduce a way to ignore the repeater -- is anyone bzg missing this too? Not that important to me ... at least for now ... still trying to learn how to use the more basic (viz., task scheduling) elements within Org. Thanks for taking the time to reply, -Kenneth
Re: [O] Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)]
Hi Tod and Bastien,
The property drawer after the code block is a red herring: the following
file (with no real property drawer at all) misbehaves on property
setting and getting functions, with the fake properties in the code
block behaving as though they pertained to the headline (as can be
confirmed by M-: (org-entry-get nil EMAIL)):
* stuff for bug report
#+BEGIN_SRC emacs-lisp
(setq i-am-a-string
:PROPERTIES:
:EMAIL: %^{Email}
:PHONE: %^{Phone number}
:END:
)
#+END_SRC
I think this problem of unselective regex searches will also affect uses
of e.g. org-scheduled-time-regexp
This seems like an excellent use case for the parser: basically a bunch
of uses of org-*-regexp and org-re-property need to be augmented with
a check like:
(not (memq (org-element-type (org-element-at-point)) '(src-block example-block
...)))
A better alternative might be to use the parser to find the property
drawer in the first place (instead of a regex). Either way, it seems
like the best strategy might be to fix all uses of these problem
variables at once, which is a big undertaking.
--
Aaron Ecay
Re: [O] Bug: property drawers within code blocks interfere [8.2.2 (8.2.2-elpa @ /home/tod/.emacs.d/.cask/24.3.50.1/elpa/org-20131108/)]
Hi Aaron and Tod, Aaron Ecay aarone...@gmail.com writes: This seems like an excellent use case for the parser: basically a bunch of uses of org-*-regexp and org-re-property need to be augmented with a check like: (not (memq (org-element-type (org-element-at-point)) '(src-block example-block ...))) A better alternative might be to use the parser to find the property drawer in the first place (instead of a regex). Either way, it seems like the best strategy might be to fix all uses of these problem variables at once, which is a big undertaking. Also don't forget the cost in terms of speed. It's fine to fix the behavior of Org for such cases, but those cases are rare, and could be explicitely prevented. If the general fix does not slow down the parsing too much, then I'm all for it. Nicolas might have better insight here than me. 2 cents, -- Bastien
Re: [O] adapted org-flag-drawer to hide newlines of consecutive drawers to save lines
Hi Gregor, Gregor Kappler g.kapp...@gmx.net writes: When drawers are hidden this wastes three lines of screen real estate : * heading : :LOGBOOK:... : :CLOCK:... : :PROPERTIES:... per line. I adapted org-flag-drawer to hide the newlines as well if another drawer is following: : * heading : :LOGBOOK:...:CLOCK:...:PROPERTIES:... This lead to a much denser editing experience. Probably a matter of taste, so I won't argue too much, but I'd rather stick to the current folding style, where ... consistently means that there is a hidden region. Beside, `org-flag-drawer' is currently under revision since Michael report on slowliness (and recent discussion with Tod and Aaron.) Best, -- Bastien
Re: [O] [BUG][PATCH] Marker points into wrong buffer
Achim Gratz strom...@nexgo.de writes: Here's a better patch (I hope). Feel free to install it, thanks! -- Bastien
Re: [O] A weird warning and a test (eager macro expansion) error
[resent]
Bastien writes:
Thanks -- I remember we had this issue before. I'm just surprise I'm
the first one to report it, I assume many people use a recent Emacs
with macro expansion done this way.
This patch fixes the error, but it looks strange (indentation is still
unchanged for clarity). Not sure if this an Ert or Emacs error, though.
From e123a7c180f5390a8658e0f352e05d85aca3627c Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Tue, 12 Nov 2013 22:01:41 +0100
Subject: [PATCH] testing: fix eager macro expansion failures on Emacs trunk
* testing/lisp/test-ob.el, testing/lisp/test-org-table.el: Quote
deftest body forms starting with a let clause.
This may actually constitute a bug in Emacs or Ert.
---
testing/lisp/test-ob.el| 36 ++--
testing/lisp/test-org-table.el | 16
2 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index e7f0645..ac409a4 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -41,7 +41,7 @@
\t #+headers : blah1 blah2 blah3 \t\n\t\n blah4 blah5 blah6 \n
(ert-deftest test-org-babel/src-block-regexp ()
- (let ((test-block
+ `(let ((test-block
(concat
#+begin_src language -n-r-a-b -c :argument-1 yes :argument-2 no\n
echo this is a test\n
@@ -103,7 +103,7 @@
org-babel-default-inline-header-args)))
(ert-deftest ob-test/org-babel-combine-header-arg-lists ()
- (let ((results (org-babel-combine-header-arg-lists
+ `(let ((results (org-babel-combine-header-arg-lists
'((foo . :any)
(bar)
(baz . ((foo bar) (baz)))
@@ -280,7 +280,7 @@
(should-not (org-babel-get-inline-src-block-matches)
(ert-deftest test-org-babel/inline-src_blk-default-results-replace-line-1 ()
- (let ((test-line src_sh{echo 1}))
+ `(let ((test-line src_sh{echo 1}))
;; src_ at bol line 1...
(org-test-with-temp-text
test-line
@@ -300,7 +300,7 @@
(concat test-line =1= =1= =1=)
(buffer-substring-no-properties (point-at-bol) (point-at-eol)
;; src_ follows space line 1...
-(let ((test-line src_emacs-lisp{ 1 }))
+`(let ((test-line src_emacs-lisp{ 1 }))
(org-test-with-temp-text
test-line
(should-error (org-ctrl-c-ctrl-c))
@@ -317,7 +317,7 @@
(ert-deftest test-org-babel/inline-src_blk-default-results-replace-line-2 ()
;; src_ at bol line 2...
- (let ((test-line src_emacs-lisp{ \x\ }))
+ `(let ((test-line src_emacs-lisp{ \x\ }))
(org-test-with-temp-text
(concat \n test-line)
(should-error (org-ctrl-c-ctrl-c))
@@ -331,7 +331,7 @@
(buffer-substring-no-properties
(point-at-bol) (point-at-eol))
- (let ((test-line Some text prior to block src_emacs-lisp{ \y\ }))
+ `(let ((test-line Some text prior to block src_emacs-lisp{ \y\ }))
(org-test-with-temp-text
test-line
(goto-char (point-max))
@@ -348,7 +348,7 @@
(should-error (org-ctrl-c-ctrl-c)
(ert-deftest test-org-babel/inline-src_blk-manual-results-replace ()
- (let ((test-line src_emacs-lisp[:results replace]{ \x\ }))
+ `(let ((test-line src_emacs-lisp[:results replace]{ \x\ }))
(org-test-with-temp-text
(concat \n test-line)
(should-error (org-ctrl-c-ctrl-c))
@@ -362,7 +362,7 @@
(buffer-substring-no-properties
(point-at-bol) (point-at-eol))
- (let ((test-line (concat Some text prior to block
+ `(let ((test-line (concat Some text prior to block
src_emacs-lisp[:results replace]{ \y\ })))
(org-test-with-temp-text test-line
(goto-char (point-max))
@@ -379,7 +379,7 @@
(should-error (org-ctrl-c-ctrl-c)
(ert-deftest test-org-babel/inline-src_blk-results-silent ()
- (let ((test-line src_emacs-lisp[ :results silent ]{ \x\ }))
+ `(let ((test-line src_emacs-lisp[ :results silent ]{ \x\ }))
(org-test-with-temp-text test-line
(org-ctrl-c-ctrl-c)
(should (string= test-line
@@ -387,7 +387,7 @@
(point-at-bol) (point-at-eol
(end-of-buffer)
(should-error (org-ctrl-c-ctrl-c
- (let ((test-line (concat Some text prior to block src_emacs-lisp
+ `(let ((test-line (concat Some text prior to block src_emacs-lisp
[ :results silent ]{ \y\ })))
(org-test-with-temp-text
test-line
@@ -405,12 +405,12 @@
(should-error (org-ctrl-c-ctrl-c)
(ert-deftest test-org-babel/inline-src_blk-results-raw ()
- (let ((test-line src_emacs-lisp[ :results raw ]{ \x\ }))
+ `(let ((test-line src_emacs-lisp[ :results raw ]{ \x\ }))
(org-test-with-temp-text test-line
(org-ctrl-c-ctrl-c)
(should (string= (concat test-line x)
(buffer-string)
- (let ((test-line (concat Some text prior to block
+ `(let ((test-line (concat Some text prior to block
src_emacs-lisp[ :results raw ]{ \the\ })))
(org-test-with-temp-text
Re: [O] Using Multiple TODO Keywords
Hi Kenneth, Kenneth Jacker k...@be.cs.appstate.edu writes: Great minds think alike? ;-) That's what I ended up using soon after my ML posting. Great manual make great minds stumble upon solutions :) bzg but the presence of the repeater will still let the TODO state bzg switch to the next one, namely TODO. Yes. I'm still a bit baffled by the behavior of repeaters ... bzg Maybe we should introduce a way to ignore the repeater -- is anyone bzg missing this too? Not that important to me ... at least for now ... still trying to learn how to use the more basic (viz., task scheduling) elements within Org. FWIW, I implemented an experimental solution. You can apply the patch you'll find here: http://article.gmane.org/gmane.emacs.orgmode/78700 Then use C-- 1 C-c C-t to switch to a DONE state even for repeating events. I'll surely apply the patch on master soon, I'm still waiting for some feedback. Thanks in advance for testing it if you can. -- Bastien
Re: [O] [BUG][PATCH] Marker points into wrong buffer
Achim Gratz strom...@nexgo.de writes: Introduced with r114064 on Emacs trunk. Not sure if this is a bug in Org or Emacs, but the patch restores the previous behaviour. --- lisp/ob-ref.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el index 5a3c8ba..251fa55 100644 --- a/lisp/ob-ref.el +++ b/lisp/ob-ref.el @@ -85,7 +85,9 @@ (defun org-babel-ref-parse (assignment) (cons (intern var) (let ((out (save-excursion (when org-babel-current-src-block-location -(goto-char org-babel-current-src-block-location)) +(goto-char (if (markerp org-babel-current-src-block-location) + (marker-position org-babel-current-src-block-location) + org-babel-current-src-block-location))) Right. I didn't know that marker ≠ char and that marker contains the buffer. markerp is the better test here. –Rasmus -- Summon the Mothership!
[O] Babel #+CALL: results?
I'm new to Babel -- I've been using Org for the last few years just to organize and typeset simple LaTeX for PDF and MathJax export -- and furthermore have had to compile Emacs from scratch and install into my home directory (installing Org as an ELPA package) to get my versions to sync up with the Worg documentation, so I may have broken something, but I've had no end of trouble trying to get even the simplest named block calls to produce output. As I understand Worg, and some old list messages from gmane, the following should produce meaningful output: #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 echo Var1: $Var1 #+END_SRC #+CALL: testfun[:results output](Var1=Val3) :results output verbatim #+RESULTS: : *Once* I got output, but I could not reproduce this after making and undoing a few formatting changes; I would chalk this up to my own cluelessness, except that I can get what I *think* is statefully incorrect output from the first block: Iteration 1 (control case): Begin with only the #+NAME: ... #+END_SRC with :results verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun : Var1: Val1 Iteration 2: Replace :results output verbatim with :results output raw and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output raw echo Var1: $Var1 #+END_SRC #+RESULTS: testfun Var1: Val1 Iteration 3: Change back to :results output verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun =Var1: Val1 =Var1: Val1 Iteration 3+n: Execute the same block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun =Var1: Val1 ==Var1: Val1 ==Var1: Val1 (prev. line repeated n times total) =Var1: Val1 Is this intended behavior? I will admit I don't understand Babel's output modes sufficiently well to know for sure; *however*, I also believe my one isolated success in getting output from #+CALL: was a side effect of this stateful behavior. If this is likely to be due to a bad install/configuration, can anyone clarify the right way to get a current org-mode installation (or at least, a version that corresponds to one or more official online documentation repositories) as an unprivileged user on a system that already has a prepackaged emacs installation? If this is intended behavior, where can I find the right combination of :results properties to pass output from a named block to a later call for display and/or export? Running from my current home directory installation, here are my emacs and Org versions: GNU Emacs 24.3.2 (x86_64-unknown-linux-gnu, GTK+ Version 2.18.9) of 2013-11-10 on host Org-mode version 8.2.2 (8.2.2-dist @ /homedir/.emacs.d/elpa/org-20131108/) Any guidance would be greatly appreciated... Phil Regier preg...@ittc.ku.edu
Re: [O] Babel #+CALL: results?
Hi Phil, I’m far from an expert myself, but I think I see what is going on with your testcases. 2013ko azaroak 12an, Phil Regier-ek idatzi zuen: [...] *Once* I got output, but I could not reproduce this after making and undoing a few formatting changes; I would chalk this up to my own cluelessness, except that I can get what I *think* is statefully incorrect output from the first block: Iteration 1 (control case): Begin with only the #+NAME: ... #+END_SRC with :results verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun : Var1: Val1 So far, as expected. Iteration 2: Replace :results output verbatim with :results output raw and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output raw echo Var1: $Var1 #+END_SRC #+RESULTS: testfun Var1: Val1 Also as expected. Iteration 3: Change back to :results output verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun =Var1: Val1 =Var1: Val1 Now org would like to remove the previous output. However, it cannot do so, since it does not know where it begins and ends (since raw output could contain in principle anything, or nothign at all). It’s best to use “drawer” instead of “raw” in most cases, because the drawer wrapper bounds the result and lets subsequent calls see it and remove it. Without removing the previous result, org tries to add the “Var1: Val1” as verbatim text (before the instance of that text which is left over from the previous call). It looks like even though there is a newline in the string org chooses to use the single-line =verbatim= syntax, rather than the multiline : verbatim I don’t know why it does this, and it may be a bug. As for your original example: #+CALL: testfun[:results output](Var1=Val3) :results output verbatim You don’t need the second :results output. That applies to an invisible elisp source block which wraps the evaluation of the #+call line, and which produces no output. I get the right result consistently with #+CALL: testfun(Var1=Val3) #+RESULTS: : Var1: Val3 Or (note the addition of quotes in the result): #+CALL: testfun(Var1=Val3) :results verbatim #+RESULTS: : Var1: Val3 -- Aaron Ecay
Re: [O] Using allowframebreaks in org-beamer
Thank you for the clarification Eric. That did exactly what I wanted it to! Best, Stephen e.fr...@ucl.ac.uk writes: Stephen J. Barr stev...@uw.edu writes: I agree with the less stuff part. The first pass in my slides is for content, second pass is for formatting :-). For now, I did manual division of the sides. I am using both org-beamer and org-reveal ( https://github.com/yjwen/org-reveal) and ideally they would have optimized (and possibly different) slide breaks. E.g. perhaps beamer breaks 9 elements into 3 3-elements slides whereas reveal breaks into 2 slides, one with 5 elements and one of 4 elements. I'll look around for the previous post but in the mean time I think I will stick with method 0. To summarise the previous post (i.e. from the thread I started for this bug), all you have to do is simply include the following on any slide for which you want frame breaks: --8---cut here---start-8--- * A long frame with breaks :PROPERTIES: :BEAMER_opt: allowframebreaks,label= :END: --8---cut here---end---8--- Method 0 is, in principle, desirable, but I actually find that beamer does a really nice job on automatic frame breaks in most cases and it makes writing some types of presentations much easier! An example, from my own usage, is the solution to some example problem when teaching. I can simply write down all the steps, e.g. as an enumerated list, and let beamer worry about the breaks. Using automatic frame breaks, for me, is just the obvious extension of org (or LaTeX): let me worry about the content and let the system worry about the formatting! From LyX: what you see is what you mean :-)
Re: [O] Babel #+CALL: results?
Oops; forgot to reply-all. Aaron's advice did set me straight, and #+CALL: is working fine for me now without my ill-advised debugging artifacts. Thanks to Aaron for the assistance, and to the Org list/maintainers for all the great Org tools and documentation. Phil - Original Message - From: Aaron Ecay aarone...@gmail.com To: Phil Regier preg...@ittc.ku.edu, emacs-orgmode@gnu.org Sent: Tuesday, November 12, 2013 5:13:34 PM Subject: Re: [O] Babel #+CALL: results? Hi Phil, I’m far from an expert myself, but I think I see what is going on with your testcases. 2013ko azaroak 12an, Phil Regier-ek idatzi zuen: [...] *Once* I got output, but I could not reproduce this after making and undoing a few formatting changes; I would chalk this up to my own cluelessness, except that I can get what I *think* is statefully incorrect output from the first block: Iteration 1 (control case): Begin with only the #+NAME: ... #+END_SRC with :results verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun : Var1: Val1 So far, as expected. Iteration 2: Replace :results output verbatim with :results output raw and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output raw echo Var1: $Var1 #+END_SRC #+RESULTS: testfun Var1: Val1 Also as expected. Iteration 3: Change back to :results output verbatim and execute block to get #+NAME: testfun #+BEGIN_SRC sh :var Var1=Val1 :results output verbatim echo Var1: $Var1 #+END_SRC #+RESULTS: testfun =Var1: Val1 =Var1: Val1 Now org would like to remove the previous output. However, it cannot do so, since it does not know where it begins and ends (since raw output could contain in principle anything, or nothign at all). It’s best to use “drawer” instead of “raw” in most cases, because the drawer wrapper bounds the result and lets subsequent calls see it and remove it. Without removing the previous result, org tries to add the “Var1: Val1” as verbatim text (before the instance of that text which is left over from the previous call). It looks like even though there is a newline in the string org chooses to use the single-line =verbatim= syntax, rather than the multiline : verbatim I don’t know why it does this, and it may be a bug. As for your original example: #+CALL: testfun[:results output](Var1=Val3) :results output verbatim You don’t need the second :results output. That applies to an invisible elisp source block which wraps the evaluation of the #+call line, and which produces no output. I get the right result consistently with #+CALL: testfun(Var1=Val3) #+RESULTS: : Var1: Val3 Or (note the addition of quotes in the result): #+CALL: testfun(Var1=Val3) :results verbatim #+RESULTS: : Var1: Val3 -- Aaron Ecay
[O] org-insert-heading
Aloha all, With the following Org mode file, there is a dead space where org-insert-heading doesn't do anything. In the following example, if the point is on either of the empty lines marked [dead space] no heading is created. Is this behavior intended? * Folded heading ... [dead space] [dead space] * Heading All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
[O] [PATCH] org-collector: enable specifying a default table-value as a parameter
Currently there isn't an easy way to have default cell values which differ from one propview block to another. This patch enables one to specify what a cell's default value for a block should be. For example, with this patch applied, you can do something like: #+BEGIN: propview :id mytable :defaultval :cols (PROP1 PROP2 PROP3) in order to make the default value for this block to be instead of 0. * contrib/lisp/org-collector.el (org-dblock-write:propview): if a 'defaultval' property has been set, then use this in place of org-propview-default-value. TINYCHANGE --- contrib/lisp/org-collector.el | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/contrib/lisp/org-collector.el b/contrib/lisp/org-collector.el index 60b9069..d62a462 100644 --- a/contrib/lisp/org-collector.el +++ b/contrib/lisp/org-collector.el @@ -121,6 +121,7 @@ preceeding the dblock, then update the contents of the dblock. (scope (plist-get params :scope)) (noquote (plist-get params :noquote)) (colnames (plist-get params :colnames)) + (defaultval (plist-get params :defaultval)) (content-lines (org-split-string (plist-get params :content) \n)) id table line pos) (save-excursion @@ -133,9 +134,10 @@ preceeding the dblock, then update the contents of the dblock. (t (error Cannot find entry with :ID: %s id (unless (eq id 'global) (org-narrow-to-subtree)) (setq stringformat (if noquote %s %S)) - (setq table (org-propview-to-table - (org-propview-collect cols stringformat conds match scope inherit -(if colnames colnames cols)) stringformat)) + (let ((org-propview-default-value (if defaultval defaultval org-propview-default-value))) + (setq table (org-propview-to-table +(org-propview-collect cols stringformat conds match scope inherit + (if colnames colnames cols)) stringformat))) (widen)) (setq pos (point)) (when content-lines
[O] Lisp code blocks fail
Aloha all, With a recent pull, Lisp code blocks that I'm fairly certain were working previously started to fail. There is a backtrace below. The Lisp code executes correctly, but Babel doesn't appear to get the results in the form it expects (if I'm reading the backtrace correctly). Have I mucked up somehow? Debugger entered--Lisp error: (wrong-type-argument listp ((\t2\ \b\))) byte-code(\211A@)\207 [result x] 2) org-babel-execute:lisp((unless (boundp '*cycle-graph*)\n(defvar *cycle-graph*))\n(setq *cycle-graph* (populate (make-instance 'digraph)))\n(let ((r)\n (flag))\n (dolist (e edges r)\n(add-edge *cycle-graph*\n (list (read-from-string (first e))\n (read-from-string (second e\n(when (and (not flag) (setf flag (cycles *cycle-graph*))) (push e r ((:comments . ) (:shebang . ) (:cache . no) (:padline . ) (:noweb . yes) (:tangle . no) (:exports . code) (:results . silent) (:var edges (t1 a) (a t2) (b t1) (t2 b)) (:colnames . yes) (:hlines . no) (:session . none) (:result-type . value) (:result-params silent) (:rowname-names) (:colname-names (edges older younger org-babel-execute-src-block(nil) org-babel-execute-src-block-maybe() org-babel-execute-maybe() org-babel-execute-safely-maybe() run-hook-with-args-until-success(org-babel-execute-safely-maybe) org-ctrl-c-ctrl-c(nil) ad-Orig-call-interactively(org-ctrl-c-ctrl-c nil nil) (with-no-warnings (ad-Orig-call-interactively function record-flag keys)) (setq ad-return-value (with-no-warnings (ad-Orig-call-interactively function record-flag keys))) (let ((ido-ubiquitous-next-override (ido-ubiquitous-get-command-override function))) (setq ad-return-value (with-no-warnings (ad-Orig-call-interactively function record-flag keys (ido-ubiquitous-with-override (ido-ubiquitous-get-command-override function) (setq ad-return-value (with-no-warnings (ad-Orig-call-interactively function record-flag keys (let (ad-return-value) (ido-ubiquitous-with-override (ido-ubiquitous-get-command-override function) (setq ad-return-value (with-no-warnings (ad-Orig-call-interactively function record-flag keys ad-return-value) call-interactively(org-ctrl-c-ctrl-c nil nil) All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
[O] C-c ' and mail sources
Hi, Org people. Just observing this little nit. If I insert an email message (copy and pasted from Gnus in my case) within: #+BEGIN_SRC mail #+END_SRC the header lines of the message are highlighted with a reasonable set of colors. However, with the cursor within the message, I hid C-c ' twice, this has the effect of shifting the inserted message two columns to the right, the highlighting of the header is then lost. Not a big problem, and I expect that someone on this list will reply that this is an Org limitation (a way to say that the bug is innocuous enough to not deserve a correction). I rather use the word limitation for a bug which has been documented :-). In any case, this is a bug. I do not know what would be the reasonable way to correct it: preventing the shifting, or changing how highlighting interpret beginning of lines, in case of Org? François
Re: [O] Babel: the disappearing hline
Rick Frankel r...@rickster.com writes: Greetings again. Again, the solution is to globally set the :hline property to =yes= instead of the default =no=, and you will get the results you want. The issue I am trying to raise here is the consistency of the system, not the way to solve this particular problem. Personally I think it would be clearer if the handling of hlines in _output_ were consistent _by default_, regardless of whether the call is made by direct evaluation of a block; by a post(); or by a #+CALL. I found it very weird when I bumped into this discrepancy - in a much more complicated context than the examples I have shown here. But it is your system and you know what kind of qualities you want it to have. I am just learning the ropes and sending you a message from the trenches. All the best, Jarmo
