Re: [O] Tweaking the export
On Sat, Jan 28 2012, Christian Wittern wrote: > Hi, Jambunathan and Nicolas, > > On 2012-01-27 22:47, Jambunathan K wrote: >> Nicolas >> >> I will let Christian answer for himself. > Thanks Jambunathan, you are not only an excellent coder, but also an > expert mind reader:-) > What you describe is exactly what I want to achieve. > >> text A text A' >> line 2 line 2 >> >> My name is Jambunathan. I live Mon nom est Jambunathan. Je vis >> in India. en India... >> >> He wants the "English column" to be collected in to an English file and >> the "French column" to be collected in to a French file. > >> In some sense, he wants to tangle the "English column", let's say as >> verse_en.org and "French column" to verse_fr.org > > Exactly. The reason for wanting to do this is that the above is my > setup for translating, but in some cases the publication will have > only the translation, for such cases, I want to extract just the > translation. This should then produce a new org file, that simple has > either everything before the tab (the original) or everything after > the tab (the translation), while leaving all lines that do not contain > a character as they are. I also use org mode for translating (from modern Chinese, coincidentally), and as Sebastien mentioned, I find it easiest to split a single file into two subtrees, source and target, then split the window so that I've got the two subtrees side-by-side. You could use follow-mode at this point, though I don't. Selective export then becomes trivial, though you'd have a harder time getting it into a two-column table. It's always annoying to ask how to do something and then be told to do something else, so I'm not going to do that, but I do think you might encounter fewer difficulties making the above setup do what you want, rather than the TAB arrangement. Of course, classical Chinese (particularly poetry) lends itself better to doing discrete chunks one at a time… modern prose would be a nightmare with TABs, though. I've toyed with a home-made follow-type setup, where the two subtrees are displayed in split windows as above, and the sub-headings of the two subtrees have properties pointing to the IDs of their corresponding sub-heading (ie, source chapters are linked to target chapters and vice versa). I got about halfway to implementing something where corresponding paragraphs are highlighted in the non-active window, before getting distracted by an actual translation deadline. (The pie-in-the-sky next step would be to use org-mode to maintain a TMX-formatted translation database (http://en.wikipedia.org/wiki/Translation_Memory_eXchange), and allow for automatic insertion of translations of known terms, a library I expect to have written some time before the obsoletion of Emacs itself.) Anyway, I'm not sure I had much of a point, but if there are any other translators using org-mode, it might be interesting to discuss how we could make it more useful, perhaps in a separate thread. Eric -- Gnu Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.24.9) of 2012-01-26 on pellet Org-mode version 7.8.03 (release_7.8.03.249.g742c4e9)
Re: [O] Tweaking the export
Hi Sebastian, On 2012-01-27 23:03, Sebastien Vauban wrote: Just a side comment: isn't easier to work in 2 different files or buffers (eventually, within the same file) and use some sort of "parallel" follow-mode? I thought such a thing existed, but can't find it back right now. Anyway, it would be quite easy to implement: it's more or less implementing C-v/M-v so that it's done in two parallel buffers at the same time, instead of just in one!? Best regards, Seb What you describe is Two-Column mode, and this was suggested by Jambunathan before. I did try this alley, but for me org-mode works better. One of the reasons for this is, that there are some structural aspects that are common to both files. Another reason is that I want to be able grep through the files and be able to see matching lines in both languages -- this helps me ensure a consistent translation. So the current setup is really nice for me for doing the work, but now I need to construct the pipeline for publication. As Jambunathan put it, this is really a problem of tangling the output. BTW, I think the general exporter should also be able to to a org-mode to org-mode conversion. This would provide a general framework to systematically correct little problems in files. I guess here it shows that I am coming from the XML world, where a conversion from one XML file to another XML file with slight alterations of some aspects is a very common pattern. All the best, Christian -- Christian Wittern, Kyoto
Re: [O] Tweaking the export
Hi, Jambunathan and Nicolas, On 2012-01-27 22:47, Jambunathan K wrote: Nicolas I will let Christian answer for himself. Thanks Jambunathan, you are not only an excellent coder, but also an expert mind reader:-) What you describe is exactly what I want to achieve. text A text A' line 2 line 2 My name is Jambunathan. I live Mon nom est Jambunathan. Je vis in India. en India... He wants the "English column" to be collected in to an English file and the "French column" to be collected in to a French file. In some sense, he wants to tangle the "English column", let's say as verse_en.org and "French column" to verse_fr.org Exactly. The reason for wanting to do this is that the above is my setup for translating, but in some cases the publication will have only the translation, for such cases, I want to extract just the translation. This should then produce a new org file, that simple has either everything before the tab (the original) or everything after the tab (the translation), while leaving all lines that do not contain a character as they are. I assume this would be an easy task with the new exporter -- but still a bit at loss on where to start... All the best, Christian -- Christian Wittern, Kyoto
Re: [O] Tangling text files
dlc writes: > How do I tangle txt to a txt file? > > #+TITLE: Centos 5 Apache Configuration > #+AUTHOR: David Coate > > * Basic Conguration > * Php Settings > * Virtual Host >e.g. for apache configuration > ** example.com > Use this as main website, use drupal, various other notes > > #+BEGIN_SRC: txt :tangle vhost.conf > ServerName Example.com > DocumentRoot "/var/www/example.com" > #+END_SRC: > It is actually just a syntax problem, you should delete the ":"s after your begin and end src lines so the above becomes #+BEGIN_SRC txt :tangle vhost.conf ServerName Example.com DocumentRoot "/var/www/example.com" #+END_SRC Then tangling should work as expected. You'd be surprised how long it took me to notice the colons :). One good way to solve these sorts of issues is using the built in templates, e.g., type "http://cs.unm.edu/~eschulte/
Re: [O] [babel][patch] BUG in inline source blocks
Andreas Leha writes:
> Martyn Jago writes:
>
>> Martyn Jago writes:
>>
>>> Hi,
>>>
>>> Andreas Leha writes:
>>>
Hi all,
I experience unexpected behaviour when an inline source block is not
preceded by whitespace.
Example:
===
* Test inline
This is a functional inline src_R{print("source block")}.
This (src_R{print("here")}) is not.
===
Regards,
Andreas
>>>
>>> I can confirm this behaviour and provide a patch to allow for inline
>>> source blocks to be preceded by punctuation, or, for instance, enclosed
>>> in parenthesis, as in Andreas' example. Patch is attached for
>>> consideration.
>>>
>>> Best, Martyn
>>
>> This is an updated version of the previous patch, with debug noise
>> removed, and a couple of extra tests.
>>
>> Best, Martyn
>
Thanks for this patch Martyn, I just pushed up your [:punct:] change.
>
> Hi Martyn,
>
> thanks for this patch! It does half the job for me. Now export (or
> evaluation) already work. But in the export I get a space inserted.
>
> I my example, I'd expect "(here)" to appear in the export, but I get "(
> here)".
>
This should now be fixed.
Best,
>
> Best,
> Andreas
>
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [Babel] [PATCH] Customize regular expression to match noweb references
Good idea, I've changed your implementation to rely on two new customization variables `org-babel-noweb-wrap-start' and `org-babel-noweb-wrap-end' as this provides more flexibility to the backend implementation to place constraints on the properties of the noweb names. In you're situation you will now want to set... (setq org-babel-noweb-wrap-start "«" org-babel-noweb-wrap-end "»") Thanks for the great idea, "Sean O'Halpin" writes: > Hi, > > Here's a patch I'm using to change the default regular expression used > to match noweb references. > The default regular expression "<<\\(.+?\\)>>" conflicts with Ruby > syntax and confuses syntax highlighting. > I now set this to "«\\(.+?\\)»", i.e. using guillemots instead > (AltGr-z and AltGr-x on my keyboard). > > Regards, > Sean > > > Customizable regular expression to match noweb references. > --- > lisp/ob-tangle.el |4 +++- > lisp/ob.el|7 ++- > 2 files changed, 9 insertions(+), 2 deletions(-) > > diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el > index d7c4d7e..4148774 100644 > --- a/lisp/ob-tangle.el > +++ b/lisp/ob-tangle.el > @@ -281,12 +281,14 @@ references." >(interactive) >(goto-char (point-min)) >(while (or (re-search-forward "\\[\\[file:.*\\]\\[.*\\]\\]" nil t) > - (re-search-forward "<<[^[:space:]]*>>" nil t)) > + (re-search-forward org-babel-noweb-regexp nil t)) > (delete-region (save-excursion (beginning-of-line 1) (point)) > (save-excursion (end-of-line 1) (forward-char 1) > (point) > > (defvar org-stored-links) > (defvar org-bracket-link-regexp) > +(defvar org-babel-noweb-regexp) > + > (defun org-babel-tangle-collect-blocks (&optional language) >"Collect source blocks in the current Org-mode file. > Return an association list of source-code block specifications of > diff --git a/lisp/ob.el b/lisp/ob.el > index 47be708..bbd6209 100644 > --- a/lisp/ob.el > +++ b/lisp/ob.el > @@ -113,6 +113,11 @@ remove code block execution from the C-c C-c keybinding." >:group 'org-babel >:type 'boolean) > > +(defcustom org-babel-noweb-regexp "<<\\(.+?\\)>>" > + "Regular expression to use to match noweb references." > + :group 'org-babel > + :type 'string) > + > (defcustom org-babel-results-keyword "RESULTS" >"Keyword used to name results generated by code blocks. > Should be either RESULTS or NAME however any capitalization may > @@ -2159,7 +2164,7 @@ block but are passed literally to the > \"example-block\"." >(with-temp-buffer > (insert body) (goto-char (point-min)) > (setq index (point)) > -(while (and (re-search-forward "<<\\(.+?\\)>>" nil t)) > +(while (and (re-search-forward org-babel-noweb-regexp nil t)) >(save-match-data (setf source-name (match-string 1))) >(save-match-data (setq evaluate (string-match "\(.*\)" > source-name))) >(save-match-data -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [babel]Skip comments on code blocks on export?
Hi Rainer, You could add a function to the `org-babel-post-tangle-hook' to remove comments from the resulting code file. Functions on this hook are called from within the tangled code file. Best, Rainer M Krug writes: > Hi > > is there a way of skipping comments when exporting R code? > > The reason is, that I have roxygen tags in my code, which I do not > want to bi included when I export the document to a pdf, as they are > only irritate readers not familiar with roxygen. > On the other hand, I would like to keep them in the code when > tangling, as basic documentation and a base for when / if I convert > the code to a package. > > So my question: is there a way of suppressing comments in code on export? > I am aware that might be difficult, but possibly a parameter > > #+PROPERTY: supressLines "##" > > which supresses all code lines in code blocks starting with ## would > be great for this purpose. > > Or is there another way of handling this issue? > > Rainer -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
Leo Alekseyev writes:
>>
>> If /inline blocks/ above don't replace their results above then that is
>> expected. If you can find instances where call lines or blocks don't
>> replace their results then that is a bug.
>
> Yes, I was finding that neither inline nor regular blocks replace: run
> the following with C-c C-v b a few times and look at the block output
>
> -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
> #+call: foo(a="a1.png")
>
> #+begin_src R :results output raw replace :exports results
> cat.a()
> #+end_src
> --snip-
>
OK, I see what you mean. When I evaluate this buffer multiple times the
results of the #+call: line *are* replaced as expected, but the final
code block can not replace it's results because of the "raw" option to
the :results header argument. The "raw" and "replace" header arguments
are not compatible because with raw results there is no way to know
where the results end. I believe this is mentioned in the manual, if
not it should be.
>
>
>>
>>>
>>> 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
>>>
>>
>> Ah, this is a different issue, but one which should be discussed. I'm
>> happy we're working through all of these before the Emacs24 release.
>>
>> The problem below is not order of evaluation but rather insertion of
>> results. The elements are evaluated in order, but the results from the
>> bar() call lines are all inserted in the same place. In the current
>> code the raw text of the call line is used to insert the results, so
>> identical call lines replace each other's results.
>
> ...
>
>>> Although the above is a workaround, it may be cumbersome. I'm on the
>> fence about whether to try to change the existing behavior. If each
>> identical call line is thought of as a token of the same call then maybe
>> it makes sense to have only one location in which to insert the results
>> of that call (also it is possible that some users are relying on the
>> current behavior). That said it is certainly confusing...
>
> I see no reason why we should think of each call line as a token of
> the same call; do you? In fact, it's probably a fundamentally flawed
> way of thinking, because nothing guarantees that the global state of
> the session hasn't changed between call invocations. In fact, in that
> sense, we can't even technically regard the _same_ call line as being
> a token of the same call, if we consider it at different times :)
>
I'm inclined to agree with you.
>
> Referring to what I said in another thread ("the principle of least
> surprise"): it makes a lot of sense for the call lines to behave the
> same way a function call, or a source() statement would behave in the
> interpreter session of the original language. From that perspective,
> the current behavior seems wrong. Can you come up with a scenario /
> usage pattern where the current behavior is more desirable?
>
The only loss of functionality would be the ability in the existing
model to have a call line and it's results live in separate locations.
Given that call lines can not currently be named their results are named
by the information on the call line (called function, header arguments,
etc...) which will be identical for identical call lines, leading to the
current confusing behavior.
I think the best way forward would be to
1. stop auto-naming #+call: lines as we are currently and instead leave
their results anonymous as with code blocks, and by default inserted
immediately after the #+call: line.
2. allow names to be applied to call lines, which can then be used to
identify their results and locate their results remotely in the
buffer.
If this sounds like a good way forward then I'll put it on my queue for
some time in the when-I-have-more-time future. :)
Best,
>
> --Leo
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] patch to org-refile for more accurate completing-read
Le Wang writes: > Here: https://gist.github.com/1689071 > > When we are using using refile as navigation, require must-match > regardless of org-refile-allow-creating-parent-nodes. Hi, I suggest you post the patch to the mailing list as an attachment so 1) we can read it inline and comment on it without having to go find it on the web 2) it will get automatically picked up by the patchwork patch tracker so it can be easily applied to the source 3) it will forever be in the mailing list archive Regards, Bernt
[O] Drawers within inline tasks
Hi everybody, I recently discovered inline tasks and use them to keep todos that are related to a text I write close to the text. I'm not a big fan of their visibility behavior, but I think I can manage. I would very much like to clock work on inline tasks. However, when opening a tasks with inline tasks the LOGBOOK drawer is opened as well producing a lot of clutter. The same is true for the PROPERTIES drawer containing the effort estimate. Is it possible to keep drawers below an inline task collapsed? Ideally I would like to be able to configure the visibility behavior of inline tasks. I think I would prefer them to behave just like normal tasks. Thanks, Viktor
Re: [O] [ODT] image scaling overridden by long caption
Jambunathan K writes: Hi Jambunathan, thanks for looking into this. Answer to your questions below > Hello Andreas > > Andreas Leha writes: >> But I experienced another issue with respect to images scaling in the odt >> export: >> >> This subtree: >> >> test.org == >> * Test image scaling in odt >> #+caption: bar >> #+label: fig:bar >> #+name: bar >> #+attr_odt: :width 8 >> #+header: :file bar.png >> #+header: :width 7200 :height 3600 :res 600 >> #+begin_src R :exports results :results graphics >> plot(1:10, 1:10) >> #+end_src >> #+caption: baz >> #+label: fig:baz >> #+name: baz >> #+attr_odt: :scale 0.5 >> #+header: :file baz.png >> #+header: :width 7200 :height 3600 :res 600 >> #+begin_src R :exports results :results graphics >> plot(1:10, 1:10) >> #+end_src >> == >> >> exports to this: http://i.imgur.com/sUHQi.png on my system. > > I am on a Netbook and I am unable to create "big" images. This is the > following error I get when export the above snippet. > > , "*Org-Babel Error Output*" > | Error in png(filename = "baz.png", height = 3600, res = 600, width = 7200) > : > | unable to start device > | Calls: -> -> png -> .External > | In addition: Warning messages: > | 1: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) : > | Unable to allocate bitmap > | 2: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) : > | opening device failed > | Execution halted > ` > > If I reduce the dimensions of the above images, I see that the ODT > output is along expected lines. > > I imagine that for some reasons, the ODT exporter has trouble figuring > out the image dimensions of the second image. > > Btw, can you post the outputs of the following forms: > > #+begin_src emacs-lisp > (list (* max-image-size (frame-pixel-width)) > (* max-image-size (frame-pixel-height))) > #+end_src #+results: | 3648.0 | 4320.0 | > #+begin_src emacs-lisp > (message "%S" (ignore-errors > (image-size (create-image "bar.png") 'pixels))) > (message "%S" (ignore-errors > (image-size (create-image "baz.png") 'pixels))) > #+end_src #+results: : (30 . 30) > > If you can also post the output of the XML created in your machines, I > would be able to infer what could be happening. > > You can access the XML with: > > open odt file in archive-mode: C-x b test.odt or C-x C-f test.odt > open content.xml : ENTER on content.xml > search for .png : C-s .png > > Post the snippets for both 001.png and 002.png #+begin_html Figure 1: bar Figure 2: baz #+end_html Best, Andreas
Re: [O] [babel][patch] BUG in inline source blocks
Martyn Jago writes:
> Martyn Jago writes:
>
>> Hi,
>>
>> Andreas Leha writes:
>>
>>> Hi all,
>>>
>>> I experience unexpected behaviour when an inline source block is not
>>> preceded by whitespace.
>>>
>>> Example:
>>> ===
>>> * Test inline
>>> This is a functional inline src_R{print("source block")}.
>>>
>>> This (src_R{print("here")}) is not.
>>> ===
>>>
>>> Regards,
>>> Andreas
>>
>> I can confirm this behaviour and provide a patch to allow for inline
>> source blocks to be preceded by punctuation, or, for instance, enclosed
>> in parenthesis, as in Andreas' example. Patch is attached for
>> consideration.
>>
>> Best, Martyn
>
> This is an updated version of the previous patch, with debug noise
> removed, and a couple of extra tests.
>
> Best, Martyn
Hi Martyn,
thanks for this patch! It does half the job for me. Now export (or
evaluation) already work. But in the export I get a space inserted.
I my example, I'd expect "(here)" to appear in the export, but I get "( here)".
Best,
Andreas
Re: [O] [ANN] ASCII back-end for new export engine
Sent from my iPhone On Jan 27, 2012, at 8:31 AM, Jambunathan K wrote: > Tom > > The aspect I am exploring is this: > > Does numbering behavious occur uniformly for a *given* level? For > example, are we talking of a scenario where level 3 heading in Tree-1 is > numbered while level 3 heading on a Tree-2 is unnumbered. What would be > the behaviour of level 4 heading in Tree-1. > > It seems to me, that an unnumbered heading is a mnemonic(?) for creating > a paragraph (albeit a short one) that is styled very much like a > heading. When one looks at a printed document, one doesn't really know > what mechanism were used to achieve a particular typesetting effect and > there could be multiple mechanisms by which the same effect could be > achieved. > LaTeX formats \section* just like \section, except it is not numbered even if \section is, it doesn't change the numbering of subsequent \sections, and it does not appear in TOC. > If the above paragraph is true , I think the right thing to do would be > to associate a paragraph style with *just* the heading component of an > Org's outline level and leave it to the exporter what particular code it > wants to emit. > -- At some point a property would be useful. Back ends could deal with it differently. Tom
Re: [O] [ANN] ASCII back-end for new export engine
Thomas S. Dye wrote: > \paragraph and \subparagraph can both be numbered sections in LaTeX. > The names are confusing. Apparently, the alternatives, > \subsubsubsection and \subsubsubsubsection weren't appealing. > No wonder - it's sorta like writing Avogadro's number like this: 6023 (not sure I got the right number of zeroes either). Maybe LaTeX should introduce scientific notation: \sub^3section and \sub^4section Tongue-firmly-in-cheek-ly yours, Nick
Re: [O] [ANN] ASCII back-end for new export engine
Sent from my iPhone On Jan 27, 2012, at 9:21 AM, Achim Gratz wrote: > Jambunathan K writes: >> Does numbering behavious occur uniformly for a *given* level? For >> example, are we talking of a scenario where level 3 heading in Tree-1 is >> numbered while level 3 heading on a Tree-2 is unnumbered. What would be >> the behaviour of level 4 heading in Tree-1. > > You can make any level heading unnumbered in LaTeX by adding a "*" to > the section command, without affecting other headings on the same > level. You can also specify a different entry to appear in the TOC than > in the document — albeit the purpose is to have a short form of the heading > in the TOC and the full heading in the document, you can actually > specify two totally different strings. > Yes, TOC and running heads if the class defines them. >> It seems to me, that an unnumbered heading is a mnemonic(?) for creating >> a paragraph (albeit a short one) that is styled very much like a >> heading. > > No, LaTeX has \paragraph for that. LaTeX concerns itself with the > document structure, it has styles to take care about the formatting. > \paragraph and \subparagraph can both be numbered sections in LaTeX. The names are confusing. Apparently, the alternatives, \subsubsubsection and \subsubsubsubsection weren't appealing. Tom >> When one looks at a printed document, one doesn't really know >> what mechanism were used to achieve a particular typesetting effect and >> there could be multiple mechanisms by which the same effect could be >> achieved. > > The point of LaTeX is that you don't manually muck with the formatting > at all. If it looks like a heading, then it was a heading and not a > paragraph that's been formatted like a heading. > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Samples for the Waldorf Blofeld: > http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra > >
Re: [O] [ANN] ASCII back-end for new export engine
Jambunathan K writes: > Does numbering behavious occur uniformly for a *given* level? For > example, are we talking of a scenario where level 3 heading in Tree-1 is > numbered while level 3 heading on a Tree-2 is unnumbered. What would be > the behaviour of level 4 heading in Tree-1. You can make any level heading unnumbered in LaTeX by adding a "*" to the section command, without affecting other headings on the same level. You can also specify a different entry to appear in the TOC than in the document — albeit the purpose is to have a short form of the heading in the TOC and the full heading in the document, you can actually specify two totally different strings. > It seems to me, that an unnumbered heading is a mnemonic(?) for creating > a paragraph (albeit a short one) that is styled very much like a > heading. No, LaTeX has \paragraph for that. LaTeX concerns itself with the document structure, it has styles to take care about the formatting. > When one looks at a printed document, one doesn't really know > what mechanism were used to achieve a particular typesetting effect and > there could be multiple mechanisms by which the same effect could be > achieved. The point of LaTeX is that you don't manually muck with the formatting at all. If it looks like a heading, then it was a heading and not a paragraph that's been formatted like a heading. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] [TABLE-OF-CONTENTS] with ODT exporter?
Jambunathan K writes: >> this means that [TABLE-OF-CONTENTS] isn't supported in the ODT >> exporter. > > Fixed. Please pull again. That works. Thanks! -Dave
[O] Bug: get-face-font: Xemacs21.5.29: org-preview-latex-fragment [7.5]
Hello I tried to use the function as mentioned above, but obtained the following error whose but trace I attach. I looked into the code (org.el) and indeed it has a it has (if (featurep 'xemacs) (font-height (get-face-font 'default)) Now the function `get-face-font' is not defined in Xemacs 21.5.29 nor in 21.4. (I shall send a copy to Xemacs beta.) One remark: I thought that (X)Emacs could not surprise me any longer since it is such a mature product, but first org-table surprised me since it brought spread-sheet features, now org-preview-latex-fragment brings (X)Emacs closer to a word processor. Thank you Team! Uwe Brauer org-preview-bug.el Description: application/emacs-lisp Emacs : XEmacs 21.5 (beta29) "garbanzo" [Lucid] (i686-pc-linux, Mule) of Sat Nov 5 2011 on Burrurr Package: Org-mode version 7.5 current state: == (setq org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-metaup-hook '(org-babel-load-in-session-maybe) outline-mode-hook '(hide-body) org-after-todo-state-change-hook '(org-clock-out-if-current) org-metadown-hook '(org-babel-pop-to-session-maybe) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-include-diary t outline-minor-mode-hook '(my-outline-keys) org-babel-pre-tangle-hook '(save-buffer) org-mode-hook '(# # org-babel-result-hide-spec org-babel-hide-all-hashes my-org-keys turn-on-flyspell iso-accents-mode turn-on-auto-capitalize-mode) org-confirm-elisp-link-function 'yes-or-no-p org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup) org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src org-babel-exp-inline-src-blocks)) org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) org-confirm-shell-link-function 'yes-or-no-p org-table-default-size "3x3" org-export-first-hook '(org-beamer-initialize-open-trackers) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe) org-export-blocks '((src org-babel-exp-src-block nil) (comment org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil)) org-occur-hook '(org-first-headline-recenter) org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) outline-heading-end-regexp "[\n]" )
Re: [O] [ANN] ASCII back-end for new export engine
Tom The aspect I am exploring is this: Does numbering behavious occur uniformly for a *given* level? For example, are we talking of a scenario where level 3 heading in Tree-1 is numbered while level 3 heading on a Tree-2 is unnumbered. What would be the behaviour of level 4 heading in Tree-1. It seems to me, that an unnumbered heading is a mnemonic(?) for creating a paragraph (albeit a short one) that is styled very much like a heading. When one looks at a printed document, one doesn't really know what mechanism were used to achieve a particular typesetting effect and there could be multiple mechanisms by which the same effect could be achieved. If the above paragraph is true , I think the right thing to do would be to associate a paragraph style with *just* the heading component of an Org's outline level and leave it to the exporter what particular code it wants to emit. --
Re: [O] how do scientists use org mode?
On Thu, Jan 26, 2012 at 3:21 PM, GMX Christoph 13 wrote: > Hi > this is my first post here and although I am evaluating org mode with great > interest, I am also asking myself in which way other scientists are making > use of org mode. It will take a while to get my head around how to accomplish > certain things in org mode but for the moment I am intrigued by *why* one > would want to approach the problem of organizing one's research with org mode > and in which way. [...] > If this list is geared towards the proximate aspects of development and less > towards philosophy of usage, I apologize > > Christoph Perfect question for this list. I've asked some like it myself :) I use org-mode in an engineering consumer product company environment. If that doesn't qualify me as a "scientist," bummer... you'll have my input anyway. I originally got into org simply for tracking todos. I had looked into many, many other todo and note taking applications. Intellectual Property documentation is a big deal in my organization, so I was originally looking for a way to capture ideas and have a way to print them out in a nice format for insertion into an IP notebook for witnessing. In my quest, I looked at Evernote, variants of wiki, TaskPaper, Google Notebook, and some others. I actually settled on TeamTasks (a TiddlyWiki variant) with many other plugins and custom scripts for quite a while.[1] It was really neat and allowed me to do quite a lot of things. Easily searchable (just like a wiki), and nice format. I also hunted for todo applications: iGTD, Task Coach, todo.txt (Gina Trapani's script), Tracks, and others. What I liked about TeamTasks was the todo integration. Many people I know rave about Evernote. It is pretty cool, but what I didn't like was having outlines and notes in one place and todos in another. Todos often come up *in the same context* as your notes. Somewhere in here I stumbled across org-mode, and it's recognition of this fact is what really appealed to me. I also really liked the export functions. I seemed to have something that could do it all -- great notes that I could search and export *as well as* a very todo-task-tracking focus and the right "mechanics" to handle those things in a non-kludgy way. I think this would appeal to me regardless of my job type. Specifically for sciency stuff, however, I have come to love org-mode for the ability to output my research into beautiful reports via LaTeX. I also often use my notes to generate beamer presentations for team meetings. I am leading my first product development team and will be using taskjuggler -- I may be able to build exports of timelines and deliverables into into my orgmode notes. I can run gnuplot or R right from my files or beamer org files to generate the necessary graphs or results for me. I can use TikZ to illustrate process flows. I have access to great looking tables that can live where all my other notes live rather than having to generate then in excel (or calc) or something else and then try to insert them as pictures. Essentially, *everything* can live in one place -- data, code, outputted results/graphics, todos, project updates, links to other files or websites that I can retrieve later... I used to have a file per project, but migrated to having a structure like this: - * Tracking Misc todos go in here * Project 1 * Project 2 * Project 3 * Misc Journals Updates that don't fit into a project * References Stuff I just want to put somewhere and refer back to later - I also have a file called devel.org that tracks any internal technology classes I take and corresponding notes. I have a recurring todo setup where I take notes on highlights of my progress each month so that my end of the year review form is easier to fill out. So, there's a snapshot into how I use it. I just used org-mode + R-babel to create a beamer presentation on analytical test results for a team progress update. Hope that was at least somewhat helpful. Best regards, John [1] http://getteamtasks.com/
Re: [O] Tangling text files
On 27/01/12 18:07, dlc wrote: How do I tangle txt to a txt file? #+TITLE: Centos 5 Apache Configuration #+AUTHOR: David Coate * Basic Conguration * Php Settings * Virtual Host e.g. for apache configuration ** example.com Use this as main website, use drupal, various other notes #+BEGIN_SRC: txt :tangle vhost.conf ServerName Example.com DocumentRoot "/var/www/example.com" #+END_SRC: ** companyb.com notes about company b. #+BEGIN_SRC: txt :tangle vhost.conf ServerName Companyb.com DocumentRoot "/var/www/companyb.com" #+END_SRC: ... and so on for 40 more web sites. I still want to be able to export this as HTML to document to others what i've done and use the org file to maintain the webpage and the source conf files. Same issue for documenting my configuration files for postfix, dovecot, drupal settings, php.ini settings. I'm sure this is easy, but searching the org manual or googling is not getting me the right answer. #+BEGIN_ASCII and #+BEGIN_EXAMPLE seem to be for exporting only and not tangling. I don't know if this is the "right" way, but I just pretend my files are shell scripts: * Dovecot. ** dovecot.conf #+BEGIN_SRC sh :tangle ~/dropbox/configuration_files/wilkesley.org/dovecot/dovecot.conf :exports none :noweb yes protocols = imap sieve ssl = yes ssl_cert =
Re: [O] [ANN] ASCII back-end for new export engine
Jambunathan K writes: > Nicolas Goaziou writes: > > A way to set individual headings as numbered or unnumbered would be > deluxe. Perhaps this is possible, but I haven't found it? It would require to modify Org's syntax (how to tell which headline has to be numbered and which has not?). It is not possible at the moment. >>> >>> Let us not support this. >> >> I tend to agree here. > > I wonder whether there is a one-to-one correspondence between how the > headline appears in regular text and how it appears in TOC. If it > appears numbered in regular text should it appear numbered in TOC? The LaTeX classes with which I'm familiar all ensure that the TOC entry matches the in-text heading wrt numbered/unnumbered. I think this is a principle of document design (which might of course be subverted for some purpose). > > TOC in ODT exporter is specified by associating an outline level > attribute with the headings. The headlines are then collected up to > certain level (with each level being associated with a given "format"). > > The above model for TOC generation, as LibreOffice sees it, is > incompatible with associating headlines as numbered or unnumbered in > arbitrary manner. I think headline numbering has to be evaluated in > conjunction with TOC (which is but a index entry). Is it the case that ODT lacks the distinction made by LaTeX between, say, \section and \section*? The former is numbered if its depth <= secnumdepth and unnumbered otherwise. It appears in the TOC if its depth is <= tocdepth, regardless of whether or not it is numbered. The numbering of depths is determined by the class, because the number and kinds of sections vary by document class. Numbering isn't something the user thinks about--it is set by the sectioning command, according to the class file. The \section* form is a special case. It produces an unnumbered heading that does not appear in the TOC. hth, Tom -- Thomas S. Dye http://www.tsdye.com
[O] Tangling text files
How do I tangle txt to a txt file? #+TITLE: Centos 5 Apache Configuration #+AUTHOR: David Coate * Basic Conguration * Php Settings * Virtual Host e.g. for apache configuration ** example.com Use this as main website, use drupal, various other notes #+BEGIN_SRC: txt :tangle vhost.conf ServerName Example.com DocumentRoot "/var/www/example.com" #+END_SRC: ** companyb.com notes about company b. #+BEGIN_SRC: txt :tangle vhost.conf ServerName Companyb.com DocumentRoot "/var/www/companyb.com" #+END_SRC: ... and so on for 40 more web sites. I still want to be able to export this as HTML to document to others what i've done and use the org file to maintain the webpage and the source conf files. Same issue for documenting my configuration files for postfix, dovecot, drupal settings, php.ini settings. I'm sure this is easy, but searching the org manual or googling is not getting me the right answer. #+BEGIN_ASCII and #+BEGIN_EXAMPLE seem to be for exporting only and not tangling. Thanks! David
Re: [O] how do scientists use org mode?
GMX Christoph 13 writes: > Hi > this is my first post here and although I am evaluating org mode with > great interest, I am also asking myself in which way other scientists > are making use of org mode. It will take a while to get my head around > how to accomplish certain things in org mode but for the moment I am > intrigued by *why* one would want to approach the problem of > organizing one's research with org mode and in which way. > Are you putting exclusively your todos in, well, your todo file and > perhaps keep project-related things, such as data and progress, notes, > ideas etc. somewhere else? Or do you embed your notes and todos within > their original context, i.e. is org mode your one-stop solution for > data management? Do you maintain a separate file for every major > project you are responsible for or involved in or throw everything > into one or few humungous files and differentiate using hierarchies > and tags? I have *everything* in org these days except for my email (gnus for that so at least I don't have to leave emacs ;-). I have GTD stuff in a set of org files in a specific directory. For research projects, I do pretty much as Tom as already described. > In the past I have hit some road blocks not so much with other > softwares but rather concepts such as GTD, which I think is tailored > to the needs of people outside science, so I would deeply appreciate > your views and experience. I am not sure why you believe that GTD is for people outside science: it's about task management and that is pretty much universal, IMO. Whether you follow any particular GTD approach religiously is another story, of course. The trick is to pick and choose the bits that work for you. For me, being able to have project specific tasks within a research org file is very helpful. > If this list is geared towards the proximate aspects of development > and less towards philosophy of usage, I apologize Not at all -- they feed on each other so both are just as important. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.243.g0e7f)
Re: [O] Marking specific elements for folding?
Yu writes: > Hello! > > I was wondering, if there is a way to mark specific elements for > staying folded unless explicitly shown. Reading the manual I only > found possibilities to control the global folding of sections and > blocks in general. > > However, what I want to do is: > - Embed a table of numerical data in my org-mode file. > - Perform calculations on the data, using the spread sheet capabilities. > - Plot the data, preferably using a (probably lengthy) gnuplot script. > - Export only the result graph. > > However, the calculations are usually not wanted to be seen, when > looking at the file, so I'd like to specify, that this specific table > and this specific gnuplot code block are to be folded by default. > > Is there some way to achieve this? If you are not planning on exporting the data and code, you can put them into a subheading and "COMMENT" it out. I do this frequently. See the attached file for a simple example. The really nice thing, for me, is that you can have the results appearing *before* the data and code... This is not necessarily so long as you can put the results in some other heading, say. #+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc * Results Our analysis gives us these results: #+results: generate-results : 6 *** COMMENT code and data #+name: datatable | 1 | | 2 | | 3 | #+name: generate-results #+begin_src octave :export results :results value :var x=datatable sum(x) #+end_src HTH, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 : using Org-mode version 7.8.03 (release_7.8.03.243.g0e7f)
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes: A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? >>> >>> It would require to modify Org's syntax (how to tell which headline has >>> to be numbered and which has not?). It is not possible at the moment. >> >> Let us not support this. > > I tend to agree here. I wonder whether there is a one-to-one correspondence between how the headline appears in regular text and how it appears in TOC. If it appears numbered in regular text should it appear numbered in TOC? TOC in ODT exporter is specified by associating an outline level attribute with the headings. The headlines are then collected up to certain level (with each level being associated with a given "format"). The above model for TOC generation, as LibreOffice sees it, is incompatible with associating headlines as numbered or unnumbered in arbitrary manner. I think headline numbering has to be evaluated in conjunction with TOC (which is but a index entry). --
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes:
> Hello,
>
> I've commited an ASCII back-end for new export engine.
>
> Assuming contrib directory is in your load-path, you just need to
> (require 'org-export) to have both LaTeX and ASCII exporters ready to
> boot.
>
> You can then access to the dispatcher with M-x org-export-dispatch and
> test various configurations from there.
>
> As a reminder, you can ask for a table of contents, list of tables and
> list of listings with, respectively, "#+toc: headlines", "#+toc: tables"
> and "#+toc: listings". Also, drawers[1] are exported transparently by
> default.
>
> Feedback is welcome.
>
>
> Regards,
>
> [1] properties drawers excepted: those are different elements anyway.
Aloha Nicolas,
I haven't been able to export a listing yet. The following source
exports with the old exporter, but fails with the experimental exporter.
* Listing heading
#+BEGIN_SRC python :results output
print "hello world"
#+END_SRC
With the old exporter I get:
\section{Listing heading}
\label{sec-6}
\begin{verbatim}
print "hello world"
\end{verbatim}
The backtrace with the experimental exporter follows.
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
get-file-buffer(nil)
(org-babel-expand-noweb-references info (get-file-buffer
org-current-export-file))
(if (org-babel-noweb-p (nth 2 info) :export)
(org-babel-expand-noweb-references info (get-file-buffer
org-current-export-file)) (nth 1 info))
(setcar (nthcdr 1 info) (if (org-babel-noweb-p ... :export)
(org-babel-expand-noweb-references info ...) (nth 1 info)))
(setf (nth 1 info) (if (org-babel-noweb-p ... :export)
(org-babel-expand-noweb-references info ...) (nth 1 info)))
(progn (when (member ... ...) (org-babel-exp-in-export-file lang ...) (setf
hash ...)) (setf (nth 1 info) (if ... ... ...)) (org-babel-exp-do-export info
(quote block) hash))
(if info (progn (when ... ... ...) (setf ... ...) (org-babel-exp-do-export
info ... hash)))
(when info (when (member ... ...) (org-babel-exp-in-export-file lang ...)
(setf hash ...)) (setf (nth 1 info) (if ... ... ...)) (org-babel-exp-do-export
info (quote block) hash))
(let* ((info ...) (lang ...) (raw-params ...) hash) (when info (when ... ...
...) (setf ... ...) (org-babel-exp-do-export info ... hash)))
(save-excursion (goto-char (match-beginning 0)) (let* (... ... ... hash)
(when info ... ... ...)))
org-babel-exp-src-block(#("print \"hello world\"\n" 0 1 (fontified t
font-lock-fontified t font-lock-multiline t face py-builtins-face) 1 5
(fontified t font-lock-fontified t font-lock-multiline t face py-builtins-face)
5 6 (fontified t font-lock-fontified t font-lock-multiline t face nil) 6 7
(fontified t font-lock-fontified t font-lock-multiline t face
font-lock-string-face) 7 19 (fontified t font-lock-fontified t
font-lock-multiline t face font-lock-string-face) 19 20 (fontified t
font-lock-fontified t font-lock-multiline t face font-lock-string-face))
#("python" 0 6 (font-lock-multiline t face org-block-begin-line
font-lock-fontified t fontified t)) #(":results" 0 8 (font-lock-multiline t
face org-block-begin-line font-lock-fontified t fontified t)) #("output" 0 6
(font-lock-multiline t face org-block-begin-line font-lock-fontified t
fontified t)))
apply(org-babel-exp-src-block #("print \"hello world\"\n" 0 1 (fontified t
font-lock-fontified t font-lock-multiline t face py-builtins-face) 1 5
(fontified t font-lock-fontified t font-lock-multiline t face py-builtins-face)
5 6 (fontified t font-lock-fontified t font-lock-multiline t face nil) 6 7
(fontified t font-lock-fontified t font-lock-multiline t face
font-lock-string-face) 7 19 (fontified t font-lock-fontified t
font-lock-multiline t face font-lock-string-face) 19 20 (fontified t
font-lock-fontified t font-lock-multiline t face font-lock-string-face))
(#("python" 0 6 (font-lock-multiline t face org-block-begin-line
font-lock-fontified t fontified t)) #(":results" 0 8 (font-lock-multiline t
face org-block-begin-line font-lock-fontified t fontified t)) #("output" 0 6
(font-lock-multiline t face org-block-begin-line font-lock-fontified t
fontified t
(if (memq type org-export-blocks-witheld) "" (apply func body headers))
(progn (if (memq type org-export-blocks-witheld) "" (apply func body
headers)))
(unwind-protect (progn (if ... "" ...)) (set-match-data
save-match-data-internal (quote evaporate)))
(let ((save-match-data-internal ...)) (unwind-protect (progn ...)
(set-match-data save-match-data-internal ...)))
(save-match-data (if (memq type org-export-blocks-witheld) "" (apply func
body headers)))
(let ((replacement ...)) (when replacement (delete-region match-start
match-end) (goto-char match-start) (insert replacement) (unless preserve-indent
...)))
(progn (let (...) (when replacement ... ... ... ...)))
(if (setq func (cadr ...)) (progn (let ... ...)))
(when (setq func (cadr ...)) (let (...) (when replacement ... ... ... ...)))
(let* ((match-start
[O] Paragraph styles
I'm using org-mode more and more for generic text document writing and of course loving it. I usually export to LaTeX->PDF, but sometimes HTML or ODT and even ASCII sometimes -- this is an incredible capability. One thing I'm missing, and maybe it's there but I don't know how to use it, is formatting paragraphs or any longer-than-a-line bunch of text as bold or italic. *bold* only works on one line. Is there a #- option to make a paragraph bold? Should I just RTFM? (I'm using latest git master, and I'm on Windows emacs 24.0.92.1 if it matters.) -- Gary
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes: > I may be bold, but I still don't get it. "num:something" is a global > option. We're talking about specifying _individually_ which headline > wouldn't be numbered. How would a global option solve a local problem? It doesn't, I missed that point. I don't think it's so terribly important to warrant any extended effort. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] [ANN] ASCII back-end for new export engine
Nicolas Goaziou writes: > Hello, > > Jambunathan K writes: > >>> I have no objection to implement limited numbering in both LaTeX and >>> ASCII back-ends, but I'd like to know if it can be handled consistently >>> in every other major back-end, too. I'm CC-ing Jambunathan to know his >>> opinion about it. >> >> I can support this in ODT exporter. We can make this a feature of the >> new export engine. > > I've now implemented this for e-latex and e-ascii back-ends. > Great! This works nicely for me. A way to set individual headings as numbered or unnumbered would be deluxe. Perhaps this is possible, but I haven't found it? >>> >>> It would require to modify Org's syntax (how to tell which headline has >>> to be numbered and which has not?). It is not possible at the moment. >> >> Let us not support this. > > I tend to agree here. This can be obviously discussed on the list, > detail specifications and so on, but I'd rather postpone any real coding > in this area until new exporter is installed in core. Yes, this is not a burning issue. In my experience, use of \section* etc. is not frequent. It is certainly not a reason to keep the new exporter from moving toward the Org mode core. Thanks for making the num: option really useful for LaTeX export. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] C-a in lists when org-special-ctrl-a/e
On 12-Jan-27, at 10:08 AM, Nicolas Goaziou wrote: > Hello, > > Anthony Lander writes: > >> 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 "[". > > There is C-M-b. Indeed there is! Thank you Nicolas, I didn't even think to try that. -Anthony
Re: [O] [ANN] ASCII back-end for new export engine
Hi all, Nicolas Goaziou writes: > I tend to agree here. This can be obviously discussed on the list, > detail specifications and so on, but I'd rather postpone any real coding > in this area until new exporter is installed in core. I strongly support this. We should try to leave key syntax elements untouched before integrating the new exporter to core. Besides, such questions can be tackled by letting the user specify rules like dont-number-headlines-of-level-x or the likes that don't require syntactic changes. My 2 cents, -- Bastien
Re: [O] Invalid read syntax "#"?
Nick Dokos wrote:
> Alan Schmitt wrote:
>
> > Hello,
> >
> > I'm trying this example to export nicely formatted code in LaTeX:
> > http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-3
> >
> > Unfortunately it fails with an error 'Invalid read syntax "#"'. If I
> > delete the second code block (the python one), it works.
> >
> > Is there something wrong in the example or in my setup (org-mode from
> > yesterday's git, Aquamacs 3 from two days ago, Pygments easy-installed
> > today)?
> >
>
> I got the same thing, so it's probably not a setup problem. Here's
> a backtrace - looks like a babel problem.
>
Uhh, maybe not: it looks as if something gets out of sync in the parsing and
babel is asked to evaluate the wrong part of the string (see the shortened
backtrace below). But I haven't looked at code, so these are guesses in the
wild.
Nick
>
> Org-mode version 7.8.03 (release_7.8.03.241.g043d)
> GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of
> 2012-01-24
>
> Debugger entered--Lisp error: (invalid-read-syntax "#")
...
> org-babel-exp-results(("emacs-lisp" "#+end_src\n#+name:
> another-listing\n#+begin_src python :exports code" ((:cache . "no")
> (:colname-names) (:colnames . "no") (:comments . "") (:exports . "both")
> (:hlines . "yes") (:noweb . "no") (:padline . "") (:padnewline . "yes")
> (:result-params "silent") (:result-type . value) (:results . "silent")
> (:rowname-names) (:session . "none") (:shebang . "") (:tangle . "no")) ""
> "setup-minted" 0) block nil "2a39b675a6bec8c15b0ed8928d030e836ddd17d5")
> org-babel-exp-src-block("" #("emacs-lisp" 0 10 (font-lock-fontified t
> fontified t)) #(":exports" 0 8 (font-lock-fontified t fontified t)) #("both"
> 0 4 (font-lock-fontified t fontified t)) #(":results" 0 8
> (font-lock-fontified t fontified t)) #("silent" 0 6 (font-lock-fontified t
> fontified t)))
...
> org-export-blocks-preprocess()
...
> org-export-preprocess-string(#("#+LATEX_CLASS: article\n#+LaTeX_HEADER:
> \\usepackage{minted}\n#+LaTeX_HEADER:
> \\usemintedstyle{emacs}\n#+LaTeX_HEADER:
> \\newminted{common-lisp}{fontsize=\\footnotesize}\n\n#+name:
> setup-minted\n#+begin_src emacs-lisp :exports both :results silent\n
> (setq org-export-latex-listings 'minted)\n (setq
> org-export-latex-custom-lang-environments\n '(\n
> (emacs-lisp \"common-lispcode\")\n ))\n (setq
> org-export-latex-minted-options\n '((\"frame\" \"lines\")\n
> (\"fontsize\" \"scriptsize\")\n (\"linenos\" \"\")))\n
> (setq org-latex-to-pdf-process\n '(\"pdflatex -shell-escape
> -interaction nonstopmode -output-directory %o %f\"\n \"pdflatex
> -shell-escape -interaction nonstopmode -output-directory %o %f\"\n
> \"pdflatex -shell-escape -interaction nonstopmode -output-directory %o
> %f\"))\n#+end_src\n\n#+name: another-listing\n#+begin_src pytho
n
> :exports code\n x = str(y)\n#+end_src\n" 0 22 (fontified t
> font-lock-fontified t face org-meta-line) 22 23 (fontified t
> font-lock-fontified t face org-meta-line) 23 58 (fontified t
> font-lock-fontified t face org-meta-line) 58 59 (fontified t
> font-lock-fontified t face org-meta-line) 59 97 (fontified t
> font-lock-fontified t face org-meta-line) 97 98 (fontified t
> font-lock-fontified t face org-meta-line) 98 161 (fontified t
> font-lock-fontified t face org-meta-line) 161 162 (fontified t
> font-lock-fontified t face org-meta-line) 162 163 (fontified t
> :org-license-to-kill t) 163 183 (fontified t font-lock-fontified t face
> org-meta-line) 183 184 (fontified t font-lock-fontified t face org-meta-line)
> 184 236 (fontified t font-lock-fontified t face org-block-begin-line
> font-lock-multiline t) 236 237 (fontified t font-lock-fontified t
> font-lock-multiline t face org-block-begin-line) 237 524 (fontified t
> font-lock-fontified t font-lock-multiline t face org-block :org-license-to-kil
l
> t) 524 764 (fontified t font-lock-fontified t font-lock-multiline t face
> org-block :org-license-to-kill t) 764 852 (fontified t font-lock-fontified t
> font-lock-multiline t face org-block :org-license-to-kill t) 852 853
> (fontified t font-lock-fontified t font-lock-multiline t face org-block
> :org-license-to-kill t) 853 862 (fontified t font-lock-fontified t face
> org-block-end-line font-lock-multiline t) 862 863 (fontified t
> font-lock-fontified t face org-block-end-line) 863 864 (fontified t
> :org-license-to-kill t) 864 887 (fontified t font-lock-fontified t face
> org-meta-line) 887 888 (fontified t font-lock-fontified t face org-meta-line)
> 888 920 (fontified t font-lock-fontified t face org-block-begin-line
> font-lock-multiline t) 920 921 (fontified t font-lock-fontified t
> font-lock-multiline t face org-block-begin-line) 921 934 (fontified t
> font-lock-fontified t font-lock-multiline t face org-block
> :org-license-to-kill t)
Re: [O] C-a in lists when org-special-ctrl-a/e
Hello, Anthony Lander writes: > 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 "[". There is C-M-b. Regards, -- Nicolas Goaziou
Re: [O] 500 persons have Org Mode in their Google+ circles
On 27 Jan 2012, at 16:01, Bastien wrote: Hi all, a while ago, I created a Google+ page for Org Mode. There are now 500 persons who have Org Mode in their circles... This is a nice place to share links, stories, announcements, etc. Here is the page: https://plus.google.com/b/102778904320752967064 I get a 404 with this URL. This one works: https://plus.google.com/102778904320752967064/posts Alan
[O] BUG: Latex exporter bug
Hello Org people: I have found the following issue when exporting to Latex: a headline is sometimes moved to another position when skipping a level in the hierarchy. The following demonstrates the problem: * Sec 1 ** Subsec 1.1 *** Subsec 1.1.1 ** Subsec 1.2 * Sec 2 *** Subsec 2.0.1 (THIS IS MOVED) When I export this to Latex, the last headline ends up before "Sec 2" in the Latex file. If I put two stars instead of three, it is placed correctly at the end. I am using the latest git head (d9970d1b) and Emacs 23.2.1 Tomas ps This does not happen for all exporters, e.g. html seems OK.
[O] 500 persons have Org Mode in their Google+ circles
Hi all, a while ago, I created a Google+ page for Org Mode. There are now 500 persons who have Org Mode in their circles... This is a nice place to share links, stories, announcements, etc. Here is the page: https://plus.google.com/b/102778904320752967064 And here is a question on how to use this space: https://plus.google.com/b/102778904320752967064/102778904320752967064/posts/YR2JZWBuEMp The mailing list is the central communication channel for Org and I will do my best to keep it as such. If people are more experienced with G+ than I am, please share your though there on how to use this space. Thanks! -- Bastien
Re: [O] org mode in press
Hopefully this will serve as the canonical introduction to working with code blocks in Org-mode. As we acknowledge in the paper this work would not have been possible without the ideas and feedback of the Org-mode community, so thanks all! Nick Dokos writes: > Andreas Leha wrote: > >> Hi all, >> >> this just came into my inbox: >> http://www.jstatsoft.org/v46/i03 >> >> Great work! Big thanks to the authors. >> > > I remember reading it with great pleasure back when Eric posted it to > the list: beautiful stuff. I look forward to rereading it. > > Congratulations! > > Nick > > -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] patch to org-refile for more accurate completing-read
Here: https://gist.github.com/1689071 When we are using using refile as navigation, require must-match regardless of org-refile-allow-creating-parent-nodes. -- Le
Re: [O] [ODT] image scaling overridden by long caption
Hello Andreas Andreas Leha writes: > But I experienced another issue with respect to images scaling in the odt > export: > > This subtree: > > test.org == > * Test image scaling in odt > #+caption: bar > #+label: fig:bar > #+name: bar > #+attr_odt: :width 8 > #+header: :file bar.png > #+header: :width 7200 :height 3600 :res 600 > #+begin_src R :exports results :results graphics > plot(1:10, 1:10) > #+end_src > #+caption: baz > #+label: fig:baz > #+name: baz > #+attr_odt: :scale 0.5 > #+header: :file baz.png > #+header: :width 7200 :height 3600 :res 600 > #+begin_src R :exports results :results graphics > plot(1:10, 1:10) > #+end_src > == > > exports to this: http://i.imgur.com/sUHQi.png on my system. I am on a Netbook and I am unable to create "big" images. This is the following error I get when export the above snippet. , "*Org-Babel Error Output*" | Error in png(filename = "baz.png", height = 3600, res = 600, width = 7200) : | unable to start device | Calls: -> -> png -> .External | In addition: Warning messages: | 1: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) : | Unable to allocate bitmap | 2: In png(filename = "baz.png", height = 3600, res = 600, width = 7200) : | opening device failed | Execution halted ` If I reduce the dimensions of the above images, I see that the ODT output is along expected lines. I imagine that for some reasons, the ODT exporter has trouble figuring out the image dimensions of the second image. Btw, can you post the outputs of the following forms: #+begin_src emacs-lisp (list (* max-image-size (frame-pixel-width)) (* max-image-size (frame-pixel-height))) #+end_src #+begin_src emacs-lisp (message "%S" (ignore-errors (image-size (create-image "bar.png") 'pixels))) (message "%S" (ignore-errors (image-size (create-image "baz.png") 'pixels))) #+end_src If you can also post the output of the XML created in your machines, I would be able to infer what could be happening. You can access the XML with: open odt file in archive-mode: C-x b test.odt or C-x C-f test.odt open content.xml : ENTER on content.xml search for .png : C-s .png Post the snippets for both 001.png and 002.png --
[O] org-remember to org-capture
Hi, I am in the process of switching from org-remember to org-capture. I used a custom function with org-remember to capture into a host-specific sub-tree under "* Inbox" in order to minimize git merge conflicts between my machines. My tree typically looks like this: * Inbox *** Inbox:host1 * INBOX idea 1 * INBOX idea 2 *** Inbox:host2 * INBOX idea 3 The custom function with org-remember only needed to create the target headline's name. Org-remember would find it or create it (IIRC): >8 (defun my-host-name () "Returns the name of the current host minus the domain." (let ((hostname (downcase (system-name (save-match-data (substring hostname (string-match "^[^.]+" hostname) (match-end 0) (defun my-org-remember-headline () (concatenate 'string "Inbox:" (my-host-name))) >8 The problem is now that org-capture expects a function that creates the target node and positions point at a child of the target, is this correct? My hacky solution is to use the file+function template and looks like this: >8 (defun my-org-capture-function () (goto-char (org-find-exact-headline-in-buffer (concatenate 'string "Inbox:" (my-host-name)) nil t)) (org-end-of-line) (org-insert-subheading "")) >8 But it looks clumsy and always inserts as first child. Is there a more elegant approach, maybe using the refiling mechanism? Thanks, Martin
Re: [O] Tweaking the export
Hi all, Jambunathan K wrote: > Nicolas > > I will let Christian answer for himself. > >> [Nicolas] >> While I understand the shape of your input, I fail to see what you >> output should you look like. For example, given the following paragraph, >> >> text A text A' >> line 2 line 2 bis >> A line with *emphasis* A traduced line with *emphasis* >> > >>> [Christian] >>> I need to separate these two parts in separate texts; the stuff to the >>> left of the has to go into one file, the stuff to the right to >>> some other file, > >>> while at the same time merging the chunks of texts >>> into paragraphs. > > If I interpret the above lines, I imagine his request more along the > following lines: > > text A text A' > line 2 line 2 > > My name is Jambunathan. I liveMon nom est Jambunathan. Je vis > in India. en India... > > He wants the "English column" to be collected in to an English file and > the "French column" to be collected in to a French file. > > It is possible that "English column" constitutes a poem and the "French > column" is a line-by-line translation of the column to the left. > > In some sense, he wants to tangle the "English column", let's say as > verse_en.org and "French column" to verse_fr.org and later include them > as a table cell or a column of a 2-C section. > > Notionally something like: > |+---| > |#+INCLUDE: verse_en.org |#+INCLUDE: verse_fr.org| > |+---| > > Put another way, collect Column-X in to Paragraph-X and do whatver. > > ps: French translation is courtesy google. Just a side comment: isn't easier to work in 2 different files or buffers (eventually, within the same file) and use some sort of "parallel" follow-mode? I thought such a thing existed, but can't find it back right now. Anyway, it would be quite easy to implement: it's more or less implementing C-v/M-v so that it's done in two parallel buffers at the same time, instead of just in one!? Best regards, Seb -- Sebastien Vauban
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Jambunathan K writes: >> I have no objection to implement limited numbering in both LaTeX and >> ASCII back-ends, but I'd like to know if it can be handled consistently >> in every other major back-end, too. I'm CC-ing Jambunathan to know his >> opinion about it. > > I can support this in ODT exporter. We can make this a feature of the > new export engine. I've now implemented this for e-latex and e-ascii back-ends. >>> A way to set individual headings as numbered or unnumbered would be >>> deluxe. Perhaps this is possible, but I haven't found it? >> >> It would require to modify Org's syntax (how to tell which headline has >> to be numbered and which has not?). It is not possible at the moment. > > Let us not support this. I tend to agree here. This can be obviously discussed on the list, detail specifications and so on, but I'd rather postpone any real coding in this area until new exporter is installed in core. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Rick Frankel writes: > On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote: >> Achim Gratz writes: >> > Unless I miss something, if "num:*" would be allowed in addition to >> > integers, the LaTeX crowd would be pleased, no terribly new syntax would >> > be needed and all other backends could take note to skip numbering that >> > headline. Maybe one could throw in "nil" and "none" as an alias for >> > "*". >> >> I don't understand. What would "num:*" achieve? >> > > I think it's an attempt to be mnemonically similar to LaTeX -- > section* for an unnumbered section. I may be bold, but I still don't get it. "num:something" is a global option. We're talking about specifying _individually_ which headline wouldn't be numbered. How would a global option solve a local problem? Regards, -- Nicolas Goaziou
Re: [O] Tweaking the export
Nicolas I will let Christian answer for himself. > [Nicolas] > While I understand the shape of your input, I fail to see what you > output should you look like. For example, given the following paragraph, > > text Atext A' > line 2line 2 bis > A line with *emphasis*A traduced line with *emphasis* > >> [Christian] >> I need to separate these two parts in separate texts; the stuff to the >> left of the has to go into one file, the stuff to the right to >> some other file, >> while at the same time merging the chunks of texts >> into paragraphs. If I interpret the above lines, I imagine his request more along the following lines: text A text A' line 2 line 2 My name is Jambunathan. I live Mon nom est Jambunathan. Je vis in India. en India... He wants the "English column" to be collected in to an English file and the "French column" to be collected in to a French file. It is possible that "English column" constitutes a poem and the "French column" is a line-by-line translation of the column to the left. In some sense, he wants to tangle the "English column", let's say as verse_en.org and "French column" to verse_fr.org and later include them as a table cell or a column of a 2-C section. Notionally something like: |+---| |#+INCLUDE: verse_en.org |#+INCLUDE: verse_fr.org| |+---| Put another way, collect Column-X in to Paragraph-X and do whatver. ps: French translation is courtesy google. --
Re: [O] Marking specific elements for folding?
Hi Achim and Yu, Achim Gratz wrote: > Yu writes: >> However, the calculations are usually not wanted to be seen, when >> looking at the file, so I'd like to specify, that this specific table >> and this specific gnuplot code block are to be folded by default. >> >> Is there some way to achieve this? > > You can put them in a drawer. ... or in a ARCHIVE'd section (to be opened with `C-TAB'). Best regards, Seb -- Sebastien Vauban
Re: [O] Tweaking the export
Hello, Christian Wittern writes: > For the last couple of years, I have used org-mode more and more for > working with and translating texts from classical Chinese. Over time, > some special conventions have crept in, like the fact that I like (for > the draft translation) to work in a way that has a short chunk of > Chinese text on the left and, separated by a character, the > translation of that piece following on the same line (there are other > special conventions like specialized drawers etc., but I don't need to > discuss these here now.) > > While this is setup is extremely pleasant to work with, at some point > I need to separate these two parts in separate texts; the stuff to the > left of the has to go into one file, the stuff to the right to > some other file, while at the same time merging the chunks of texts > into paragraphs. Now for quite some while if have thought about how > to automate that, but until now, I have usually done it by hand with > a couple of regex search-and-replace. > > Now, with the new export engine, it looks like all I would need to do > would be to tweak the way paragraphs are handled, while leaving the > rest intact, some kind of org to org transform that simply tweaks one > single aspect of the text. However, I am a bit baffled on where to > start with this. I would be glad if you or somebody else could give > me some pointers at how to tackle this problem. (And please be kind, > since my elisp fu is pretty insignificant:-( ) While I understand the shape of your input, I fail to see what you output should you look like. For example, given the following paragraph, --8<---cut here---start->8--- text A text A' line 2 line 2 bis A line with *emphasis* A traduced line with *emphasis* --8<---cut here---end--->8--- what exactly do you want to obtain ? Regards, -- Nicolas Goaziou
[O] Invalid read syntax "#"?
Hello, I'm trying this example to export nicely formatted code in LaTeX: http://orgmode.org/worg/org-tutorials/org-latex-export.html#sec-12-3 Unfortunately it fails with an error 'Invalid read syntax "#"'. If I delete the second code block (the python one), it works. Is there something wrong in the example or in my setup (org-mode from yesterday's git, Aquamacs 3 from two days ago, Pygments easy-installed today)? Thanks, Alan
Re: [O] [ANN] ASCII back-end for new export engine
On Fri, Jan 27, 2012 at 01:58:26PM +0100, Nicolas Goaziou wrote: > Achim Gratz writes: > > Unless I miss something, if "num:*" would be allowed in addition to > > integers, the LaTeX crowd would be pleased, no terribly new syntax would > > be needed and all other backends could take note to skip numbering that > > headline. Maybe one could throw in "nil" and "none" as an alias for > > "*". > > I don't understand. What would "num:*" achieve? > I think it's an attempt to be mnemonically similar to LaTeX -- section* for an unnumbered section. rick
Re: [O] [ANN] ASCII back-end for new export engine
Hello, Achim Gratz writes: > Nicolas Goaziou writes: >> But it's still new syntax. It could also be narrowed >> to :LATEX_NUMBERING: nil, but I think that this feature, if implemented, >> should be available for every major back-end, much like "num:1". > > Unless I miss something, if "num:*" would be allowed in addition to > integers, the LaTeX crowd would be pleased, no terribly new syntax would > be needed and all other backends could take note to skip numbering that > headline. Maybe one could throw in "nil" and "none" as an alias for > "*". I don't understand. What would "num:*" achieve? Regards, -- Nicolas Goaziou
Re: [O] [ANN] ASCII back-end for new export engine
> I have no objection to implement limited numbering in both LaTeX and > ASCII back-ends, but I'd like to know if it can be handled consistently > in every other major back-end, too. I'm CC-ing Jambunathan to know his > opinion about it. I can support this in ODT exporter. We can make this a feature of the new export engine. >> A way to set individual headings as numbered or unnumbered would be >> deluxe. Perhaps this is possible, but I haven't found it? > > It would require to modify Org's syntax (how to tell which headline has > to be numbered and which has not?). It is not possible at the moment. Let us not support this. > Regards,
