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/)]
I fixed the documentation. - Carsten On 14.10.2012, at 09:57, Nicolas Goaziou wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: Org used to have the ambition to parse a date in the middle of a text, and this six what you are seeing in the documentation. However, over time more and more different requests came in, to parse ISO weeks, European dates and more. Also we want to allow incomplete dates like leaving out a year etc. I still think Org does a pretty god job there. However, to be reasonably predictable we did have o restrict matching of special dates to the beginning of the string, and this is what you and Nicolas are now seeing. It may be worth specifying that restriction in the documentation. As Gregor pointed out But it will in fact accept any string containing some date and/or time information, and it is really smart about interpreting your input. is misleading. Regards, -- Nicolas Goaziou
[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
[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 jarmo.hu...@syk.fi
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
Re: [O] Publishing using the new exporter
Hallo, On 10/11/2012 11:55 PM, Nicolas Goaziou wrote: Hello, Robert Klein klein...@mpip-mainz.mpg.de 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] 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 img src... is missing. 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... :-) Best regards Robert --- snip --- snip --- # -*- fill-column:75; coding: utf-8-unix; -*- #+TITLE: file1 * plantuml diagram #+begin_src plantuml :file example.png :exports results @startuml title Todo for something (*) -- Count slowly to ten -- Count slowly backwards to zero -- Relax -- (*) #+end_src * next section Lorem ipsum dolor sit amet... --- snip --- snip ---
[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* *
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 sanjibju2...@gmail.comwrote: 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* *
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 carsten.domi...@gmail.com writes: I fixed the documentation. Thank you. Regards, -- Nicolas Goaziou
[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] 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] 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 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] 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] multiline agenda and/or two-pane agenda selection
Ben mis...@emerose.org 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 SPACE instead of ENTER. Nick
Re: [O] multiline agenda and/or two-pane agenda selection
Le lundi 15 oct 2012 à 13:10:58 (-0400), Nick Dokos a écrit : Ben mis...@emerose.org 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 SPACE instead of ENTER. 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] Bug: behaviour of org-agenda-earlier with org-agenda-span
Hello, Dieter Faulbaum m...@faulbaum.in-berlin.de 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
[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] 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
Re: [O] Latex error too deeply nested only for #+INCLUDE statements
Percival du Chat Gris percyha...@gmail.com 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
[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
Good afternoon,
On Mon, Oct 15, 2012 at 2:24 PM, Nick Dokos nicholas.do...@hp.com wrote:
Percival du Chat Gris percyha...@gmail.com 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 return for immediate help.
...
l.236 \begin{itemize}
? H
You're in trouble here. Try typing return to proceed.
If that doesn't work, type X return to quit.
?
[2]
! LaTeX Error: Too deeply nested.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return 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.
Re: [O] Typographical error in org.texi (org-show-todo-key should be org-show-todo-tree)
Hello, Troy Will troydw...@gmail.com 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
[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] 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 : TrySPACE instead ofENTER. 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
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] new exporter: too many blank lines in .org results in missing images from src blocks
Hello, Robert Klein klein...@mpip-mainz.mpg.de 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 img src... is missing. 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] Latex error too deeply nested only for #+INCLUDE statements
Percival du Chat Gris percyha...@gmail.com 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
[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] [New exporter] Wrong export to LaTeX
Hello, Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org 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] 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 dt%s/dtdd desc-tag)) ((and (equal type o) counter) (format li value=\%s\ counter)) (t li))) 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 dt class=org-dt.../dt dd class=org-dd.../dd li class=org-li.../li or something similar. This should provide enough hooks for people to work with. Thanks, Derek -- Derek Upham s...@blarg.net
