[O] Last org-lparse.el changes make swriter not to open after org-export-as-odt-and-open
Last org-lparse.el changes make swriter not to open after org-export-as-odt-and-open This refers to commit Tue, 2 Oct 2012 08:03:15 + (10:03 +0200) and, I think, the problems is only in org-lparse.el changes. Version 7.9.2-50-g1fb3cc works as expected if org-lparse.el is reverted to its previous version.
[O] Feature request: HTML export classes for "real" lists
In org-html-export-list-line, Org list elements use the expected "dt", "dd" and "li" tags: (insert (cond ((equal type "d") (format "%s" desc-tag)) ((and (equal type "o") counter) (format "" counter)) (t ""))) But the exporter also uses HTML list elements in other contexts; the tags are overloaded. This means you can't set up CSS definitions to tweak just "real" lists. Can someone add class attributes to each of the "dt", "dd" and "li" items in the above code block? For example ... ... ... or something similar. This should provide enough hooks for people to work with. Thanks, Derek -- Derek Upham s...@blarg.net
Re: [O] [New exporter] Wrong export to LaTeX
Hello, "Sebastien Vauban" writes: > Suvayu Ali wrote: >>> However, I thought that LaTeX_CLASS had been renamed EXPORT_LaTeX_CLASS, but >>> when using the latter, I get frames inside an `article' documentclass type >>> of >>> document -- while using `C-c E l O' (for Beamer)? That results in a weird >>> document... >> >> I believe that is the property name only for subtree export. So when >> exporting a file, use: >> >> #+LaTeX_CLASS: beamer >> >> for subtree export use: >> >> * Beamer presentation >> :PROPERTIES: >> :EXPORT_LaTeX_CLASS: beamer >> :END: > > Nicolas, do you confirm the fact that keywords differ whether they apply to > the file or to a subtree? Yes. > If yes, wouldn't make sense to remove such a distinction, or (at the > other extreme of the spectrum) to make all keywords share that same > feature (prefixing with "EXPORT_" for subtrees)? Note that it isn't a new feature from the new export engine, merely a generalization from the old exporter, which already distinguished #+DATE: and :EXPORT_DATE:, #+TITLE: and :EXPORT_TITLE:... There's little incentive for users to create new keywords on the fly. On the other hand, they may want to add node properties. That's why export keywords should be made as simple as possible and export properties should pollute as little namespace as possible. Therefore, I think the current state is good. It will be properly documented once the new exporter becomes mainstream (but the rule is simple anyway). Regards, -- Nicolas Goaziou
[O] Bug: Org column view, property edit bug [7.8.11]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. Org's column view has "e" key for editing fields such as property values. Properties are messed up if user tries to clear the property's value with "e". See the following example. Start "emacs -Q" and load this org file: #+COLUMNS: %9ITEM %5foo * heading :PROPERTIES: :foo: value :END: Turn on the column view with "C-c C-x C-c". The buffer should look like this: ITEM__|_foo___|_ #+COLUMNS: %9ITEM %5foo * heading | value | :PROPERTIES: :foo: value :END: Now move the point to the "value" column and edit it with "e". Clear all the text from the minibuffer prompt and press enter. The buffer looks like this: ITEM__|_foo___|_ #+COLUMNS: %9ITEM %5foo * heading | | :PROPERTIES: :foo: :END: Don't move the point. Press "e" again to edit the same value again. Insert "xxx" to the minibuffer prompt. The buffer looks like this: ITEM__|_foo___|_ #+COLUMNS: %9ITEM %5foo * heading | | :PROPERTIES: :foo: :foo: xxx :END: See, there are now two "foo" properties: one with empty value and one with the value "xxx". The column view will always show the empty value but the edit command "e" will edit the latter value (currently "xxx"). I think the last "e" command in my example shouldn't create new "foo" property line; it should edit the empty "foo" instead. Emacs : GNU Emacs 24.2.3 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1) of 2012-10-14 on mithlond Package: Org-mode version 7.8.11
Re: [O] Latex error "too deeply nested" only for #+INCLUDE statements
Percival du Chat Gris wrote: > > ! LaTeX Error: Too deeply nested. > > And that repeats over and over again. > OK - Seb probably got it right then: if you have too many (too many = 5) nested itemize environments, latex complains as above. > > > What is the exact output? > > Unfortunately there isn't any output. I meant the error output as you showed above. > > What version of org/emacs? > > Org-mode: Version : 7.9.2-1 > Emacs: Version : 23.3.a-3 > OK. > Are you using the new exporter or the old exporter? > > How would I be able to tell? C-c C-e p invokes the old exporter. To use the new exporter, see for example this thread: http://thread.gmane.org/gmane.emacs.orgmode/60236/focus=61566 > If the error is produced by latex, export to latex and look at the .tex > file. If the error is produced by org, it > would help to have a backtrace. > > Well ... I presume the error is produced by Latex, because I can get the same > thing if I run LaTex Export.tex, but if I replace all the > #+INCLUDE references with the contents of the files themselves, in the .org > file, it works, so I think it's an .org problem, in > producing the .tex files, not (necessarily) a LaTex problem. > I would strip down the contents of the files to just the headers: it's the structure that matters here, not the details. Then I would ask the exporter to export to latex and compare the tex files by opening them in two side-by-side windows in emacs: the differences should be telling. > I think (not being an expert) it seems that, with the stub-based file > (Export.tex), the single * in each of the #+INCLUDEed files > becomes a subsection, as opposed to an actual section (as it did in > Export-1.tex), since a section of the diff file between the .tex > files produced looks something like: > > diff Export.tex Export-1.tex > [...] > 1144a1132,1133 > > \subsection{Dynamic Interactions} > > \label{sec-7-5} > 1146,1147d1134 > < \item Dynamic Interactions\\ > < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5}% The differences *are* telling: In one case, you have a subsection at level 2, in the other an item at level (almost) infinity :-) > 1154c1141 > < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-1}% > --- > > \label{sec-7-5-1}% > 1157c1144 > < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-2}% > --- > > \label{sec-7-5-2}% > 1160c1147 > < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-3}% > --- > > \label{sec-7-5-3}% > 1163c1150 > < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-4}% > --- > > \label{sec-7-5-4}% > 1166c1153 > [...] > > I attach a tarball with a simple example where the new exporter with > > Org-mode version 7.9.2 (release_7.9.2-432-g545166 @ > /home/nick/elisp/org-mode/lisp/) > GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of > 2012-09-21 > > Thank you, I will try it, and see if that will clear up the issue. > > > does the right thing. BTW, I think the old exporter mishandles my simple example (and slightly modified variants) in various ways. I would recommend that you try the new exporter at this point. Nick
Re: [O] new exporter: too many blank lines in .org results in missing images from src blocks
Hello, Robert Klein writes: > The export of the file below doesn't always include the image in the > export (that is, no image, not even a missing image). > > When there is only one blank line after #+end_src, the image in > included. Two or more blank lines, and there is no image. in tex files > there is no \includegraphics, in html exports " > Same happens when the org file ends after #+end_src and there are more > than two blank lines. (That happened with the file I encountered the > issue first. And, of course, didn't "see" any difference to a org file > where exporting worked... :-) It should be fixed now. Thanks again for the report. Regards, -- Nicolas Goaziou
Re: [O] [New exporter] Wrong export to LaTeX
Hi Nicolas and Suvayu, Suvayu Ali wrote: >> However, I thought that LaTeX_CLASS had been renamed EXPORT_LaTeX_CLASS, but >> when using the latter, I get frames inside an `article' documentclass type of >> document -- while using `C-c E l O' (for Beamer)? That results in a weird >> document... > > I believe that is the property name only for subtree export. So when > exporting a file, use: > > #+LaTeX_CLASS: beamer > > for subtree export use: > > * Beamer presentation > :PROPERTIES: > :EXPORT_LaTeX_CLASS: beamer > :END: Nicolas, do you confirm the fact that keywords differ whether they apply to the file or to a subtree? If yes, wouldn't make sense to remove such a distinction, or (at the other extreme of the spectrum) to make all keywords share that same feature (prefixing with "EXPORT_" for subtrees)? Best regards, Seb -- Sebastien Vauban
Re: [O] multiline agenda and/or two-pane agenda selection
On 10/15/2012 12:50 PM, François Allisson wrote: Le lundi 15 oct 2012 à 13:10:58 (-0400), Nick Dokos a écrit : Try instead of. You can also try the follow mode, with the key "F" in the agenda view. And then move with "n" and "p". If you like it and would like to make it by default, just add (setq org-agenda-start-with-follow-mode t) in your .emacs . It will perhaps even solve your second point? Excellent, thanks to both of you! -- Ben Escoto
[O] [PATCH] Babel: add results value support to Scala
* lisp/ob-scala.el (org-babel-scala-wrapper-method): Use an scala block enclosing the submitted code The string representing an well formed block was not an Scala code. I put the string from the user into an block, surrounded by an call to replace the default output stream. 0001-Babel-add-results-value-support-to-Scala.patch Description: Binary data
Re: [O] Typographical error in org.texi (org-show-todo-key should be org-show-todo-tree)
Hello, Troy Will writes: > I spotted an obvious typographical error in the Org mode manual. There is > no "org-show-todo-key" function. Change "org-show-todo-key" to > "org-show-tree" on line 3785 of org.texi to fix. Fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] Latex error "too deeply nested" only for #+INCLUDE statements
Good afternoon, On Mon, Oct 15, 2012 at 2:24 PM, Nick Dokos wrote: > Percival du Chat Gris wrote: > > > Good day, > > > > I've tried googling, reading faqs and the like, and have come up empty. > > > > If I have a number of stub files, with the information in them that I > want to pull into multiple > > documents, and I #+INCLUDE them in a file, I get the latex "too deeply > nested" error. > > Please provide details and, if possible, a minimal example. > Sorry about that, I was hoping, perhaps, it was a known problem, and I was just failing to find the FAQ. > Who produces this error? The LaTeX -> PDF conversion that happens after I do C-c C-e p from the Export.log file [...] LaTeX Font Info:Font shape `T1/fvs/bx/n' in size <14.4> not available (Font) Font shape `T1/fvs/b/n' tried instead on input line 68. LaTeX Font Info:Font shape `T1/fvs/b/n' will be (Font) scaled to size 12.9599pt on input line 68. \tf@toc=\write4 \openout4 = `Export.toc'. [2] LaTeX Font Info:Font shape `T1/fvs/bx/n' in size <12> not available (Font) Font shape `T1/fvs/b/n' tried instead on input line 87. LaTeX Font Info:Font shape `T1/fvs/b/n' will be (Font) scaled to size 10.79993pt on input line 87. LaTeX Font Info:Font shape `TS1/fve/m/n' will be (Font) scaled to size 9.85492pt on input line 96. LaTeX Font Info:Font shape `T1/fve/bx/n' in size <10.95> not available (Font) Font shape `T1/fve/b/n' tried instead on input line 103. LaTeX Font Info:Font shape `T1/fve/b/n' will be (Font) scaled to size 9.85492pt on input line 103. [1] ! LaTeX Error: Too deeply nested. See the LaTeX manual or LaTeX Companion for explanation. Type H for immediate help. ... l.236 \begin{itemize} ? H You're in trouble here. Try typingto proceed. If that doesn't work, type X to quit. ? [2] ! LaTeX Error: Too deeply nested. See the LaTeX manual or LaTeX Companion for explanation. Type H for immediate help. ... l.268 \begin{itemize} ? ! LaTeX Error: Too deeply nested. And that repeats over and over again. > What is the exact output? Unfortunately there isn't any output. > What version of org/emacs? > Org-mode: Version: 7.9.2-1 Emacs: Version: 23.3.a-3 Are you using the new exporter or the old exporter? > How would I be able to tell? > > If the error is produced by latex, export to latex and look at the .tex > file. If the error is produced by org, it > would help to have a backtrace. > Well ... I presume the error is produced by Latex, because I can get the same thing if I run LaTex Export.tex, but if I replace all the #+INCLUDE references with the contents of the files themselves, in the .org file, it works, so I think it's an .org problem, in producing the .tex files, not (necessarily) a LaTex problem. I think (not being an expert) it seems that, with the stub-based file (Export.tex), the single * in each of the #+INCLUDEed files becomes a subsection, as opposed to an actual section (as it did in Export-1.tex), since a section of the diff file between the .tex files produced looks something like: diff Export.tex Export-1.tex [...] 1144a1132,1133 > \subsection{Dynamic Interactions} > \label{sec-7-5} 1146,1147d1134 < \item Dynamic Interactions\\ < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5}% 1154c1141 < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-1}% --- > \label{sec-7-5-1}% 1157c1144 < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-2}% --- > \label{sec-7-5-2}% 1160c1147 < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-3}% --- > \label{sec-7-5-3}% 1163c1150 < \label{sec-1-1-4-5-1-6-5-1-10-5-1-4-5-1-4-5-1-5-4}% --- > \label{sec-7-5-4}% 1166c1153 [...] > I attach a tarball with a simple example where the new exporter with > > Org-mode version 7.9.2 (release_7.9.2-432-g545166 @ > /home/nick/elisp/org-mode/lisp/) > GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of > 2012-09-21 > Thank you, I will try it, and see if that will clear up the issue. > > does the right thing. > > Nick > > > If, however, > > I simply insert the files into the buffer, then they will create the PDF > via latex export without a > > problem. Is there something in the #+INCLUDE code that adds a nested > layer such that it becomes > > problematic for PDF production? If so, is there a better route to > create PDF files? I have been > > using Latex and HTML export for a while, so I'm not entirely familiar > with any other options that > > might produce PDF files as cleanly. While I can (and have) written a > script to pull all the pieces > > together into one large file, there should be an easier way. > > > >
[O] Typographical error in org.texi (org-show-todo-key should be org-show-todo-tree)
Hi, I spotted an obvious typographical error in the Org mode manual. There is no "org-show-todo-key" function. Change "org-show-todo-key" to "org-show-tree" on line 3785 of org.texi to fix. Regards, Troy
Re: [O] Latex error "too deeply nested" only for #+INCLUDE statements
Percival du Chat Gris wrote: > Good day, > > I've tried googling, reading faqs and the like, and have come up empty. > > If I have a number of stub files, with the information in them that I want to > pull into multiple > documents, and I #+INCLUDE them in a file, I get the latex "too deeply > nested" error. Please provide details and, if possible, a minimal example. Who produces this error? What is the exact output? What version of org/emacs? Are you using the new exporter or the old exporter? If the error is produced by latex, export to latex and look at the .tex file. If the error is produced by org, it would help to have a backtrace. I attach a tarball with a simple example where the new exporter with Org-mode version 7.9.2 (release_7.9.2-432-g545166 @ /home/nick/elisp/org-mode/lisp/) GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.4) of 2012-09-21 does the right thing. Nick > If, however, > I simply insert the files into the buffer, then they will create the PDF via > latex export without a > problem. Is there something in the #+INCLUDE code that adds a nested layer > such that it becomes > problematic for PDF production? If so, is there a better route to create PDF > files? I have been > using Latex and HTML export for a while, so I'm not entirely familiar with > any other options that > might produce PDF files as cleanly. While I can (and have) written a script > to pull all the pieces > together into one large file, there should be an easier way. > doc.tgz Description: doc.org and three included files
Re: [O] Latex error "too deeply nested" only for #+INCLUDE statements
Hello Percival, Percival du Chat Gris wrote: > I've tried googling, reading faqs and the like, and have come up empty. > > If I have a number of stub files, with the information in them that I want > to pull into multiple documents, and I #+INCLUDE them in a file, I get the > latex "too deeply nested" error. If, however, I simply insert the files > into the buffer, then they will create the PDF via latex export without a > problem. Is there something in the #+INCLUDE code that adds a nested layer > such that it becomes problematic for PDF production? If so, is there a > better route to create PDF files? I have been using Latex and HTML export > for a while, so I'm not entirely familiar with any other options that might > produce PDF files as cleanly. While I can (and have) written a script to > pull all the pieces together into one large file, there should be an easier > way. It makes me think at lists of levels 5 or more. Are you including your source files at deep levels? Best regards, Seb -- Sebastien Vauban
[O] Latex error "too deeply nested" only for #+INCLUDE statements
Good day, I've tried googling, reading faqs and the like, and have come up empty. If I have a number of stub files, with the information in them that I want to pull into multiple documents, and I #+INCLUDE them in a file, I get the latex "too deeply nested" error. If, however, I simply insert the files into the buffer, then they will create the PDF via latex export without a problem. Is there something in the #+INCLUDE code that adds a nested layer such that it becomes problematic for PDF production? If so, is there a better route to create PDF files? I have been using Latex and HTML export for a while, so I'm not entirely familiar with any other options that might produce PDF files as cleanly. While I can (and have) written a script to pull all the pieces together into one large file, there should be an easier way. Thank you, Percival
Re: [O] Bug: behaviour of org-agenda-earlier with org-agenda-span
Hello, Dieter Faulbaum writes: > I have a problem in org-version 7.9.2 (from emacs-snapshot): > if I set org-agenda-span to custom 14 (not day, week, month or year) > than the function org-agenda-earlier doesn't go back anymore, it goes > forward instead of. > If I switch the view by org-agenda-week-view or org-agenda-day-view, the > function org-agenda-earlier goes back as expected. > In think this is a bug (by the way it works fine in org-version > 7.8.11)? Thanks for the report. IIRC, it was fixed recently in master branch. You may want to test the development version or wait the next merge with Emacs. Regards, -- Nicolas Goaziou
Re: [O] multiline agenda and/or two-pane agenda selection
Le lundi 15 oct 2012 à 13:10:58 (-0400), Nick Dokos a écrit : > Ben wrote: > > > Hi all, > > > > I hope this isn't in the FAQ or documentation---I tried to look > > through both according to the instructions but this seems like a basic > > question so my apologies if I'm missing something stupid. > > > > I'm starting to use org-mode and its agenda view and like it a lot. > > However, I would like to modify it so one of two things happen: > > > > 1) Easy agenda navigation > > --- > > > > Currently I like how I can press Enter (bound to org-agenda-switch-to > > apparently) in the agenda view and it will show me the relevant spot > > in an org file. However, it replaces the agenda view with the org > > file, meaning I have to switch back to the agenda file and press extra > > keystrokes. > > > > Try instead of . > > Nick > > You can also try the follow mode, with the key "F" in the agenda view. And then move with "n" and "p". If you like it and would like to make it by default, just add (setq org-agenda-start-with-follow-mode t) in your .emacs . It will perhaps even solve your second point? François.
Re: [O] multiline agenda and/or two-pane agenda selection
Ben wrote: > Hi all, > > I hope this isn't in the FAQ or documentation---I tried to look > through both according to the instructions but this seems like a basic > question so my apologies if I'm missing something stupid. > > I'm starting to use org-mode and its agenda view and like it a lot. > However, I would like to modify it so one of two things happen: > > 1) Easy agenda navigation > --- > > Currently I like how I can press Enter (bound to org-agenda-switch-to > apparently) in the agenda view and it will show me the relevant spot > in an org file. However, it replaces the agenda view with the org > file, meaning I have to switch back to the agenda file and press extra > keystrokes. > Try instead of . Nick
[O] multiline agenda and/or two-pane agenda selection
Hi all, I hope this isn't in the FAQ or documentation---I tried to look through both according to the instructions but this seems like a basic question so my apologies if I'm missing something stupid. I'm starting to use org-mode and its agenda view and like it a lot. However, I would like to modify it so one of two things happen: 1) Easy agenda navigation --- Currently I like how I can press Enter (bound to org-agenda-switch-to apparently) in the agenda view and it will show me the relevant spot in an org file. However, it replaces the agenda view with the org file, meaning I have to switch back to the agenda file and press extra keystrokes. I almost always use emacs with two windows open (tiled side by side in one frame). Is it possible for Enter to open up the org file in the other window, leaving the agenda window unchanged? I found the org-agenda-window-setup command, but it seems to govern how the agenda window is displayed instead of how the agenda opens other windows. 2) Multi-line agenda listings -- If that isn't possible or recommended, it would be nice if I could have a bit more information at a glance in the agenda view. Sometimes I can't tell in my agenda what a TODO item is because it's out of context. For instance, if in my org file it says * Client XYZ * TODO Call Bob about paperwork SCHEDULED: <2012-10-15 Mon> Then in the agenda it says: Monday15 October 1012 work:Scheduled:TODO Call Bob about paperwork This is good but sometimes I wonder which "Bob" or what "paperwork" it's talking about. For me I think it would be nicer if the heading it's under would also appear, so the agenda view would look like: Monday15 October 1012 work:Scheduled:Client XYZ TODO Call Bob about paperwork so I have a bit more context. Perhaps other lines could be displayed too depending on the settings. Thanks for any ideas, -- Ben
Re: [O] export of #+INCLUDE appears broken with :exports results
Hi Sebastien, Sebastien Vauban writes: > Did you try first locally in the same file? Eh? Include the file in itself? If you mean did I execute the source block: yes, and it works. > Did you try with downcase for the TBLNAME keyword? I know it (all upper or > down-case) was important at some point in time, but don't remember if this is > still of importance. I have tried all those variations, and using #+name instead of #+tblname the only thing that makes a difference is removing ":exports results". I think it a bug. Myles
[O] Bug: behaviour of org-agenda-earlier with org-agenda-span
I have a problem in org-version 7.9.2 (from emacs-snapshot): if I set org-agenda-span to custom 14 (not day, week, month or year) than the function org-agenda-earlier doesn't go back anymore, it goes forward instead of. If I switch the view by org-agenda-week-view or org-agenda-day-view, the function org-agenda-earlier goes back as expected. In think this is a bug (by the way it works fine in org-version 7.8.11)? Emacs : GNU Emacs 24.2.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2) Dieter
Re: [O] export of #+INCLUDE appears broken with :exports results
Hi Myles, Myles English wrote: > Trying to export as ascii an included file fails with "Reference > 'example-table' not found in this buffer". > > Is this a bug? > > This is the contents of the file I run C-c C-e a from: > > * Main > #+INCLUDE: "./org-example.org" > > Where org-example.org contains only the example at > http://orgmode.org/org.html#Tables but with the adition of ":exports > results": > > #+TBLNAME: example-table > | 1 | > | 2 | > | 3 | > | 4 | > > #+NAME: table-length > #+BEGIN_SRC emacs-lisp :var table=example-table :exports results > (length table) > #+END_SRC > > And the error is: > > Debugger entered--Lisp error: (error "Reference 'example-table' not found in > this buffer") Did you try first locally in the same file? Did you try with downcase for the TBLNAME keyword? I know it (all upper or down-case) was important at some point in time, but don't remember if this is still of importance. Best regards Seb -- Sebastien Vauban
[O] export of #+INCLUDE appears broken with :exports results
Hi, Trying to export as ascii an included file fails with "Reference 'example-table' not found in this buffer". Is this a bug? This is the contents of the file I run C-c C-e a from: * Main #+INCLUDE: "./org-example.org" Where org-example.org contains only the example at http://orgmode.org/org.html#Tables but with the adition of ":exports results": #+TBLNAME: example-table | 1 | | 2 | | 3 | | 4 | #+NAME: table-length #+BEGIN_SRC emacs-lisp :var table=example-table :exports results (length table) #+END_SRC And the error is: Debugger entered--Lisp error: (error "Reference 'example-table' not found in this buffer") signal(error ("Reference 'example-table' not found in this buffer")) error("Reference '%s' not found in this buffer" "example-table") org-babel-ref-resolve("example-table") org-babel-ref-parse("table=example-table") #[(el) "A:\203 A\207\301A!\207" [el org-babel-ref-parse] 2]((:var . "table=example-table")) mapcar(#[(el) "A:\203A\207\301A!\207" [el org-babel-ref-parse] 2] ((:var . "table=example-table"))) org-babel-process-params(((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "no") (:tangle . "no") (:exports . "results") (:results . "replace") (:var . "table=example-table") (:session . "none") (:padnewline . "yes") (:hlines . "yes") (:colnames . "no"))) org-babel-exp-src-block(("emacs-lisp" ":var" "table=example-table" ":exports" "results")) org-export-blocks-preprocess() org-export-preprocess-string(#("\n* Main\n#+INCLUDE: \"./org-example.org\"\n" 0 1 (fontified t) 1 3 (fontified t face org-level-1) 3 7 (fontified t face org-level-1) 7 8 (fontified t) 8 38 (fontified t font-lock-fontified t face org-meta-line) 38 39 (fontified t)) :for-backend ascii :skip-before-1st-heading nil :drawers nil :tags not-in-toc :priority nil :footnotes t :timestamps t :todo-keywords t :tasks t :verbatim-multiline t :select-tags ("export") :exclude-tags ("noexport") :archived-trees headline :add-text nil) org-export-as-ascii(nil) call-interactively(org-export-as-ascii) org-export(nil) call-interactively(org-export nil nil) Thanks, Myles
Re: [O] Bug: org-read-date: problem with year in dotted european date input [7.9.2 (release_7.9.2-436-g9b11e6 @ /home/grfz/src/org-mode/lisp/)]
Hello, Carsten Dominik writes: > I fixed the documentation. Thank you. Regards, -- Nicolas Goaziou
Re: [O] #+BEGIN_COMMENT latex export issue
Hi, I have solved the problem after removing all the relevant packages and reinstalling. Some left over packages were causing trouble and reinstalling was not of any help. Thanks. - *Sanjib Sikder *Ph.D. Fellow Chemical Engineering IIT Bombay* * On Mon, Oct 15, 2012 at 4:13 PM, Sanjib Sikder wrote: > Hi, > > #+BEGIN_COMMENT > Some text > #+END_COMMENT > > The above code is not working on my desktop while it runs without any > error on my laptop. I have same .emacs set up for both desktop and laptop. > I am getting the following error message. > > byte-code: unbalanced begin/end_comment blocks with #("#+BEGIN_COMMENT > " 0 15 (fontified nil font-lock-fontified t) 15 16 (fontified nil > font-lock-fontified t)) > > > Thanks. > > Following is the corresponding part in my .emacs > > (custom-set-variables > ;; custom-set-variables was added by Custom. > ;; If you edit it by hand, you could mess it up, so be careful. > ;; Your init file should contain only one such instance. > ;; If there is more than one, they won't work right. > '(TeX-PDF-mode t t) > '(TeX-source-correlate-method (quote synctex)) > '(TeX-source-correlate-mode t) > '(TeX-source-correlate-start-server t) > '(TeX-view-program-list (quote (("Okular" "okular --unique > %o#src:%n%b" > '(TeX-view-program-selection (quote ((output-pdf "Okular") ((output-dvi > style-pstricks) "dvips and gv") (output-dvi "xdvi") (output-html > "xdg-open" > '(org-modules (quote (org-bbdb org-bibtex org-docview org-gnus org-info > org-jsinfo org-irc org-mew org-mhe org-rmail *org-special-blocks* org-vm > org-wl org-w3m))) > '(show-paren-mode t)) > (custom-set-faces > ;; custom-set-faces was added by Custom. > ;; If you edit it by hand, you could mess it up, so be careful. > ;; Your init file should contain only one such instance. > ;; If there is more than one, they won't work right. > '(default ((t (:inherit nil :stipple nil :background "white" :foreground > "black" :inverse-video nil :box nil :strike-through nil :overline nil > :underline nil :slant normal :weight normal :height 98 :width normal > :foundry "unknown" :family "Liberation Sans") > > - > *Sanjib Sikder > *Ph.D. Fellow > Chemical Engineering > IIT Bombay* > > * > >
[O] #+BEGIN_COMMENT latex export issue
Hi, #+BEGIN_COMMENT Some text #+END_COMMENT The above code is not working on my desktop while it runs without any error on my laptop. I have same .emacs set up for both desktop and laptop. I am getting the following error message. byte-code: unbalanced begin/end_comment blocks with #("#+BEGIN_COMMENT " 0 15 (fontified nil font-lock-fontified t) 15 16 (fontified nil font-lock-fontified t)) Thanks. Following is the corresponding part in my .emacs (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(TeX-PDF-mode t t) '(TeX-source-correlate-method (quote synctex)) '(TeX-source-correlate-mode t) '(TeX-source-correlate-start-server t) '(TeX-view-program-list (quote (("Okular" "okular --unique %o#src:%n%b" '(TeX-view-program-selection (quote ((output-pdf "Okular") ((output-dvi style-pstricks) "dvips and gv") (output-dvi "xdvi") (output-html "xdg-open" '(org-modules (quote (org-bbdb org-bibtex org-docview org-gnus org-info org-jsinfo org-irc org-mew org-mhe org-rmail *org-special-blocks* org-vm org-wl org-w3m))) '(show-paren-mode t)) (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(default ((t (:inherit nil :stipple nil :background "white" :foreground "black" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 98 :width normal :foundry "unknown" :family "Liberation Sans") - *Sanjib Sikder *Ph.D. Fellow Chemical Engineering IIT Bombay* *
[O] new exporter: too many blank lines in .org results in missing images from src blocks
Hello, I found another issue with the new exporter. The export of the file below doesn't always include the image in the export (that is, no image, not even a missing image). When there is only one blank line after #+end_src, the image in included. Two or more blank lines, and there is no image. in tex files there is no \includegraphics, in html exports " "Count slowly to ten" --> "Count slowly backwards to zero" --> "Relax" --> (*) #+end_src * next section Lorem ipsum dolor sit amet... --- snip --- snip ---
Re: [O] Publishing using the new exporter
Hallo, On 10/11/2012 11:55 PM, Nicolas Goaziou wrote: > Hello, > > Robert Klein writes: > >> I did some more tests and it seems the issue happens when Emacs is just >> started and nothing (much) done in it. >> >> Test description below. > > Thank you for the thorough testing. I was able to reproduce the bug and > you're right: setting default-directory is the only way out. I've > committed a patch doing this. > > If you confirm that the problem is solved, I'll also apply the same > changes to e-texinfo, e-man and e-groff back-ends. > sorry for the late answer. I run all tests again plus a couple additional ones using a bigger project: The image exports work as expected. (I ran into another "no image" issue and had to verify it isn't related to this issue. It isn't.) Thanks a lot for the help. Best regards Robert
[O] [Patch] Table lookup functions: director's cut
Greetings. Here is the newest version of the patch implementing table lookup functions. First, to see what these little functions can do, take a look at http://orgmode.org/worg/org-tutorials/org-lookups.html Please note that the patch is not in the official git repository yet, so you can not replicate the examples in the tutorial. When and if I get the word that the patch has been applied, I will add a link to the tutorial in the main tutorial page on Worg. A few notes on the patch: 1. There is now a third lookup function org-lookup-all, which I thought would be a very useful addition. 2. The three lookup functions are still defined by calls to a single macro. Heck, one of the advertised reasons for using Lisp are its macro capabilities, so I could not resist. The generated documentation strings now contain a reference to the macro, so users can locate the macro in org-table.el. 3. CL is no longer used in the implementation. I decided to implement the search using a while control structure. I wanted to do a tail recursive implementation, but then found out that Emacs Lisp does not do tail-call optimization. If you'd like me to use a different control structure (for some reason), I can change it. 4. Technically R-LIST is now an optional parameter in the lookup functions, because if it is nil, the matching value from S-LIST is returned directly. I decided not to define it to be an optional parameter, because that would simply look weird to a first-time user: the default use would then be to find a value and return the same value, which would not make much sense. Have fun! Jarmo >From dfa552f2e8b61ce301900dcce7da92d4f8f0854a Mon Sep 17 00:00:00 2001 From: Jarmo Hurri Date: Mon, 15 Oct 2012 09:54:24 +0300 Subject: [PATCH] Table lookup functions * lisp/org-table.el: added macro org-define-lookup-function and the calls to this macro that generate the lookup functions org-lookup-first, org-lookup-last and org-lookup-all * doc/org.texi: documented lookup functions --- doc/org.texi | 50 -- lisp/org-table.el | 32 2 files changed, 80 insertions(+), 2 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index c8f0afb..6d8f59a 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -378,6 +378,7 @@ The spreadsheet * Durations and time values:: How to compute durations and time values * Field and range formulas::Formula for specific (ranges of) fields * Column formulas:: Formulas valid for an entire column +* Lookup functions::Lookup functions for searching tables * Editing and debugging formulas:: Fixing formulas * Updating the table:: Recomputing all dependent fields * Advanced features:: Field and column names, parameters and automatic recalc @@ -2397,6 +2398,7 @@ formula, moving these references by arrow keys * Durations and time values:: How to compute durations and time values * Field and range formulas::Formula for specific (ranges of) fields * Column formulas:: Formulas valid for an entire column +* Lookup functions::Lookup functions for searching tables * Editing and debugging formulas:: Fixing formulas * Updating the table:: Recomputing all dependent fields * Advanced features:: Field and column names, parameters and automatic recalc @@ -2782,7 +2784,7 @@ can also be used to assign a formula to some but not all fields in a row. Named field, see @ref{Advanced features}. @end table -@node Column formulas, Editing and debugging formulas, Field and range formulas, The spreadsheet +@node Column formulas, Lookup functions, Field and range formulas, The spreadsheet @subsection Column formulas @cindex column formula @cindex formula, for table column @@ -2821,7 +2823,51 @@ stores it. With a numeric prefix argument(e.g.@: @kbd{C-5 C-c =}) the command will apply it to that many consecutive fields in the current column. @end table -@node Editing and debugging formulas, Updating the table, Column formulas, The spreadsheet +@node Lookup functions, Editing and debugging formulas, Column formulas, The spreadsheet +@subsection Lookup functions +@cindex lookup functions in tables +@cindex table lookup functions + +Org has three predefined Emacs Lisp functions for lookups in tables. +@table @code +@item (org-lookup-first VAL S-LIST R-LIST &optional PREDICATE) +@findex org-lookup-first +Searches for the first element @code{S} in list @code{S-LIST} for which +@lisp +(PREDICATE VAL S) +@end lisp +is @code{t}; returns the value from the corresponding position in list +@code{R-LIST}. The default @code{PREDICATE} is @code{equal}. Note that the +parameters @code{VAL} and @code{S} are passed to @code{PREDICATE} in the same +order as the correspoding parameters are in the call to +@code{org-lookup-first}, where @code{VAL} precedes @code{S-LIST}. If +@code{R-LIST} is @cod
[O] org-end-of-line
Hello, When pressing `C-e' to go to the last char of a looong sentence, such as: azroiu zrouz eruzepr ozeioru zoepru zoeruozieuriozerusdjflsdfjsdksjfsdfs df sdjf sdf sdsd fklsdjf sdj sdjlksdjf sqfjsdjf sdfklsjdjsdsdjlkmskfjsldkjfsdjfoizeoi xcsdf zerfze ze rrz zer ze sdf sd d g erg ry er fscvf dsr yh yt re gfsd f er gt z'y reg er fsd cf,sk jfshfsdc kle eozifsdnc sslk kzdjf dsl jfsdljf sdilkj fzefoizejfsdlkf sklqjfoiezrfoi it goes up to the last char of the visual line, would that line be truncated. In every other mode I've looked at (Message, Emacs Lisp, etc.), `C-e' does go to the end of the physical line, _with the same untouched settings_ for `line-move-visual' (set to `t' in `simple.el'). Why does Org behave differently? See line 21613 in org.el: #+begin_src emacs-lisp (call-interactively (cond ((org-bound-and-true-p line-move-visual) 'end-of-visual-line) ; ((fboundp 'move-end-of-line) 'move-end-of-line) (t 'end-of-line #+end_src Best regards, Seb -- Sebastien Vauban