Re: [O] Inconsistency in odt export to other exporters
The following snippet exports correctly to LaTeX and to html, but produces the text Figure Figure in odt. Fixed.
Re: [O] Organizing by time or by subject and an idea
Max Mikhanosha m...@openchat.com writes: At Fri, 20 Jan 2012 12:04:51 -0600, John Hendy wrote: [...] Generally I think the way to tackle this is to take advantage that you are working with plain text and not with Word document, and use standard Emacs/Unix tools for working with text. Agreed! Some ideas: Before updating each project, cut-n-paste it into the new revision.. Org mode makes it easy to cut-n-paste trees, for myself duplicating a headline is simply pressing Y then P over a folded headline (viper/vimpulse user) Is it not easier to simply make use of any of the revision control systems (git, mercurial, svn, even RCS) that are out there? You can easily tag a particular revision based on milestones and then see diffs between the current content and any previous version. In terms of the original questions, I use a combination of hierarchical structure that is filled in as a project develops, with revision control to allow me to see progress, together with a log based recording of activities (e.g. meetings, deliverables delivered, issues raised). That is, I mix both of the approaches mentioned by John in his initial email. The key, as John has already stated, is to record everything! With emacs, I can usually pull out what I want *if* the information was recorded in the first place. Finally, tags can be very useful for quick searching as well. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.192.g32af)
Re: [O] Capitalisation and good taste ?
Bernt Hansen be...@norang.ca writes: Eric S Fraga e.fr...@ucl.ac.uk writes: Bernt Hansen be...@norang.ca writes: [...] I added the following to my .emacs to keep lowercase. Thanks. This is a great suggestion! Two possible typos, by the way, that would only affect you if you use muse tags: (v #+begin_verse\n?\n#+end_verse verse\n?\n/verse) (c #+begin_center\n?\n#+end_center center\n?\n/center) Missing for closing tag in each case, after last \n. I just took the default setting and lowercased it without actually looking closely at it -- so I think the problem is in the defcustom in org.el for org-structure-template-alist too. Regards, Bernt Indeed. Attached is a very simple patch to fix these missing s. Untested. diff --git a/lisp/org.el b/lisp/org.el index f6a1160..f47a104 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -11031,9 +11031,9 @@ This function can be used in a hook. (q #+BEGIN_QUOTE\n?\n#+END_QUOTE quote\n?\n/quote) (v #+BEGIN_VERSE\n?\n#+END_VERSE - verse\n?\n/verse) + verse\n?\n/verse) (c #+BEGIN_CENTER\n?\n#+END_CENTER - center\n?\n/center) + center\n?\n/center) (l #+BEGIN_LaTeX\n?\n#+END_LaTeX literal style=\latex\\n?\n/literal) (L #+LaTeX: -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.90.1 : using Org-mode version 7.8.03 (release_7.8.03.192.g32af.dirty)
Re: [O] Inconsistency in odt export to other exporters
Jambunathan K kjambunat...@gmail.com writes: The following snippet exports correctly to LaTeX and to html, but produces the text Figure Figure in odt. Fixed. Works great for me, thanks! And thanks for all these fast responses! Best, Andreas
Re: [O] [bug] Tables in lists not exported to ODT
Jambunathan K kjambunat...@gmail.com writes: Jambunathan K kjambunat...@gmail.com writes: Btw, I was trying to make the tables cute-looking Just pushed a fix whereby one can control the width of the tables. , commit f9d242 | Customize table width using :rel-width option. For example, to create a | table of width 60% use: | | #+attr_odt: :rel-width 60 | | | A | B | | |---+---| | | | | ` Thanks for this very useful feature. Works nicely for me. - Andreas
Re: [O] [bug] Tables in lists not exported to ODT
On 1/23/12 11:48 AM, Andreas Leha wrote: Jambunathan Kkjambunat...@gmail.com writes: Just pushed a fix whereby one can control the width of the tables. Thanks for this very useful feature. Works nicely for me. +1! Thanks, Christian
[O] (no subject)
From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 From: Tom Regner t...@goochesa.de Rcpt To: emacs-orgmode@gnu.org Date: Mon, 23 Jan 2012 12:39:52 +0100 Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing. At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken because the newlines before the #+end_src line are excluded from the output. This patch uses :padline to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct results; code depending on the (errorneous?) behaviour would be broken though. --- lisp/ob.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 47be708..398a997 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2211,13 +2211,16 @@ block but are passed literally to the \example-block\. (nth 4 i)) source-name) (let* ((body (org-babel-expand-noweb-references i)) -(full (if comment +(padded (if (not (string= no (cdr (assoc :padline (nth 2 i) + (concat body \n) + body )) +(full (if comment ((lambda (cs) (concat (c-wrap (car cs)) \n - body \n + padded \n (c-wrap (cadr cs (org-babel-tangle-comment-links i)) -body))) +padded))) (setq expansion (concat expansion full expansion) ;; possibly raise an error if named block doesn't exist -- 1.7.5.4
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
[...]
As a side note, #+label has been deprecated in favor of #+name (though
the former is immediately translated into the latter at parse time).
Sorry for hijacking this thread. But this side note is only valid for
the new exporter, correct? As it does not yield the expected result in
the current LaTeX and odt exporter (the only ones I tried).
== test.org ===
* Test name
#+caption: Test name
#+name: testname
#+begin_src R :exports results :results graphics :file foo.png
plot(1)
#+end_src
As can be seen in Figure \ref{testname}...
As can be seen in Figure [[testname]]
#+caption: Test name 2
#+label: testnametwo
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnametwo}...
As can be seen in Figure [[testnametwo]]
#+caption: Test name 3
#+label: testnamethree
#+name: testnamethree
#+begin_src R :exports results :results graphics :file bar.png
plot(1)
#+end_src
As can be seen in Figure \ref{testnamethree}...
As can be seen in Figure [[testnamethree]]
===
Best,
Andreas
[O] C-a in lists when org-special-ctrl-a/e
Hi, Org people. This morning, I activated org-special-ctrl-a/e (setting it to t). It works as documented on header lines having TODO keywords. On check lists however, I would have expected a corresponding behavior. Currently, on the first C-a, the cursor moves back on the [ character, while I think it should move after the space following ]. François
[O] [PATCH] narrowing in agenda file
Narrowing in the agenda file does not survive agenda redo. Please see an example in the first patch. I think the second patch fixes this problem. From 60ef46625131391c6a49fccd26861f933a984515 Mon Sep 17 00:00:00 2001 From: Litvinov Sergey slitvi...@gmail.com Date: Mon, 23 Jan 2012 14:22:53 +0100 Subject: [PATCH 1/2] Add a test narrowed agenda file --- testing/examples/org-agenda-test.org | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 testing/examples/org-agenda-test.org diff --git a/testing/examples/org-agenda-test.org b/testing/examples/org-agenda-test.org new file mode 100644 index 000..ecd00e5 --- /dev/null +++ b/testing/examples/org-agenda-test.org @@ -0,0 +1,10 @@ +#+Title: a collection of examples for org-agenda tests +* TODO should be visible +ob-agenda-test.org buffer should be narrowed after execution of this block +#+BEGIN_SRC elisp :results silent + (let ((org-agenda-files (list buffer-file-name))) +(narrow-to-region 1 (- (buffer-size) 23)) +(org-agenda nil t) +(org-agenda-redo)) +#+END_SRC +* TODO should be hidden -- 1.7.3.4 From 188d95624fec5d53403fd705679167ed7d7345a2 Mon Sep 17 00:00:00 2001 From: Litvinov Sergey slitvi...@gmail.com Date: Mon, 23 Jan 2012 14:26:14 +0100 Subject: [PATCH 2/2] Make narrowing of the agenda file survive (org-agenda-redo) * lisp/org.el (org-prepare-agenda-buffers): move '(save-excursion (save-restriction' construction --- lisp/org.el | 67 +-- 1 files changed, 33 insertions(+), 34 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index f6a1160..9e23c18 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -16498,47 +16498,46 @@ When a buffer is unmodified, it is just killed. When modified, it is saved (inhibit-read-only t) (rea (concat : org-archive-tag :)) bmp file re) -(save-excursion - (save-restriction (while (setq file (pop files)) (catch 'nextfile (if (bufferp file) (set-buffer file) (org-check-agenda-file file) (set-buffer (org-get-agenda-file-buffer file))) - (widen) - (setq bmp (buffer-modified-p)) - (org-refresh-category-properties) - (setq org-todo-keywords-for-agenda - (append org-todo-keywords-for-agenda org-todo-keywords-1)) - (setq org-done-keywords-for-agenda - (append org-done-keywords-for-agenda org-done-keywords)) - (setq org-todo-keyword-alist-for-agenda - (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) - (setq org-drawers-for-agenda - (append org-drawers-for-agenda org-drawers)) - (setq org-tag-alist-for-agenda - (append org-tag-alist-for-agenda org-tag-alist)) - (save-excursion - (remove-text-properties (point-min) (point-max) pall) - (when org-agenda-skip-archived-trees - (goto-char (point-min)) - (while (re-search-forward rea nil t) - (if (org-at-heading-p t) - (add-text-properties (point-at-bol) (org-end-of-subtree t) pa - (goto-char (point-min)) - (setq re (format org-heading-keyword-regexp-format - org-comment-string)) - (while (re-search-forward re nil t) - (add-text-properties - (match-beginning 0) (org-end-of-subtree t) pc))) - (set-buffer-modified-p bmp) -(setq org-todo-keywords-for-agenda - (org-uniquify org-todo-keywords-for-agenda)) -(setq org-todo-keyword-alist-for-agenda - (org-uniquify org-todo-keyword-alist-for-agenda) - org-tag-alist-for-agenda (org-uniquify org-tag-alist-for-agenda + (save-restriction + (widen) + (setq bmp (buffer-modified-p)) + (org-refresh-category-properties) + (setq org-todo-keywords-for-agenda + (append org-todo-keywords-for-agenda org-todo-keywords-1)) + (setq org-done-keywords-for-agenda + (append org-done-keywords-for-agenda org-done-keywords)) + (setq org-todo-keyword-alist-for-agenda + (append org-todo-keyword-alist-for-agenda org-todo-key-alist)) + (setq org-drawers-for-agenda + (append org-drawers-for-agenda org-drawers)) + (setq org-tag-alist-for-agenda + (append org-tag-alist-for-agenda org-tag-alist)) + (save-excursion + (remove-text-properties (point-min) (point-max) pall) + (when org-agenda-skip-archived-trees + (goto-char (point-min)) + (while (re-search-forward rea nil t) + (if (org-at-heading-p t) + (add-text-properties (point-at-bol) (org-end-of-subtree t) pa + (goto-char (point-min)) + (setq re (format org-heading-keyword-regexp-format + org-comment-string)) + (while (re-search-forward re nil t) + (add-text-properties + (match-beginning 0) (org-end-of-subtree t) pc))) + (set-buffer-modified-p bmp) + (setq org-todo-keywords-for-agenda + (org-uniquify org-todo-keywords-for-agenda)) + (setq org-todo-keyword-alist-for-agenda + (org-uniquify org-todo-keyword-alist-for-agenda) + org-tag-alist-for-agenda (org-uniquify
Re: [O] typo in doc/orgguide.texi
Hi Guido, Guido Arnold watsoll...@googlemail.com writes: Hello, please forgive me for not filing a proper bug report, I am not even a org-mode user yet, but I am very interested. I just had a look at the quick guide and found a typo in line 1908: http://orgmode.org/w/?p=org-mode.git;a=blob;f=doc/orgguide.texi;h= 0e6295a121a6ac0b2eb8738c1156f2672c24548d;hb=minted s/will also works/will also work/ ^ I hope someone with write privileges on this list can fix this. Fixed, thanks! http://orgmode.org/w/?p=org-mode.git;a=commit;h=8a7799473c90e71bff460c63a71e7551dfa4e4e2 -- Bastien
[O] Prompts for C-. and
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
#+CAPTION[An example photograph]: An example photograph.
#+NAME: fig:photo
for me, yields:
\caption{\label{fig:photo}An example photograph}
I was expecting:
\caption[An example photograph]{\label{fig:photo}An example
photograph}
I get the expected caption command in that case, even from a fresh emacs
-q. You may need to reload Org, or even Emacs.
Regards,
Thanks, that worked.
The file name passed to \includegraphics is formed like this:
~/path/to/graphics/file
My LaTeX doesn't recognize this as a path.
The old exporter passed a file name where the tilde was expanded:
/Users/user/path/to/graphics/file
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] Prompts for `C-c .' and `C-c !'
Hi, Org people! :-) Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insert DATE, the other [DATE]. The mini-buffer always show DATE, like this: Date+time [2012-01-23]: = 2012-01-23 lun Could it be: Date+time [2012-01-23]: = [2012-01-23 lun] when appropriate? This feedback would be useful (to me at least), in case I mixed `C-c .' and `C-c !' in my head, and am using the wrong one. François
[O] Why functions like org-show-subtree are undocumented?
Hi all, I just reviewed code in org.el and noticed that function org-show-subtree, which is called by org-cycle, unconditionally shows whole subtree (exactly what I wanted to have in my shortcuts!). So the question is - why such useful functions like org-show-subtree, hide-subtree, show-children aren't documented in manual? Because of that, previously I thought that what I wanted was impossible (without source change). Thanks
Re: [O] Side-by-side support
Hello Christian Christian Wittern cwitt...@gmail.com writes: On 2012-01-20 05:03, Jambunathan K wrote: side-by-side has surfaced in the list for the second time, I think it deserves to be supported out of the box. I strongly support this, since I have a lot of files with side-by-side content. The first question is of course how does the org source look like. I think laying out tables either list tables (or for that matter, it's beamer equivalent) will become particularly inconvenient to edit. In both the cases, the two-dimensional structure is laid out along the single-dimension and it would become difficult to remember which column or row when one is editing at a given point in time. In my case, I have simply separated the columns by a tab character and set the tab-width to a sensible value for nice on-screen display. These are 'text' and 'translation of that text' side-by-side, When you are saying on-screen display, I presume you are referring to the Emacs screen? I have a strong feeling that you are using two column editing. Otherwise, it would be extremely difficult to keep one's sanity. See C-h k C-x 6 2 (info (emacs) Two-Column). I have a wild-thought. Why not use use 2C editing for creating multi-paragraph Org tables. I am Ccing Nicolas (who is likely to have thought more about this stuff) since the last conversation. sometimes interrupted by section headers, notes and so on. Therefore I end up with multiple 'tables', which will need to have the same width throughout the document. Therefore for this use-case, I would like to see a global setting for the relative width of these columns. --
Re: [O] (no subject)
Tom Regner t...@goochesa.de writes: From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 From: Tom Regner t...@goochesa.de Rcpt To: emacs-orgmode@gnu.org Date: Mon, 23 Jan 2012 12:39:52 +0100 Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing. [...] I'm awfully sorry -- shall I remail the patch without the errorneous empty line in between the headers, so that the patchwork server will receive it? kind regards, Tom
Re: [O] C-a in lists when org-special-ctrl-a/e
Hello, pin...@iro.umontreal.ca (François Pinard) writes: On check lists however, I would have expected a corresponding behavior. Currently, on the first C-a, the cursor moves back on the [ character, while I think it should move after the space following ]. According to the documentation: In an item, this will be the position after the bullet. Thus, that behaviour seems correct to me. Note that check-boxes are not part of the bullet (text is indented below them on second line of an item). Regards, -- Nicolas Goaziou
Re: [O] org-e-latex remove logfiles
Hello, t...@tsdye.com (Thomas S. Dye) writes: The documentation string for org-e-latex-remove-logfiles might better be: Non-nil means remove files with the extensions listed in org-e-latex-extensions. I think that the first sentence of the doc-string should be a tad bit shorter. In an attempt to split it, what about something like: Non-nil means remove some files created during PDF export. Any file whose extension is listed in `org-e-latex-extensions' will be deleted. Regards, -- Nicolas Goaziou
Re: [O] Prompts for `C-c .' and `C-c !'
pin...@iro.umontreal.ca (François Pinard) writes: Hi, Org people! :-) Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insert DATE, the other [DATE]. The mini-buffer always show DATE, like this: Date+time [2012-01-23]: = 2012-01-23 lun Could it be: Date+time [2012-01-23]: = [2012-01-23 lun] when appropriate? This feedback would be useful (to me at least), in That's probably not worth the effort. If you use the wrong one just put point on the [ or and hit S-up arrow to switch it. Regards, Bernt
Re: [O] customize agenda time boundaries
sergio mail...@sergio.spb.ru writes: On 01/23/2012 07:17 AM, Bernt Hansen wrote: (setq org-agenda-start-on-weekday nil) C-c a a j -3 w OK, it works. But it's complicated and week was just an example. How to do the same for 3 days? For one day (show 12 hours before, and 12 after the current moment)? I don't know. You might be able to use org-agenda-span to accomplish some of this. Regards, Bernt
Re: [O] C-a in lists when org-special-ctrl-a/e
Nicolas Goaziou n.goaz...@gmail.com writes: pin...@iro.umontreal.ca (François Pinard) writes: On check lists however, I would have expected a corresponding behavior. Currently, on the first C-a, the cursor moves back on the [ character, while I think it should move after the space following ]. According to the documentation: In an item, this will be the position after the bullet. Thus, that behaviour seems correct to me. Note that check-boxes are not part of the bullet (text is indented below them on second line of an item). The text says: When t, `C-a' will bring back the cursor to the beginning of the headline text, i.e. after the stars and after a possible TODO keyword. In an item, this will be the position after the bullet. It all depends if we read the letter or the spirit of the second sentence. [ ] is a kind of TODO, and [X] is a kind of DONE, as demonstrated by the commands `C-x -' and `C-x *'. That's why I quite naturally expect the cursor to be positioned after the check box. This is of course all debatable. I think the spirit and usefulness of org-special-ctrl-a/e would be better guaranteed, if the behavior was amended. François
Re: [O] [PATCH] narrowing in agenda file
Litvinov Sergey slitvi...@gmail.com writes: Narrowing in the agenda file does not survive agenda redo. Please see an example in the first patch. I think the second patch fixes this problem. Hi Sergey, I haven't had a chance to try your patch yet but I recently tried to fix this behaviour as well but there are other issues that crop up when you keep the narrowed region. Please make sure that at least the following work as expected with your patch: - org agenda clock reports are correct - You don't have the LOGBOOK drawer aligned with tags when clocking in from the agenda (this was with emacs -q (no org-indent-mode) - Column view in the agenda shows correct clocking amounts for each task - Visiting a task with RET or SPC goes to the task when outside the narrowed region - Remote editing of a task outside the narrowed region changes the target task and not something in your narrowed region instead I'm hoping your patch works since I also want this desired behaviour but so far my attempts to achieve this failed miserably :( Regards, Bernt
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Leo Alekseyev dnqu...@gmail.com writes: Since all source blocks are evaluated on export, I don't think it should be necessary to issue org-babel-execute-buffer before invoking export. However, running HTML export without org-babel-execute-buffer currently produces garbage output. What do you mean by garbage output? On the other hand, I have several examples where running HTML export _after_ org-babel-execute-buffer produces the wrong output due to the fact that :results replace directive appears to append instead of replacing the output Could you isolate a minimal example demonstrating just the failure of results replacement? Thanks, I am attaching three simple examples where I simulate generating and exporting image data (I just generate and print filenames). If I understand the documentation correctly, they are all supposed to produce identical output on HTML export; however, none of the files produces the expected output, namely, blocks of the form: | some output | images/conv1.png | | images/conv1.png \-- Here, the first two lines should be enclosed in a code block, and the last line should be raw org output. To reproduce, load any of my examples, do C-c C-e h - will produce garbage output on export C-c C-v b - will produce expected output in the buffer C-c C-e h - will produce extraneous output on export despite :results replace being on C-c C-v b - will produce extraneous output in the buffer This was tested on my test-export4.org, but the other examples behave in a similar fashion. --Leo -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] org-babel functions for Io evaluation
Hi Andrzej, This looks wonderful, thanks for sharing! Would you be willing to complete the FSF copyright assignment [1] so that we can include this into the Org-mode core? If that is not possible then we could still distribute this in the contrib directory, but inclusion in the core is definitely preferable. Many Thanks, Andrzej Lichnerowicz unje...@gmail.com writes: Hello list. Attached file (also available at https://gist.github.com/1652684), implements org-babel evaluation functions for Io language (http://iolanguage.org). It's not yet fully functional (no value results, and session support) as I'm still learning org-mode from developer perspective, but if you're interested, I'd be happy to contribute it. Best regards, Andrzej Footnotes: [1] http://orgmode.org/worg/org-contribute.html -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] How to include comments on export? org-exp-blocks.el?
There are currently begin/end_comment blocks implemented as part of org-exp-blocks.el. See the `org-export-blocks-format-comment' function which is fairly simple and should not be difficult to customize. Best, Samuel Wales samolog...@gmail.com writes: We had a wonderful discussion of it once, along with different possible uses for inline tasks, inclusion of paragraphs, non-exported headlines for easier structure editing, universal syntax, and returning text to higher level. On my blog I use a colored background, which could also serve as comment blocks: #+HTML: div style=color: black; background-color: burlywood Some text. #+HTML: /div A bit rudimentary perhaps. Samuel On 2011-10-24, Herbert Sitz hes...@gmail.com wrote: I'm trying to see if there is a way to include comments on export, to show up as something like the comments boxes you see in MS Word. I see Eric Schulte did some work on this and that somehow it ended up (I think) as part of what you could do using the org-exp-blocks addon. But I'm not sure how you actually use it. Can someone give an example of how org-exp-blocks (or anything else) could be used to export comment blocks as graphic notes in the text? Thanks, Herb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)
Have you tried using the `org-babel-noweb-error-langs' variable that I mentioned previously? It should help in these situations. Yu yu_...@gmx.at writes: Hello again! I thought about the *noweb* part again. I tried the following: == #+begin_src sh :tangle test.out :noweb tangle task1 cat test.org test.out2 #+end_src #+begin_src sh :noweb-ref task1 echo hello world #+end_src == The tangled output file test.out looked like this: == /bin/sh echo hello world cat test.out2 == i.e. the syntactically valid test.org construct was omitted. Thus a separate syntax for forcing a literal in the tangled output is needed anyway (if not yet implemented) and if so, warning about undefined code blocks should be possible too. The big relevance of warning about undefined and never used code blocks struck me, when recently I tried to use it again. The natural work flow to me would have been to write something like : The task at hand has an overall structure : #+begin_src python :tangle foo.py :noweb tangle : read the data : generate derived information : output the results : #+end_src When proceeding after this however I would have to keep in mind open tasks or (slightly better) to instantly create TODO sections for said blocks. However, having this order of working imposed on me sort of defeats the purpose for my understanding. I'd rather prefer to do an `M-x org-babel-tangle' tell me, that I forgot to implement one of the partial tasks, rather than having to find out missing code blocks from the output file (where, as mentioned, they result in nothing rather than an unresolved ... construct). kind regards, Yu 2012/1/14 Eric Schulte eric.schu...@gmx.com: Yu yu_...@gmx.at writes: Hello! I was wondering, if there is a way to get warnings for typos (e.g. when specifying invalid properties or header arguments). It can just easily happen that I mix up e.g. :exports and :export (though that's probably a very harmless example). While there is currently no way to do this there are two related functions which should help. ,[org-babel-view-src-block-info] bound to C-c C-v I | org-babel-view-src-block-info is an interactive Lisp function in | `ob.el'. | | (org-babel-view-src-block-info) | | Display information on the current source block. | This includes header arguments, language and name, and is largely | a window into the `org-babel-get-src-block-info' function. ` and ,[org-babel-check-src-block] bound to C-c C-v c | org-babel-check-src-block is an interactive Lisp function in `ob.el'. | | (org-babel-check-src-block) | | Check for misspelled header arguments in the current code block. ` This problem is not trivial because new language are permitted to create and use *any* header arguments they like, so there are no /wrong/ header arguments, there are only /suspicious/ header arguments (like the :exports option you suggest). The above function reports any suspicious header arguments. Perhaps there would be a way to integrate the above function with flyspell for automatic highlighting of suspicious header arguments. I'll put looking into such integration on my long-term Org task queue. More important it gets though, when trying to use the literate programming facilities. Say I have a source code #+begin_src sh :noweb tangle :tangle foo.sh foo #+end_src #+begin_src sh :noweb-ref fo echo '... how are you?'; #+end_src then tangling would run through without any indication of the typo in the name of the foo block. Such errors might be hard to debug, because there is no indication of the error, maybe nothing other than runtime errors. An error message for the /use/ of undefined references only wouldn't avoid such problems either, e.g. consider #+begin_src sh :noweb tangle :tangle foo.sh foo #+end_src #+begin_src sh :noweb-ref foo echo 'Hello World...'; #+end_src #+begin_src sh :noweb-ref fo echo 'Hello World...'; #+end_src where the only detectable error is, that fo was never used anywhere. A similiar question (though without the second part) was asked here: http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00273.html As far as I can tell, it stands unanswered. Yes, although in many languages constructs like foo are valid code, so it would be inappropriate for tangling to raise errors by default. It is possible to turn on such errors on a language-by-language basis, by customizing the following variable. ,[org-babel-noweb-error-langs] | org-babel-noweb-error-langs is a variable defined in `ob.el'. | Its value is nil | | Documentation: | Languages for which Babel will raise literate programming errors. | List of languages for which errors should be raised when the | source code block
Re: [O] Syntax error warnings? (Especially important with :noweb-ref's)
Fixed. Thanks, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: there are two related functions which should help. ,[org-babel-view-src-block-info] bound to C-c C-v I | org-babel-view-src-block-info is an interactive Lisp function in | `ob.el'. | | (org-babel-view-src-block-info) | | Display information on the current source block. | This includes header arguments, language and name, and is largely | a window into the `org-babel-get-src-block-info' function. ` and ,[org-babel-check-src-block] bound to C-c C-v c | org-babel-check-src-block is an interactive Lisp function in `ob.el'. | | (org-babel-check-src-block) | | Check for misspelled header arguments in the current code block. ` When checking for suspicious header arguments on[1]: #+name: mean #+begin_src emacs-lisp :var lst=() (let ((num (car lst)) (nums (cdr lst))) (/ (float (+ num (apply #'+ nums))) (1+ (length nums #+end_src it reports: supplied header var is suspiciously close to dir Can you enlighten me on what's suspicious here? Best regards, Seb Footnotes: [1] which is supposed to be used in the following table: | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 3.5 | #+TBLFM: @7$1='(sbe mean (lst @1..@6)) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] org-babel order of evaluation
Leo Alekseyev dnqu...@gmail.com writes: On Thu, Jan 12, 2012 at 7:52 PM, Rick Frankel r...@rickster.com wrote: On Thu, Jan 12, 2012 at 06:07:41PM -0700, Eric Schulte wrote: Rick Frankel r...@rickster.com writes: Turns out it was not that difficult to change this behavior. You and Leo are both correct that in-buffer-order evaluation is more natural and expected than the previous behavior. I've just pushed up a fix after which evaluating the following Eric, The fix doesn't seem to be working for me when I export the buffer to HTML. My previous fix only set the order of evaluation for interactive buffer evaluation. I've just pushed up another fix which sets the order of evaluation during export. Best, The ordering of call and source blocks once again becomes randomized, and in general, exported file is missing a bunch of stuff unless I run org-babel-execute-buffer prior to export. Since the export engine does its own evaluation, it doesn't seem like org-babel-execute-buffer should be a necessity. But I can't run org-babel-execute-buffer on anything with a src_language inline block as it gives me an error. I'm attaching two files which do not export correctly, at least when one doesn't run org-babel-execute-buffer; just do C-c C-e h and look at the output. --Leo -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] ASCII back-end for new export engine
t...@tsdye.com (Thomas S. Dye) writes: The file name passed to \includegraphics is formed like this: ~/path/to/graphics/file My LaTeX doesn't recognize this as a path. The old exporter passed a file name where the tilde was expanded: /Users/user/path/to/graphics/file It should be fixed now. Thank you. Regards, -- Nicolas Goaziou
[O] Absolute paths in exported files
Hello!
An older topic was here:
http://lists.gnu.org/archive/html/emacs-orgmode/2010-01/msg00573.html
The problem seems to persist as of now for latex (and thus pdf)
export. The results are sort of diffuse though.
I am working with emacs on Cygwin using the latest git-version and
native Windows Adobe Reader and Sumatra PDF as PDF Viewers.
* Apparently [[file:file]] is exported as
\href{file://.file}{file:file} (note the extra period)
* The same happens with [[./file]] and other local paths like
[[file:plots/somefile.pdf]]
* For some reason sometimes relative paths get exported as absolute paths.
Examples:
[[file:/labbook.org]] = \href{file://./labbook.org}{file:/labbook.org}
[[./labbook.org]] = \href{file:///absolute/path/to/labbook.org}{./labbook.org}
[[./plot/test.plt]] = \href{file://../plot/test.plt}{./plot/test.plt}
[[/labbook.org]] = \href{file://./labbook.org}{/labbook.org}
In another org file:
[[./local.plt]] = \href{file://../local.plt}{./local.plt}
[[file:local.org]] = \href{file://.local.org}{file:local.org}
[[./local.org]] = \href{file://../local.org}{./local.org}
Also:
* file://relative/path - style urls fail to be opened (adobe reader
passes it to the browser, the browser treats it as absolute path).
Might also be related to the windows environment, but a PDF should be
portable anyway.
* Researching the problem, I read that hyperref's \href doesn't
support relative paths to begin with.
Any ideas? It works well for html export and for use within the
org-mode buffer, but it would be nice if the links in the PDF file
could support local files properly too (though I'm not sure if the
viewers even support this).
kind regards, Yu
Re: [O] Prompts for `C-c .' and `C-c !'
Hi ! If I understood well, I think that the difference between C-c . and C-c ! is that the timestamp is active or not. DATE is an active date that appear in agenda view. So you have ti use it if you want to see the task scheduled or deadlined. [DATE] format does not allow the timestamp to interact with agenda view. It is used to indicate date just for information. Lolo Le 23/01/2012 17:01, François Pinard a écrit : Hi, Org people! :-) Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insertDATE, the other [DATE]. The mini-buffer always showDATE, like this: Date+time [2012-01-23]: = 2012-01-23 lun Could it be: Date+time [2012-01-23]: = [2012-01-23 lun] when appropriate? This feedback would be useful (to me at least), in case I mixed `C-c .' and `C-c !' in my head, and am using the wrong one. François
Re: [O] [ODT] image scaling overridden by long caption
Hello Andreas I have added support for character anchored images as part of the following commit release_7.8.03-201-g1d99fd7. I am attaching a sample Org file and the associated ODT output. Nicolas/Eric Don't be surprised. Please Read on ... --8---cut here---start-8--- #+TITLE: side-by-side.org #+AUTHOR:Jambunathan K #+EMAIL: kjambunat...@gmail.com #+DATE: 2012-01-23 Mon #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t :t #+OPTIONS: TeX:t LaTeX:dvipng skip:nil d:nil todo:t pri:nil tags:not-in-toc #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+LINK_UP: #+LINK_HOME: #+XSLT: Nicolas, Does the existing behaviour as captured in [[Side-by-Side images laid out by hand]] be preserved with new export driver? Eric, 1. can the extraneous parbreaks in [[Side-by-Side images using Babel]] be removed? 2. Can [[http://lists.gnu.org/archive/html/emacs-orgmode/2012-01/msg00678.html][this issue with #+header lines ]] be fixed? * Side-by-Side images using Babel Creating side-by-side images with Babel is problematic. #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png #+begin_src R :exports results :results graphics plot(1:100, 1:100) #+end_src The images are vertically stacked because Babel introduces extraneous parbreaks. This forces the images to be anchored as character, but to *successive* paragraphs. Here is a segment of Org buffer as seen by the ODT exporter at the end of =org-export-preprocess-string=. #+BEGIN_SRC org ,Creating side-by-side images with Babel is problematic. ,[[file:foo.png][file:foo.png]] ,[[file:foo.png][file:foo.png]] ,The images are vertically stacked because Babel introduces extraneous ,parbreaks. This forces the images to be anchored as character, but to ,*successive* paragraphs. #+END_SRC * Side-by-Side images laid out by hand To create side-by-side images flank them with paragraph boundaries. #+BEGIN_CENTER #+caption: foo #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file foo.png [[./foo.png]] #+caption: bar #+ATTR_ODT: :width 7 :height 7 :anchor as-char #+header: :file bar.png [[./bar.png]] #+END_CENTER You should be seeing side-by-side images. --8---cut here---end---8--- side-by-side.odt Description: side-by-side.odt On a related note: Could I place two (correctly scaled) images side-by-side? For the sake of record, your request is much similar to what is discussed here http://lists.gnu.org/archive/html/emacs-orgmode/2011-12/msg00780.html - save for (dynamically-generated) images taking the place of src blocks. Try something like this: #+begin_list-table - [[./foo1.png]] - [[./foo2.png]] #+end_list-table Make sure that the images are small images. If you replace the image links above with R srcblocks or attach caption/attr_odt to the above above images, the results are less than satisfactory. So the answer to your question is a soft no. Thanks for this. For two reasons that does not work for me: (1) I want to use captions on my images (2) it is odt-export specific Notes to self: There are multiple ways to achieve side-by-side effect. - use tables (aka list tables) - use 2-Column sections - 2-column frames (what is this?) side-by-side has surfaced in the list for the second time, I think it deserves to be supported out of the box. +1. And ideally generic enough, s.t. also the LaTeX supports it. Beamer has the concept of columns, which is nicely supported in org mode. Maybe that could be a general concept supported by all (or, most) exporters? --
Re: [O] Is it possible to include #+call lines in HTML export?
Leo Alekseyev dnqu...@gmail.com writes: Currently, my org files look something like this: * And now, let's do the analysis ! #+call: foo(bar) #+results: : earth-shattering results : gonna land me a Nobel /and/ a Fields! But because #+call is not exported, it's not clear what function was called and with what parameters. It makes a lot of sense for it to be included in the export (unless its evaluation is turned off via e.g. :eval no-export), but I can't find an option for this. Currently what you describe is not possible. Call lines are by default replaced with their results on export. ... Alright, I just pushed up an addition which allows the specification of a call line export template to include information like the name of the call line used to generate the results. For example, add the following to your config and export a buffer with call lines. (setq org-babel-exp-call-line-template \n: call: %line) Best, --Leo -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [ANN] ASCII back-end for new export engine
2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. It's out of exporter's scope. I disagree. The current exporter conforms to the value of the :results header argument (e.g., silent, replace, append, etc...) when executing code blocks during export. I see no reason why the new exporter should not as well. When you ask to export some buffer, what is really parsed is a copy of the current buffer with `org-export-blocks-preprocess' applied to it. So, simply apply that function in your test buffer, and you will see what is sent to the parser. That will explain why the results appear twice. In other words, tweaking the output of `org-export-blocks-preprocess' will automatically change the outcome of the export process. Hmm, in light of this description it seems that the new export /should/ have the same behavior WRT code block execution as the current exporter. If not I wonder if a complete minimal example could be provided. Thanks, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] ob.el Adhere to current :padline header during noweb dereferencing.
At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken because the newlines before the #+end_src line are excluded from the output. This patch uses :padline to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct results; code depending on the (errorneous?) behaviour would be broken though. --- lisp/ob.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 47be708..398a997 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2211,13 +2211,16 @@ block but are passed literally to the \example-block\. (nth 4 i)) source-name) (let* ((body (org-babel-expand-noweb-references i)) -(full (if comment +(padded (if (not (string= no (cdr (assoc :padline (nth 2 i) + (concat body \n) + body )) +(full (if comment ((lambda (cs) (concat (c-wrap (car cs)) \n - body \n + padded \n (c-wrap (cadr cs (org-babel-tangle-comment-links i)) -body))) +padded))) (setq expansion (concat expansion full expansion) ;; possibly raise an error if named block doesn't exist -- 1.7.5.4
Re: [O] (no subject)
I'd rather not change the default silently in this way. Could you provide a minimal example of the difference you describe? I just tried viewing the expanded form of the following code block and saw no difference between :noweb-ref and normal #+name: based expansions. * examples #+name: first #+begin_src sh echo 1 #+end_src #+begin_src sh :noweb-ref second echo 2 #+end_src #+begin_src sh :noweb yes first second #+end_src Thanks, Tom Regner t...@goochesa.de writes: From aea3adc952de33aa9acad94fbd9baa717b7b1a1e Mon Sep 17 00:00:00 2001 From: Tom Regner t...@goochesa.de Rcpt To: emacs-orgmode@gnu.org Date: Mon, 23 Jan 2012 12:39:52 +0100 Subject: [PATCH] ob.el Adhere to current :padline header during noweb dereferencing. At the moment using the :noweb-ref: property approach on subtrees results in the tangled code beeing broken because the newlines before the #+end_src line are excluded from the output. This patch uses :padline to check if a newline should be added. The default being yes, tangling with subtree mangling now produces correct results; code depending on the (errorneous?) behaviour would be broken though. --- lisp/ob.el |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 47be708..398a997 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -2211,13 +2211,16 @@ block but are passed literally to the \example-block\. (nth 4 i)) source-name) (let* ((body (org-babel-expand-noweb-references i)) - (full (if comment + (padded (if (not (string= no (cdr (assoc :padline (nth 2 i) + (concat body \n) + body )) + (full (if comment ((lambda (cs) (concat (c-wrap (car cs)) \n - body \n + padded \n (c-wrap (cadr cs (org-babel-tangle-comment-links i)) - body))) + padded))) (setq expansion (concat expansion full expansion) ;; possibly raise an error if named block doesn't exist -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] C-a in lists when org-special-ctrl-a/e
pin...@iro.umontreal.ca (François Pinard) writes: It all depends if we read the letter or the spirit of the second sentence. [ ] is a kind of TODO, and [X] is a kind of DONE, as demonstrated by the commands `C-x -' and `C-x *'. That's why I quite naturally expect the cursor to be positioned after the check box. Ok, then, let's read the spirit. I've implemented this behaviour in master branch. We'll see how it goes. Also, for those, like me, who would rather read the letter, I've also modified the doc-string accordingly. Thanks for your suggestion. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Eric Schulte eric.schu...@gmx.com writes: It's out of exporter's scope. I disagree. The current exporter conforms to the value of the :results header argument (e.g., silent, replace, append, etc...) when executing code blocks during export. I see no reason why the new exporter should not as well. The new exporter conforms to the output of `org-export-blocks-preprocess'. It doesn't pay attention to header arguments. Hmm, in light of this description it seems that the new export /should/ have the same behavior WRT code block execution as the current exporter. If not I wonder if a complete minimal example could be provided. Martyn Jago provided one in this thread. Here it is: --8---cut here---start-8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8---cut here---end---8--- Regards, -- Nicolas Goaziou
Re: [O] [ODT] image scaling overridden by long caption
Hello, Jambunathan K kjambunat...@gmail.com writes: Does the existing behaviour as captured in [[Side-by-Side images laid out by hand]] be preserved with new export driver? I'm not sure to get the syntax right, but in the new exporter, you can see what is the next or previous element, along with its properties. Thus, you can detect when two paragraphs are back to back, if they have appropriate :attr_latex properties and if they are enclosed in a parent center-block element. The check could be done at the paragraph level, and, if positive, org-odt-paragraph could return the draw:fram draw:style.../draw:frame string. Am I missing something? Regards, -- Nicolas Goaziou
Re: [O] Prompts for `C-c .' and `C-c !'
Lolo le 13 lolol...@gmail.com writes: Hi ! If I understood well, I think that the difference between C-c . and C-c ! is that the timestamp is active or not. DATE is an active date that appear in agenda view. So you have ti use it if you want to see the task scheduled or deadlined. [DATE] format does not allow the timestamp to interact with agenda view. It is used to indicate date just for information. You can include inactive timestamps in the agenda with the [ and ] keys. -Bernt
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: The file name passed to \includegraphics is formed like this: ~/path/to/graphics/file My LaTeX doesn't recognize this as a path. The old exporter passed a file name where the tilde was expanded: /Users/user/path/to/graphics/file It should be fixed now. Thank you. Regards, It is fixed. Thank you! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou n.goaz...@gmail.com writes:
Hello,
t...@tsdye.com (Thomas S. Dye) writes:
A quick question and a couple of comments on the LaTeX exporter.
With the old exporter I set (setq org-export-latex-hyperref-format
\\ref{%s}) so a link to a headline would cross reference properly in
LaTeX. How do I achieve this with the new exporter? I want my text to
read, e.g., In section 1 ... So far with the new exporter, I've only
been able to get In section First headline ...
Indeed, it seems that I forgot to create that variable in the new
exporter. I don't mind adding it, but I'm not sure about where it should
apply.
At the moment, \\hyperref[%s]{%s} format string is applied to id,
custom-id, target, radio, fuzzy/target and fuzzy/headline links.
Changing all those links with just a single variable seems wrong to me.
Maybe it should replace the default value only for id, custom-id and
fuzzy/headline. And since it would only apply to headlines, it could be
renamed `org-e-latex-link-to-headline-format' or something alike.
What do you think about all of this?
My initial impression is the new exporter is extremely fast.
Unfortunately, it's only an impression. It will be slower than the
current exporter in most cases.
Oh, by the way, it reminds me that I implemented something in the LaTeX
back-end that you had asked for a while ago. If you didn't notice it,
you can try a LaTeX export on the following test buffer:
#+latex_header: \usepackage{paralist}
* Head 1
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
#+attr_latex: inparaenum i.
- item 1
- item 2
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
There is support for the following keywords: inparaenum, asparaenum,
inparaitem, asparaitem, inparadesc, asparadesc, all accepting an
optional bullet argument.
I've given the paralist facility a test run and it seems to work like a
charm. Thanks very much for augmenting the LaTeX exporter. This will
be a big help.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] LaTeX export: Keep point position in TeX file
Eric S Fraga e.fr...@ucl.ac.uk writes: If so, I suggest you could achieve what you want by using the org-export-* hooks to, for instance, save current position before export and then jump to that position after export? Maybe org-export-first-hook and org-export-latex-final-hook could be used? Thanks for your thoughts on this and sorry for being late to reply. I stumbled upon your reply and have tried it today with this: --8---cut here---start-8--- (defun my-org-latex-export-save-point () (interactive) (let ((latexfile (concat (file-name-sans-extension (buffer-name)) .tex)) (orgfile (buffer-name))) (if (get-buffer latexfile) (save-excursion (set-buffer latexfile) (setq temppoint (point))) (message Open exported LaTeX file to save point position --8---cut here---end---8--- `(interactive)' is only for testing purposes. Saving of point in .tex file under `temppoint' works this way. I tried further restoring point but failed. For reference: --8---cut here---start-8--- (defun my-org-latex-export-restore-point () (interactive) (let ((latexfile (concat (file-name-sans-extension (buffer-name)) .tex)) (orgfile (concat (file-name-sans-extension (buffer-name)) .org))) (progn (switch-to-buffer-other-frame (get-buffer latexfile)) (goto-char temppoint --8---cut here---end---8--- The switching to latex file works, but `(goto-char temppoint)' does not - for a reason I do not understand. The only benefit of this is that after export, emacs switches to the latex file automatically, which may or may not be wanted (in my case, it is). The last thing is to bind the functions to the correct hooks. I found this worked: --8---cut here---start-8--- (add-hook 'org-export-latex-after-initial-vars-hook 'my-org-latex-export-save-point) (add-hook 'org-export-latex-after-save-hook 'my-org-latex-export-restore-point) --8---cut here---end---8--- Untried and obviously untested! And likely beyond my elisp capabilities so I'd be very keen on seeing a solution. This behaviour has also bothered me (well, very minor irritation) for a long time as I often export to latex when debugging the export to PDF. It is also a minor irritation to me. And even if I could get my solution to work as intended, this approach only helps for minor edits, since the org-export could insert arbitrarily many new lines into the latex file, making the restore by previous point position rather useless. What would be needed is a context sensitive position check which can check for environments and contents simultaneously. Just guessing and thinking aloud here. A solution by hobby-elispers like me will be necessarily cumbersome, but maybe someone more skilled can pick up the scraps and make it work better :-) Best, Michael
[O] [PATCH] Save undo history after org-edit-src-save.
It's been irritating me that after saving an edit buffer, the undo history disappears; the attached patch restores the undo history. diff --git a/lisp/org-src.el b/lisp/org-src.el index 8cdf81e..e85e04e 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -661,7 +661,7 @@ the language, a switch telling if the content should be in a single line. (setq org-edit-src-saved-temp-window-config nil (defmacro org-src-in-org-buffer (rest body) - `(let ((p (point)) (m (mark)) msg) + `(let ((p (point)) (m (mark)) (ul buffer-undo-list) msg) (save-window-excursion (org-edit-src-exit 'save) ,@body @@ -670,6 +670,7 @@ the language, a switch telling if the content should be in a single line. (let ((org-src-window-setup 'current-window)) (org-edit-src-code 'save)) (org-edit-src-code 'save))) + (setq buffer-undo-list ul) (push-mark m 'nomessage) (goto-char (min p (point-max))) (message (or msg
Re: [O] C-a in lists when org-special-ctrl-a/e
On 12-Jan-23, at 3:30 PM, Nicolas Goaziou wrote: pin...@iro.umontreal.ca (François Pinard) writes: It all depends if we read the letter or the spirit of the second sentence. [ ] is a kind of TODO, and [X] is a kind of DONE, as demonstrated by the commands `C-x -' and `C-x *'. That's why I quite naturally expect the cursor to be positioned after the check box. Ok, then, let's read the spirit. I've implemented this behaviour in master branch. We'll see how it goes. It's interesting... I've wished for this for a long time, but now that you've built it, I see a problem: [ is not in the beginning of word regex set, so there is no easy way to get back to the [. With that one sole exception, I think the behaviour gives a better user experience this way than the way it was before. It's easier to get to your text. -anthony
Re: [O] C-a in lists when org-special-ctrl-a/e
Nicolas Goaziou n.goaz...@gmail.com writes: It all depends if we read the letter or the spirit of the second sentence. [ ] is a kind of TODO, and [X] is a kind of DONE, as demonstrated by the commands `C-x -' and `C-x *'. That's why I quite naturally expect the cursor to be positioned after the check box. Ok, then, let's read the spirit. I've implemented this behaviour in master branch. We'll see how it goes. Also, for those, like me, who would rather read the letter, I've also modified the doc-string accordingly. Thanks for your suggestion. Thanks for the implementation, and of course, for the open spirit :-). François
[O] Scrolling down after Shift-TAB ?
Hi again. Very, very often, after a Shift-TAB that collapses all entries, a few lines in the vicinity of the cursor are shown at the top of the window, which is mainly empty for its reminder; we contemplate the vacuum *after* the file. As my Org files are such that all the top level lines usually fit in one window, I then invariably scroll down so see it all. I wonder if this could be automated, yet it is a bit uneasy to exactly define what would be the ideal. Let me try an initial suggestion: - If the whole Org file could be displayed at once, scrolling should automatically occur so the first line of the window displays the beginning of the Org file. - Otherwise, if the last line of the window would be *outside* the Org file, scrolling should automatically occur so the last line of the window displays the end of the Org file. - If neither of the above holds, do not automatically scroll. Maybe others could improve on this with better ideas or algorithms ? François
Re: [O] Side-by-side support
Hi Jambunathan, On 2012-01-24 01:34, Jambunathan K wrote: In my case, I have simply separated the columns by atab character and set the tab-width to a sensible value for nice on-screen display. These are 'text' and 'translation of that text' side-by-side, When you are saying on-screen display, I presume you are referring to the Emacs screen? I have a strong feeling that you are using two column editing. Otherwise, it would be extremely difficult to keep one's sanity. Actually I started out using 2C editing for this, but it came constantly in my way, so currently what I am doing is: (1) use a tab character to separate the two columns and (2) set the tab-width to 30 (in most cases), so that most of the columns are nicely separated. This works very well for editing in Emacs. However, at the moment I do not have an easy way to export this to ODT as it s. Now I have given further thought to this, maybe the following will work: (1) consecutive lines with 1 or more tab characters and the *same* number of such tabs will be considered as a table and the exporter will work with this as if it were a org-table. (Note that I usually only have two columns and as you said, with more columns one is probably better off using proper tables) (2) This option is switched on or off through a variable or a OPTION line in the header of the file. (3) as I mentioned earlier, it would be good to be also able to globally set the proportions (maybe this can already be done with column properties?) All the best, Christian -- Christian Wittern, Kyoto
Re: [O] Scrolling down after Shift-TAB ?
François Pinard pin...@iro.umontreal.ca wrote: Hi again. Very, very often, after a Shift-TAB that collapses all entries, a few lines in the vicinity of the cursor are shown at the top of the window, which is mainly empty for its reminder; we contemplate the vacuum *after* the file. As my Org files are such that all the top level lines usually fit in one window, I then invariably scroll down so see it all. I wonder if this could be automated, yet it is a bit uneasy to exactly define what would be the ideal. Let me try an initial suggestion: - If the whole Org file could be displayed at once, scrolling should automatically occur so the first line of the window displays the beginning of the Org file. - Otherwise, if the last line of the window would be *outside* the Org file, scrolling should automatically occur so the last line of the window displays the end of the Org file. - If neither of the above holds, do not automatically scroll. Maybe others could improve on this with better ideas or algorithms ? You'd need to code it somewhat carefully sp that you wouldn't lose the property that after a couple of S-TABs, the buffer looks the same as when you started and point has not moved: that's useful in order to zoom out and orient yourself in the larger context and then zoom in again to continue working. Have you tried C-l after the collapse? S-TAB C-l doesn't do quite what you specified, but perhaps it's enough: it shrinks the vacuum after the file, maybe to nothing, and it does not shift point. If you like the behavior, you can always advise org-cycle so that it always calls recenter afterwards: --8---cut here---start-8--- (defadvice org-cycle (after org-cycle-recenter) Recenter after org-cycle) (recenter)) (ad-activate 'org-cycle) --8---cut here---end---8--- Nick
Re: [O] (no subject)
Eric Schulte eric.schu...@gmx.com writes: I'd rather not change the default silently in this way. I understand that. Could you provide a minimal example of the difference you describe? I just tried viewing the expanded form of the following code block and saw no difference between :noweb-ref and normal #+name: based expansions. * examples #+name: first #+begin_src sh echo 1 #+end_src #+begin_src sh :noweb-ref second echo 2 #+end_src #+begin_src sh :noweb yes first second #+end_src Thanks, Example document: ---% * Subtree :PROPERTIES: :noweb-ref: subtree :END: ** Part 1 #+begin_src sh Line One #+end_src sh ** Part 2 #+begin_src sh Line Two #+end_src sh * Assamble it #+begin_src sh :tangle yes :noweb tangle subtree #+end_src sh ---% tangled without my patch: ---% Line OneLine Two ---% tangled with my patch ---% Line One Line Two ---%
Re: [O] Scrolling down after Shift-TAB ?
Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: Very, very often, after a Shift-TAB that collapses all entries, [...] I [...] scroll down so see it all. You'd need to code it somewhat carefully sp that you wouldn't lose the property that after a couple of S-TABs, the buffer looks the same as when you started and point has not moved: that's useful in order to zoom out and orient yourself in the larger context and then zoom in again to continue working. That's a nice property indeed. Thanks for your patience with me! :-) Have you tried C-l after the collapse? It usually does not do the proper thing alone, but `C-l C-l C-l' is closer to what I want. If you like the behavior, you can always advise org-cycle so that it always calls recenter afterwards: (defadvice org-cycle (after org-cycle-recenter) Recenter after org-cycle) (recenter)) (ad-activate 'org-cycle) This was a good hint, thanks. Starting from your idea, I ended up with: (defun fp-org-cycle-recenter (type) Recenter after global collapsing. (when (eq type 'overview) (recenter (1- (window-body-height) (add-hook 'org-cycle-hook 'fp-org-cycle-recenter) When returning to a more expanded view, the original line is recovered at the center of the window instead of at its precise previous position, which is quite acceptable to me. From there, another full cycle of course leaves the impression that the position did not move. François
Re: [O] Scrolling down after Shift-TAB ?
François Pinard pin...@iro.umontreal.ca wrote: It usually does not do the proper thing alone, but `C-l C-l C-l' is closer to what I want. Well, the proper thing is very much in the eye of the beholder :-) Also, I never noticed the binding change: I've been living my life thinking that C-l *is* recenter... Thanks for the wake-up call. Nick
Re: [O] string joining accumulated noweb references Was: (no subject)
Tom Regner t...@goochesa.de writes: Eric Schulte eric.schu...@gmx.com writes: I'd rather not change the default silently in this way. I understand that. My apologies, now that I understand the issue I see that the current behavior is most likely confusing and I agree with your original suggestion to change the default. Example document: ---% * Subtree :PROPERTIES: :noweb-ref: subtree :END: ** Part 1 #+begin_src sh Line One #+end_src sh ** Part 2 #+begin_src sh Line Two #+end_src sh * Assamble it #+begin_src sh :tangle yes :noweb tangle subtree #+end_src sh I just pushed up a new customization variable named `org-babel-noweb-separator' which is used to join multiple accumulated noweb references like the above. The value defaults to a newline giving the same behavior resulting from your patch but can be set to any string. Thanks for pointing this out, -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte eric.schu...@gmx.com wrote:
Leo Alekseyev dnqu...@gmail.com writes:
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export. However, running HTML export without org-babel-execute-buffer
currently produces garbage output.
What do you mean by garbage output?
That wasn't a very good description, sorry.
..
I just wrote a detailed description of the bug, and then remembered
that I forgot to copy the latest org pull into
/usr/share/emacs/24/lisp/org. This bug is now gone, probably as a
result of you fixing export evaluation order. However, the
description of replace results bug is still relevant. I'll denote
issues that are now fixed with appropriate markup.
#+BEGIN_MOOT_POINT
Take test-export4.org from my original message, and export (C-c C-e h;
don't evaluate the buffer beforehand). You will see the following
output: http://i.imgur.com/IM3oy.png
There are two problems:
(1) Notice that the output of _every_ src_R block is images/conv2.png
It should be conv1.png on the first invocation conv2.png on the
second, and conv3.png on the third.
(2) The last src_R block is not evaluated and, in fact, appears in the
output (which it shouldn't), mangled, as the underscore is taken as a
subscript.
#+END_MOOT_POINT
For comparison, if you first evaluate the buffer, and then export, you
will see this:
http://i.imgur.com/V6PXq.png
The output of the src_R blocks is now correct, but I don't see why one
needs to pre-evaluate the buffer to get correct output on export. The
overall output, as you can see, is _not_ correct, since the results
from invocation of src_R blocks via the export are _appended_ to those
that were generated via C-c C-v b.
Could you isolate a minimal example demonstrating just the failure of
results replacement?
Run the below code a few times with C-c C-v b, and you'll see
snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var plot.filename=conv1.png
#+BEGIN_SRC R :results output silent
cat.fname.link - function() { cat(plot.filename,\n,sep=) }
cat.fname.link()
#+END_SRC
src_R[:results output replace]{ cat.fname.link() }
snip-
You can also replace src_R with
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
and it will also fail to replace results.
All the above examples were run with the latest pull of org.
HTH,
--Leo
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Leo Alekseyev dnqu...@gmail.com writes:
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte eric.schu...@gmx.com wrote:
Leo Alekseyev dnqu...@gmail.com writes:
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export. However, running HTML export without org-babel-execute-buffer
currently produces garbage output.
What do you mean by garbage output?
That wasn't a very good description, sorry.
No problem, thanks for clarifying.
[... moot bug removed ...]
Could you isolate a minimal example demonstrating just the failure of
results replacement?
Run the below code a few times with C-c C-v b, and you'll see
snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var plot.filename=conv1.png
#+BEGIN_SRC R :results output silent
cat.fname.link - function() { cat(plot.filename,\n,sep=) }
cat.fname.link()
#+END_SRC
src_R[:results output replace]{ cat.fname.link() }
snip-
You can also replace src_R with
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
and it will also fail to replace results.
All the above examples were run with the latest pull of org.
Ah, I see now. Unfortunately it is not possible to replace the results
of inline code blocks. This is because there is no general way to
identify where the results begin and end. Maybe adding [:results
silent] to your inline code blocks would solve the problem. Then you
could evaluate the whole buffer, and could previews the values produced,
but would not have to worry about duplicate results.
Sorry I don't have a more satisfying answer.
Best,
HTH,
--Leo
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Prompts for `C-c .' and `C-c !'
On 2012-01-24 00:01 +0800, François Pinard wrote: Commands `C-c .' and `C-c !' both insert a time stamp in the buffer, and the date is prompted in the mini-buffer in the same way for both commands. One of them is going to insert DATE, the other [DATE]. The mini-buffer always show DATE, like this: Date+time [2012-01-23]: = 2012-01-23 lun Could it be: Date+time [2012-01-23]: = [2012-01-23 lun] I think this is a good suggestion. is unconditionally set in org-time-stamp-custom-formats but it can be fixed by tweaking org-read-date-display. Leo
Re: [O] [BUG] Inconsistency in src block hiding
statement above. The tag-line to the Drawers section in the manual is Tucking stuff away which I think is often how drawers are used. Changing the default drawer export behavior from don't export to do export would be surprising, would break many existing work flows, and would likely make drawers less useful. In general I think the Org-mode specification is best defined by how Org-mode is used and how it may be more easily and intuitively used in the future. Org-mode doesn't currently have a formal specification, and I think that is a good thing. Formal specification don't prevent bugs, they just move them from the code to the spec. Tucking stuff away can mean different things to different users. Personally, I have treated them purely as an organizational device for supplementary information (I have :DETAILS: drawers all over my org files). The problem is that I may or may not want this supplementary information in the export, and will really vary from case to case. (Personally, in most cases, I do want to export that information -- but not always!) Furthermore, assuming that I _do_ want drawers exported, I may or may not want the drawer markup to be exported, i.e. if drawers are used purely for organizing the presentation of information, the drawer markup doesn't belong in the export. On the other hand, in certain cases one might want to denote the information as supplementary, either by exporting drawer markup (or, more likely, by putting drawer contents inside something like a code block). If I were designing this behavior from scratch, I would allow for maximum flexibility by (1) creating e.g. org-drawers-to-export variable which could take on the values nil (don't export), 'all (all drawers except :PROPERTIES:) exported, or a list of drawer names to export (2) introducing drawer flags that would control the export and display behavior of individual drawers. For instance, something like :FOO: -vis -export stuff... :END: would indicate that this drawer is to be kept unfolded and exported by default. (3) controlling whether the drawer contents are separated out from the rest of the contents by some markups (hr's or a code block) I'm not sure how easy and/or practical any of this would be. My general philosophy is that if a behavior isn't specified, many possible (sensible) behaviors should be considered and accommodated. In that sense, hiding #+name: blocks is a good thing, because it increases the amount of allowed sensible usage patterns. If we were to take it away, I think it would be necessary to compensate for this by increasing the amount of allowed sensible usage patterns of the drawers, kind of along the lines of what I described above. --Leo
Re: [O] [BUG] Inconsistency in src block hiding
Leo Alekseyev dnqu...@gmail.com writes: Tucking stuff away can mean different things to different users. Personally, I have treated them purely as an organizational device for supplementary information (I have :DETAILS: drawers all over my org files). (Out of Context) Drawer contents = Marginalia[1]? or Presentation Notes? It could also be useful as side-bar notes that have interesting trivia like Ever seen a subliminal arrow in the Fedex logo? Footnotes: [1] http://en.wikipedia.org/wiki/Marginalia --
Re: [O] string joining accumulated noweb references
Wow - this is /fast/ development :-); now I'm glad my son kept me awake this night, so that I could check my mails sooner than I normaly would have... Eric Schulte eric.schu...@gmx.com writes: Tom Regner t...@goochesa.de writes: Eric Schulte eric.schu...@gmx.com writes: I'd rather not change the default silently in this way. I understand that. My apologies, now that I understand the issue I see that the current behavior is most likely confusing and I agree with your original suggestion to change the default. Yes, well -- but changing current behaviour is always tricky -- you never know, how many people/documents rely on it. That's why I think that... Example document: ---% * Subtree :PROPERTIES: [...] I just pushed up a new customization variable named `org-babel-noweb-separator' which is used to join multiple accumulated noweb references like the above. The value defaults to a newline giving the same behavior resulting from your patch but can be set to any string. ...this change is way better than my proposal; as it now does the right thing™ per default, but existing workflows depending on the old behaviour are easily mended. Thanks again -- impressive speed in reacting and thinking, and overall a polite and civil environment for contributors. I like that. Kind regards, Tom
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
On Mon, Jan 23, 2012 at 10:05 PM, Eric Schulte eric.schu...@gmx.com wrote:
Leo Alekseyev dnqu...@gmail.com writes:
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte eric.schu...@gmx.com wrote:
Leo Alekseyev dnqu...@gmail.com writes:
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export. However, running HTML export without org-babel-execute-buffer
currently produces garbage output.
What do you mean by garbage output?
That wasn't a very good description, sorry.
No problem, thanks for clarifying.
[... moot bug removed ...]
Could you isolate a minimal example demonstrating just the failure of
results replacement?
Run the below code a few times with C-c C-v b, and you'll see
snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var plot.filename=conv1.png
#+BEGIN_SRC R :results output silent
cat.fname.link - function() { cat(plot.filename,\n,sep=) }
cat.fname.link()
#+END_SRC
src_R[:results output replace]{ cat.fname.link() }
snip-
You can also replace src_R with
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
and it will also fail to replace results.
All the above examples were run with the latest pull of org.
Ah, I see now. Unfortunately it is not possible to replace the results
of inline code blocks. This is because there is no general way to
identify where the results begin and end. Maybe adding [:results
silent] to your inline code blocks would solve the problem. Then you
could evaluate the whole buffer, and could previews the values produced,
but would not have to worry about duplicate results.
Yes, that's a good suggestion.
Just to be clear, do you consider the following to be an inline block?
(I usually think of inline as limited to src_R{ ...} type things).
Or are you generally talking about the distinction between #+begin_src
/ #+end_src lines vs #+call lines?
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
Finally, in the last file of my original message I try to use #+call's
everywhere instead of source blocks. Cleaned up example is pasted
below. It looks broken (the first #+call bar is out of order, the
second and third #+call bar's don't run), see
http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
broken
--snip-
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var a=a1.png
#+BEGIN_SRC R :results output silent
cat(in foo block\n)
cat.a - function() { cat(a,\n,sep=) }
cat.a()
#+END_SRC
#+NAME: bar
#+begin_src R :results output raw replace :exports none
cat.a()
#+end_src
Should have all a1 stuff
#+call: foo(a=a1.png)
#+call: bar()
Should have all a2 stuff
#+call: foo(a=a2.png)
#+call: bar()
Should have all a3 stuff
#+call: foo(a=a3.png)
#+call: bar()
[O] export-as-hmtl fail
Hello, When I use a python code block in a document any export-as-html results in the error Invalid file-name. Without a code block the export goes without a hitch. Other exports work no probs such as export-as-ascii. The code block within the document acts as expected, it is only the export that fails. I was on org7.5 but updated to 7.8.03 but have the same result. Also, it is only the python code blocks that fail, others work. My babel setup is (org-babel-do-load-languages 'org-babel-load-languages '( (dot . t) (sh . t) (python . t) (emacs-lisp . t) )) (setq org-babel-python-command python2.6) My code block is #+begin_src python :results output print hi #+end_src #+results: : hi Does anyone have any tips on what I might do to troubleshoot this. Could it be something else in my setup or system? Any else ever experienced this? cheers, aaron.
Re: [O] Problem at capture time
Hi François, Hi Bastien, At Mon, 09 Jan 2012 07:50:54 -0500, François Pinard wrote: Bastien b...@altern.org writes: Hi François, please be patient -- your patches are under radar, resending them does not help. OK, sorry. I do not know enough, yet, how Org works. I sent a problem, got a question, sent a reply which was rejected, then nothing. A mere short acknowledgement would have told me the message was not lost. What helps is to send them using git format-patch, to include a detailed and clean changelog entry, and to make it clear whether the patch is okay or for testing purpose first. When I read your message, I could not be sure you were yourself confident it was the right fix. I'm still not confident. And I'm not pedant enough -- yet! :-) -- to write formal patches when I'm not at least rather sure. Besides the lack of confidence in a solution, however, the problem is real. The patch I sent was merely a trail for thinking. But if nothing else, it would do I presume. I will look into this later on. Let me the one thanking you for supporting Org mode and its users, even those like me! :-) Sorry for my silence, haven't looked into the Orgmode mailing list for a while. I just pushed a fix for this problem: If the :exact-position for a list item is supplied we don't search for the position in an existing list at all but insert the item whereever :exact-position points to. I'll mark the patch in patchwork as superseeded this evening as soon as I recover my password. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpXeMllWqvRS.pgp Description: PGP signature
Re: [O] string joining accumulated noweb references
Eric Schulte eric.schu...@gmx.com writes: I just pushed up a new customization variable named `org-babel-noweb-separator' which is used to join multiple accumulated noweb references like the above. The value defaults to a newline giving the same behavior resulting from your patch but can be set to any string. Now, lets say I'd want to accumulate one set of noweb references with one separator and another set with a different one, maybe even in the same document. How'd I do that? Also, using a customization variable for the purpose of changing the semantics of documents is generally fraught with peril: if someone does customize this variable, their documents will break in subtle ways for somebody with a different or no customization. I suggest that such changes should always be visible in the source document itself. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] string joining accumulated noweb references
Achim Gratz strom...@nexgo.de writes: Eric Schulte eric.schu...@gmx.com writes: I just pushed up a new customization variable named `org-babel-noweb-separator' which is used to join multiple accumulated noweb references like the above. The value defaults to a newline giving the same behavior resulting from your patch but can be set to any string. Now, lets say I'd want to accumulate one set of noweb references with one separator and another set with a different one, maybe even in the same document. How'd I do that? Not possible in the same document, although on a document-by-document basis I would recommend the use of file local variables. Also, using a customization variable for the purpose of changing the semantics of documents is generally fraught with peril: if someone does customize this variable, their documents will break in subtle ways for somebody with a different or no customization. I suggest that such changes should always be visible in the source document itself. That is a very good point. I had originally started to implement this parameter using a header argument, but then decided that it didn't make sense to implement a multi-block parameter using a header argument. Now that you mention this however I do agree that a customization parameter is even less appropriate. Given that header arguments may be set on the file and subtree level, I suppose they do offer the range of application appropriate for this sort of parameter, and they are more likely (though not guaranteed) to have their value present in the buffer. I've just pushed up a change converting the `org-babel-noweb-separator' customization variable to the :noweb-sep header argument. Thanks, Regards, Achim. -- Eric Schulte http://cs.unm.edu/~eschulte/
