[O] [PATCH] Remove org-time-clocksum-use-effort-durations
* lisp/org.el (org-time-clocksum-use-effort-durations): Remove variable. (org-minutes-to-clocksum-string): Remove references. * lisp/org-clock.el (org-clocktable-write-default): Remove references. We would like the following identity to hold: (= (org-duration-string-to-minutes 3d 2h) (org-duration-string-to-minutes (org-minutes-to-clocksum-string (org-duration-string-to-minutes 3d 2h) Previously, this was only true if org-time-clocksum-use-effort-durations was non-nil (not the default), since org-duration-string-to-minutes unconditionally looks at org-effort-durations, whereas org-minutes-to-clocksum-string only considers it if org-time-clocksum-use-effort-durations is non-nil. To remove confusion, since org uses org-effort-durations unconditionally everywhere else when interpreting duration strings, just remove this customisation option and use org-effort-durations in org-minutes-to-clocksum-string as well. --- lisp/org-clock.el | 2 -- lisp/org.el | 32 ++-- 2 files changed, 6 insertions(+), 28 deletions(-) Bastien wrote: Hi Lawrence, Lawrence Mitchell we...@gmx.li writes: I would argue that (org-duration-string-to-minutes (org-minutes-to-clocksum-string (org-duration-string-to-minutes some-value))) Should be a no-op. But that is only the case if org-time-clocksum-use-effort-durations is t. Agreed. Thanks for the clear explanations. Can you provide a patch to get the correct behavior? At the time, I could not closely watch the side-effect of introducing `org-time-clocksum-use-effort-durations' and this is clearly one of them. Here we go. I think the right thing to do is just remove org-time-clocksum-use-effort-durations completely. If this is wanted, I can add the appropriate entry to ORG-NEWS as well. Lawrence diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 8ac215e..cc6b9c1 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -2337,8 +2337,6 @@ from the dynamic block definition. (maxlevel (or (plist-get params :maxlevel) 3)) (emph (plist-get params :emphasize)) (level-p (plist-get params :level)) -(org-time-clocksum-use-effort-durations - (plist-get params :effort-durations)) (timestamp (plist-get params :timestamp)) (properties (plist-get params :properties)) (ntcol (max 1 (or (plist-get params :tcolumns) 100))) diff --git a/lisp/org.el b/lisp/org.el index adb5fb1..581536d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2978,20 +2978,6 @@ See `org-time-clocksum-format' for more on time clock formats. :version 24.3 :type 'boolean) -(defcustom org-time-clocksum-use-effort-durations nil - When non-nil, \\[org-clock-display] uses effort durations. -E.g. by default, one day is considered to be a 8 hours effort, -so a task that has been clocked for 16 hours will be displayed -as during 2 days in the clock display or in the clocktable. - -See `org-effort-durations' on how to set effort durations -and `org-time-clocksum-format' for more on time clock formats. - :group 'org-time - :group 'org-clock - :version 24.4 - :package-version '(Org . 8.0) - :type 'boolean) - (defcustom org-time-clocksum-fractional-format %.2f The format string used when creating CLOCKSUM lines, or when Org mode generates a time duration, if @@ -17521,21 +17507,15 @@ effort string \2hours\ is equivalent to 120 minutes. Format number of minutes as a clocksum string. The format is determined by `org-time-clocksum-format', `org-time-clocksum-use-fractional' and -`org-time-clocksum-fractional-format' and -`org-time-clocksum-use-effort-durations'. +`org-time-clocksum-fractional-format'. (let ((clocksum ) (m (round m)) ; Don't allow fractions of minutes h d w mo y fmt n) -(setq h (if org-time-clocksum-use-effort-durations - (cdr (assoc h org-effort-durations)) 60) - d (if org-time-clocksum-use-effort-durations - (/ (cdr (assoc d org-effort-durations)) h) 24) - w (if org-time-clocksum-use-effort-durations - (/ (cdr (assoc w org-effort-durations)) (* d h)) 7) - mo (if org-time-clocksum-use-effort-durations -(/ (cdr (assoc m org-effort-durations)) (* d h)) 30) - y (if org-time-clocksum-use-effort-durations - (/ (cdr (assoc y org-effort-durations)) (* d h)) 365)) +(setq h (or (cdr (assoc h org-effort-durations)) 60) + d (or (/ (cdr (assoc d org-effort-durations)) h) 24) + w (or (/ (cdr (assoc w org-effort-durations)) (* d h)) 7) + mo (or (/ (cdr (assoc m org-effort-durations)) (* d h)) 30) + y (or (/ (cdr (assoc y org-effort-durations)) (* d h)) 365)) ;; fractional format (if org-time-clocksum-use-fractional (cond -- 1.8.2-rc3
Re: [O] Effort entry and confusing effort estimates
Bastien wrote: Hi Ken, Ken Mankoff mank...@gmail.com writes: But I'm still confused what 'org-set-effort' expects/interprets compared to 'org-clock-modify-effort-estimate'. Any clarification will be much appreciated. `org-set-effort' allows you to _set_ the effort value. `org-clock-modify-effort-estimate' allows you to either set the effort value (e.g. if you enter 1:30, the old value will be replaced by this one) or to increment/decrement the effort value by using +mm or +n[hdwmy] -- e.g. entering +1d will increment the current value by 1 day. 1 day is interpreted depending on `org-effort-durations', which see. I think the problem is slightly more complicated. org-set-effort does: read some effort duration (org-entry-put nil Effort duration-we-just-read) org-clock-modify-effort-estimate does: read some effort duration (org-duration-string-to-minutes value) convert this duration in minutes back to a string (org-minutes-to-clocksum-string minutes-corresponding-to-value) (org-entry-put nil Effort duration-we-just-calculated) So org-set-effort doesn't do any conversion of the effort string we enter. org-clock-modify-effort-estimate does do conversion. However, it does it badly. org-duration-string-to-minutes always uses org-effort-durations to convert the input string to minutes. However, org-minutes-to-clocksum-string /only/ uses org-effort-durations if org-time-clocksum-use-effort-durations is non-nil (not the default). The problem boils down to: (let ((org-time-clocksum-use-effort-durations nil)) (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered (org-duration-string-to-minutes ;; what gets inserted (org-minutes-to-clocksum-string (org-duration-string-to-minutes 3d 2h) = nil (let ((org-time-clocksum-use-effort-durations t)) (= (org-duration-string-to-minutes 3d 2h) ;; what the user entered (org-duration-string-to-minutes ;; what gets inserted (org-minutes-to-clocksum-string (org-duration-string-to-minutes 3d 2h) = t I would argue that (org-duration-string-to-minutes (org-minutes-to-clocksum-string (org-duration-string-to-minutes some-value))) Should be a no-op. But that is only the case if org-time-clocksum-use-effort-durations is t. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] [PATCH] ox-html: Ensure space between tag and attribute when closing tags
* lisp/ox-html.el (org-html-close-tag): Add space before attr. We might get an attribute to a tag with no space at its start. Rather than auditing all callers, unconditionally separate the tag from its attributes with a space when closing the tag. --- lisp/ox-html.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Robert Eckl wrote: The space between img and the attribute width is missing. Attributes coming from the buffer didn't get a space prepended. Here's a fix. diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 05b99bf..0379567 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -1301,7 +1301,7 @@ CSS classes, then this prefix can be very useful. (member dt '(html5 xhtml5 !doctype html (defun org-html-close-tag (tag attr info) - (concat tag (or attr ) + (concat tag attr (if (org-html-xhtml-p info) / ))) (defun org-html--make-attribute-string (attributes) -- 1.8.2-rc3
Re: [O] [PATCH] ox-html: Ensure space between tag and attribute when closing tags
Bastien wrote: Hi Lawrence, Lawrence Mitchell we...@gmx.li writes: * lisp/ox-html.el (org-html-close-tag): Add space before attr. thanks for the patch -- can you make it against the maint branch so that we include this in the next minor release? It does not apply against master. It won't apply against maint because the ox-html changes that introduced the problem (9bc55c, Export to various flavors of (X)HTML) are on master, not maint. My patch definitely applies against master: $ git checkout master $ git describe release_8.0.2-91-g29ab1bb $ git am ... $ git diff origin/master diff --git c/lisp/ox-html.el w/lisp/ox-html.el index 05b99bf..0379567 100644 --- c/lisp/ox-html.el +++ w/lisp/ox-html.el @@ -1301,7 +1301,7 @@ CSS classes, then this prefix can be very useful. (member dt '(html5 xhtml5 !doctype html (defun org-html-close-tag (tag attr info) - (concat tag (or attr ) + (concat tag attr (if (org-html-xhtml-p info) / ))) (defun org-html--make-attribute-string (attributes) -- Lawrence Mitchell we...@gmx.li
Re: [O] Exporting large documents
[Reintroducing org mailing list CC] On 05/05/2013 20:21, Nicolas Goaziou wrote: Carsten Dominik carsten.domi...@gmail.com writes: I don't think there's much to do about that. Though, some tools could benefit from caching, like Lawrence did for `org-export-resolve-fuzzy-link'. Could you point out specific ones where it would make sense? Maybe someone would like to take this up as a task. It requires some careful benchmarking. Though, good candidates are tools searching for an object or element within the full parse tree. This includes: - org-export-footnote-first-reference-p - org-export-get-footnote-number - org-export-get-category - org-export-resolve-coderef - org-export-resolve-radio-link - org-export-get-loc - org-export-get-ordinal I wonder if it would be possible to store a copy of the parse tree in a form that is more amenable to log or constant time searches. However, I note that my caching of the fuzzy link stuff brought the quadratic time export of copies of the org manual introduction down to linear (or close to) time. Most of the problem now seems to be that for big documents, many functions are called a /lot/. For example: org-element--current-element takes (on my machine) 0.0003 seconds per call. However, when exporting 128x the orgmanual introduction, it's called around 25 times giving ~ 80 seconds total time (out of ~200 total). So it sort of feels like actually what is needed is microoptimisations of the bits of the export engine that are called the most. Lawrence -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Re: [O] Exporting large documents
Lawrence Mitchell wrote: [...] And here's the profile for exporting the whole of orgmanual.org to latex. You can see that a lot of the time comes from quite cheap functions that are called lots. org-latex-export-as-latex 1 415.52740777 415.52740777 org-export-to-buffer 1 414.89446185 414.89446185 org-export-as 1 414.89314727 414.89314727 org-entry-get 362909 377.15499961 0.0010392550 org-export-execute-babel-code 1 248.09360062 248.09360062 org-babel-exp-process-buffer 1 248.08328800 248.08328800 org-babel-exp-src-block137 243.10403972 1.7744820417 org-export-data33704 241.13159257 0.0071543909 org-babel-get-src-block-info 3811241.06197704 0.0632542579 org-babel-parse-src-block-match3811239.00537768 0.0627146097 org-babel-exp-do-export137 238.11539604 1.7380685842 org-babel-exp-code 137 237.68002300 1.7348906788 org-babel-expand-noweb-references 24 237.62374387 9.9009893283 org-babel-params-from-properties 3811237.29706205 0.0622663505 org-entry-get-with-inheritance 99086 234.87738424 0.0023704396 org-get-property-block 322856 121.21322218 0.0003754405 org-macro-replace-all 2 112.94112931 56.470564655 org-element-context8588107.43778316 0.0125102216 org-element-at-point 8976101.79823538 0.0113411581 org-element--current-element 236519 91.414278451 0.0003864986 org-up-heading-safe263822 84.507423221 0.0003203198 org-element--parse-elements311340.774293673 0.0130980705 org-back-to-heading1209279 40.394825581 3.340...e-05 org-element-headline-parser59033 32.808386543 0.0005557634 org-before-first-heading-p 272799 32.791086826 0.0001202023 org-list-struct803520.801415973 0.0025888507 org-element-map19598 20.466600874 0.0010443208 org-latex-link 341 19.91215084 0.0583934042 org-export-resolve-fuzzy-link 281 19.879402747 0.0707452055 ... Functions taking less than 15 seconds cumulative time elided. -- Lawrence Mitchell we...@gmx.li
Re: [O] Exporting large documents
Carsten Dominik wrote: Hi Lawrence, thanks for doing this. Stuff to think about - but no good ideas for improvements here either - I am just not familiar enough with the export engine. Nicolas, it would be interesting to hear from you if you have comments and ideas about quadratic behavior of the exporter, and if you think these are inevitable. My guess is that quadratic behavior would mostly result from searches of the data structure. From the data you show it seems that most of the damage is done during export, not during parsing. Yes, I think that's right. The parse tree is built in one pass I think, but some of the export requires walking over this tree a lot. It's unclear to me if this is necessary or not, or if the export could be built with a single linear pass over the parse tree. Lawrence
[O] [PATCH v2] ox: Cache locations of fuzzy links
* ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a cache before trying to resolve it in the parse tree. When a document contains a large number of identical fuzzy links, it doesn't make sense to continually search for them. Instead, cache the locations in the position independent case. --- lisp/ox.el | 42 +- 1 file changed, 29 insertions(+), 13 deletions(-) Changes since v1: - Pull initialisation of link-cache into let - Don't use cons cells for keys, just use the path - lift found check to top-level let since it's now common Nicolas Goaziou wrote: Hello, Lawrence Mitchell we...@gmx.li writes: * ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a cache before trying to resolve it in the parse tree. Thanks for your patch. A few comments follow. [...] Minor nitpick: I'd rather have this included in the (let ...), like: (let (... (link-cache (or (plist-get info :fuzzy-link-cache) (plist-get (setq info (plist-put info :fuzzy-link-cache (make-hash-table :test 'eq))) :fuzzy-link-cache) I've made this change. Barring the eq test. Remember, paths are strings and two strings are only eq or eql if they are actually the same string (in memory). In particular: (let ((p foo)) (eq (substring p 1) (substring p 1))) = nil (let ((p foo)) (eql (substring p 1) (substring p 1))) = nil (let ((p foo)) (equal (substring p 1) (substring p 1))) = t Hence, we must use equal or string-equal as a test in the hash table. But string-equal isn't a predefined test, hence equal. [...] I don't get why you need to use such a key. Simply use the link as key and `eq' as the test. I was worried that I'd have the same key pointing to two different places, but I see now that those worries were unfounded, since if we didn't see it in the path case the first time we never will. I've simplified the key to just look for the path. diff --git a/lisp/ox.el b/lisp/ox.el index 88b4122..6aa8617 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -3976,27 +3976,43 @@ significant. ;; Split PATH at white spaces so matches are space ;; insensitive. (path (org-split-string - (if match-title-p (substring raw-path 1) raw-path + (if match-title-p (substring raw-path 1) raw-path))) +;; Cache for locations of fuzzy links that are not position dependent +(link-cache + (or (plist-get info :fuzzy-link-cache) + (plist-get (setq info (plist-put info :fuzzy-link-cache + (make-hash-table :test 'equal))) +:fuzzy-link-cache))) +(found-in-cache (gethash path link-cache 'fuzzy-link-not-found))) (cond ;; First try to find a matching path unless user specified ;; he was looking for a headline (path starts with a * ;; character). ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) 'target -(lambda (blob) - (and (equal (org-split-string (org-element-property :value blob)) - path) - blob)) -info t))) + (or (not (eq found-in-cache 'fuzzy-link-not-found)) + (puthash path + (org-element-map (plist-get info :parse-tree) 'target + (lambda (blob) + (and (equal (org-split-string +(org-element-property :value blob)) + path) +blob)) + info t) + link-cache ;; Then try to find an element with a matching #+NAME: path ;; affiliated keyword. ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) - org-element-all-elements -(lambda (el) - (let ((name (org-element-property :name el))) -(when (and name (equal (org-split-string name) path)) el))) -info 'first-match))) + (or (not (eq found-in-cache 'fuzzy-link-not-found)) + (puthash path + (org-element-map (plist-get info :parse-tree) + org-element-all-elements + (lambda (el) + (let ((name (org-element-property :name el))) + (when (and name +(equal (org-split-string name) path)) + el))) + info 'first-match) + link-cache ;; Last case: link either points to a headline or to nothingness. ;; Try to find the source, with priority given to headlines with ;; the closest common ancestor
[O] [PATCH] ox: Cache locations of fuzzy links
* ox.el (org-export-resolve-fuzzy-link): Look for fuzzy link in a cache before trying to resolve it in the parse tree. When a document contains a large number of identical fuzzy links, it doesn't make sense to continually search for them. Instead, as long as we're looking for position independent links, cache the locations and look there first. --- lisp/ox.el | 48 +++- 1 file changed, 35 insertions(+), 13 deletions(-) Achim Gratz wrote: Lawrence Mitchell writes: I did a bit of digging and here are the results. No potential fixes though. I couldn't see how to fix up org-export-data, but here's some band-aid to speed up resolving fuzzy links. It works much better for the fake test case (where there are many identical links) than the real org manual, but I do get a slight improvement (about 6%). As per elp: Before: org-latex-export-to-latex 1 373.02289908 373.02289908 org-export-resolve-fuzzy-link 281 42.108304211 0.1498516164 After: org-latex-export-to-latex 1 349.7238257 349.7238257 org-export-resolve-fuzzy-link 281 19.329938028 0.0687898150 Cheers, Lawrence diff --git a/lisp/ox.el b/lisp/ox.el index 88b4122..bb49512 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -3976,27 +3976,49 @@ significant. ;; Split PATH at white spaces so matches are space ;; insensitive. (path (org-split-string - (if match-title-p (substring raw-path 1) raw-path + (if match-title-p (substring raw-path 1) raw-path))) +(link-cache (plist-get info :fuzzy-link-cache))) +;; Cache for locations of fuzzy links that are not position dependent +(unless link-cache + (setq info (plist-put info :fuzzy-link-cache + (make-hash-table :test 'equal))) + (setq link-cache (plist-get info :fuzzy-link-cache))) (cond ;; First try to find a matching path unless user specified ;; he was looking for a headline (path starts with a * ;; character). ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) 'target -(lambda (blob) - (and (equal (org-split-string (org-element-property :value blob)) - path) - blob)) -info t))) + (let ((found (gethash (cons 'path path) +link-cache +'fuzzy-link-not-found))) +(or (not (eq found 'fuzzy-link-not-found)) +(puthash (cons 'path path) + (org-element-map (plist-get info :parse-tree) 'target + (lambda (blob) + (and (equal (org-split-string + (org-element-property :value blob)) + path) + blob)) + info t) + link-cache) ;; Then try to find an element with a matching #+NAME: path ;; affiliated keyword. ((and (not match-title-p) - (org-element-map (plist-get info :parse-tree) - org-element-all-elements -(lambda (el) - (let ((name (org-element-property :name el))) -(when (and name (equal (org-split-string name) path)) el))) -info 'first-match))) + (let ((found (gethash (cons 'name path) +link-cache +'fuzzy-link-not-found))) +(or (not (eq found 'fuzzy-link-not-found)) +(puthash (cons 'name path) + (org-element-map (plist-get info :parse-tree) + org-element-all-elements + (lambda (el) + (let ((name (org-element-property :name el))) + (when (and name (equal +(org-split-string name) +path)) + el))) + info 'first-match) + link-cache) ;; Last case: link either points to a headline or to nothingness. ;; Try to find the source, with priority given to headlines with ;; the closest common ancestor. If such candidate is found, -- 1.8.2-rc3
Re: [O] Exporting large documents
Carsten Dominik wrote: Hi Achim, this is an interesting experiment, thank you! I think it would also be interesting to use elp to see which function are taking up the non-linear time. I did a bit of digging and here are the results. No potential fixes though. Taking the Introduction section of orgmanual.org and doubling it up so the buffer is 16x, 32x, 64x and 128x copies of the introduction and then running latex export having elp-instrumented the org package shows the following. There are a few instances of quadratic behaviour that contribute to the slowdown. Main culprit: Name times-called cumulative-time time-per-call org-export-data 10132 29.364160173 0.0028981603 org-export-data 20180 90.198301053 0.0044696878 org-export-data 40276 316.37200089 0.0078550998 org-export-data 80468 1155.4851323 0.0143595607 Less important but still a noticeable total runtime: org-element-map 1133 2.6814707420 0.0023666996 org-element-map 2285 10.799367732 0.0047262003 org-element-map 4589 43.787327887 0.0095418016 org-element-map 9197 173.27839595 0.0188407519 org-export-resolve-fuzzy-link 48 2.6659073480 0.0555397364 org-export-resolve-fuzzy-link 96 10.766515020 0.1121511981 org-export-resolve-fuzzy-link 192 43.725658059 0.2277378023 org-export-resolve-fuzzy-link 384 173.15348462 0.4509205328 org-latex-link 144 2.6730487589 0.0185628386 org-latex-link 288 10.783675007 0.0374433159 org-latex-link 576 43.768676906 0.0759872862 org-latex-link 1152 173.27176368 0.1504095170 Unimportant but still quadratic: org-export-get-headline-number 176 0.0036720380 2.086...e-05 org-export-get-headline-number 352 0.0154215390 4.381...e-05 org-export-get-headline-number 704 0.0636496679 9.041...e-05 org-export-get-headline-number 1408 0.2382477599 0.0001692100 org-babel-get-inline-src-block-matches 112 0.0174396369 0.0001557110 org-babel-get-inline-src-block-matches 224 0.0521645539 0.0002328774 org-babel-get-inline-src-block-matches 448 0.182069907 0.0004064060 org-babel-get-inline-src-block-matches 896 0.66889546 0.0007465351 org-babel-remove-result 112 0.0332858050 0.0002971946 org-babel-remove-result 224 0.0837776260 0.0003740072 org-babel-remove-result 448 0.2475016210 0.0005524589 org-babel-remove-result 896 0.8013491290 0.0008943628 org-babel-where-is-src-block-result 112 0.0320815769 0.0002864426 org-babel-where-is-src-block-result 224 0.081381881 0.0003633119 org-babel-where-is-src-block-result 448 0.2425831529 0.0005414802 org-babel-where-is-src-block-result 896 0.7915090309 0.0008833806 Cheers, Lawrence
Re: [O] getting a tilde into LaTeX export
Eric Abrahamsen wrote:
I'm sure this has been answered many times but I can't find it…
I want to get a tilde into my LaTeX export -- not a LaTeX-escaped tilde,
but a plain tilde, that will turn into a small non-breaking space in
LaTeX. Everything I've tried in org exports as either \~ or \~{} in
LaTeX, where all I want is plain ~. Can someone help me out?
hello \nbsp goodbye
= hello ~ goodbye
Although I can't figure out a way of having no extra whitespace
on both sides of the ~.
Lawrence
--
Lawrence Mitchell we...@gmx.li
Re: [O] Table formula not returning an error
Sebastien Vauban wrote: [...] But I'm surprised I did not see any error reported. This is a feature of org-hh:mm-string-to-minutes: | Convert a string H:MM to a number of minutes. | If the string is just a number, interpret it as minutes. | In fact, the first hh:mm or number in the string will be taken, | there can be extra stuff in the string. ^^ | If no number is found, the return value is 0. It's arguable that this is the best choice, but it is one. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] bug#9610: 24.0.90; org-mode: sluggish response and high CPU utilization with large .org files
Steve Revilak wrote: I'd like to report an org-mode regression issue. When working with large .org files, Emacs 24.0.90 becomes sluggish, and consumes large amounts of CPU. If you type this: M-x set-variable RET bidi-paragraph-direction RET left-to-right RET does the problem go away? My bug report contained two scenarios to produce sluggish response and high CPU utilization. These scenarios were (1) move point to the end of buffer, and start typing (2) Put point in line 1, column zero; press and hold the down (then up) arrows to move point down (then up) the org-mode buffer. Setting bidi-paragraph-direction: left-to-right eliminates the problem with scenario (1). However, it has no effect on scenario (2). Setting bidi-display-reordering to nil in the buffer has the effect that moving point is no longer jerky for me. Lawrence
Re: [O] unexpected failure on all formulas
Nick Dokos wrote: [...] I cribbed heavily from the implementation of vmedian. Although there is no key binding, you can even use the above in an interactive Calc session, by entering the formula in algebraic form. I yanked the vector twice onto the Calc stack and then entered 'vmode($) with the following result: This does the wrong thing for bimodal lists of numbers, since the correct answer in that case is the list of modes. Here's an elisp implementation that's a bit shorter: (require 'cl) (defun mode (rest list) (let ((ret nil) val count) (loop for n in list if (assq n ret) do (incf (cdr (assq n ret))) else do (push (cons n 1) ret)) (setq ret (sort ret (lambda (a b) ( (cdr a) (cdr b) (setq val (list (caar ret)) count (cdar ret)) (loop for (n . c) in (cdr ret) while (= c count) do (push n val)) val)) And here's how to use it in the proffered table: | Date Stamp | Systalic | Diastalic | Pulse | |+--+---+---| | [2011-07-19 Tue 02:26] | 138 |92 |74 | | [2011-07-20 Wed 04:03] | 130 |85 |74 | |+--+---+---| | min| 130 |85 |74 | | max| 138 |92 |74 | | mode | 138, 130 |92, 85 |74 | #+TBLFM: @II+1$2..@II+1$4=vmin(@I..@II)::@II+2$2..@II+2$4=vmax(@I..@II)::@II+3$2..@II+3$4='(mapconcat 'number-to-string (mode @I..@II) , );N Lawrence -- Lawrence Mitchell we...@gmx.li
[O] [PATCH] org-latex: Convert quote marks in section headers
* lisp/org-latex.el (org-export-latex-fontify-headline): Convert
quotes to their LaTeX equivalents using
org-export-latex-quotation-marks.
---
Xin Shi wrote:
Hello,
I'm using the org-mode 7.5 in Emacs 23.3.
I noticed this lines in org:
** ``Internal'' and External Example
``Internal'' and External Examples in paragraph
will result in tex:
\section{``Internal'' and External Example}
\label{sec-1_1}
``Internal'' and ``External'' Examples in paragraph
One can see that the quotation in the heading line is not translated
properly into TeX.
Is this a bug?
It would appear to be so, though I'm not sure if the decision not
to convert quotation marks is a deliberate one. Although looking
at the commit logs, it would appear that it's probably an oversight.
lisp/org-latex.el |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 8abe1d2..bc7644a 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1589,6 +1589,7 @@ links, keywords, lists, tables, fixed-width
(when (plist-get org-export-latex-options-plist :emphasize)
(org-export-latex-fontify))
(org-export-latex-time-stamps)
+(org-export-latex-quotation-marks)
(org-export-latex-keywords-maybe)
(org-export-latex-special-chars
(plist-get org-export-latex-options-plist :sub-superscript))
--
1.7.4.1
Re: [O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it
Eric Schulte wrote: Hi Lawrence, Is there a reason to make this copy? Given that params is used like a hash/dictionary the order of it's elements should not matter. Is there a case where this patch is necessary to avoid buggy behavior? Ah, but the sorting is happening so that the hashing function is stable to changes in the order of the arguments, no? So I think sorting is necessary. At least, the sort was already there, I've just added the copy-sequence. If so then I'm happy to apply the patch, but if there is no need then I'd rather avoid the (admittedly small) overhead of making a copy of the params list. [...] It seems to be necessary to correctly link to the produced graphics output from (say) R plotting if :cache yes is specified. Try this without the patch: * header #+begin_src R :cache yes :exports results :file plot.png :results graphics curve(1*x, from=1, to=10, lwd=2) #+end_src #+results: and evaluate the code block, we get: #+results[4d3e7ef5e40f7b608d400c310401c15e913a22c0]: : plot.png Rather than the (correct): #+results[4d3e7ef5e40f7b608d400c310401c15e913a22c0]: [[file:plot.png]] The problem is that (sort v 'string) destructively modifies v, and in this case, that means that the file argument to :result-params in thrown away. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] [PATCH 1/2] lisp/ob.el: Fix org-babel-result-regexp to match users
* lisp/ob.el (org-babel-result-regexp): Use non-shy group around org-babel-data-names. By default regexp-opt returns a shy group around its arguments. But users of org-babel-result-regexp expect the third match-string to contain the hash. With a shy group, the second match-string contains the hash. --- lisp/ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 27f005c..e1f4372 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -310,7 +310,7 @@ specific header arguments as well.) (defvar org-babel-result-regexp (concat ^[ \t]*#\\+ - (regexp-opt org-babel-data-names) + (regexp-opt org-babel-data-names t) \\(\\[\\([[:alnum:]]+\\)\\]\\)?\\:[ \t]*) Regular expression used to match result lines. If the results are associated with a hash key then the hash will -- 1.7.4.1
[O] [PATCH 2/2] lisp/ob.el: Don't modify babel info when hashing it
* lisp/ob.el (org-babel-sha1-hash): Don't modify info argument by side-effect when sorting result-params list. copy-sequence only does shallow copies, so if we're going to modify a sub-list, we need to make sure we copy it first. --- lisp/ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index e1f4372..36649f0 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -767,7 +767,7 @@ the current subtree. (cond ((and (listp v) ; lists are sorted (member (car arg) '(:result-params))) - (sort v #'string)) + (sort (copy-sequence v) #'string)) ((and (stringp v) ; strings are sorted (member (car arg) '(:results :exports))) (mapconcat #'identity (sort (split-string v) -- 1.7.4.1
Re: [O] [Orgmode] Re: [Feature Request] Cross headings in tables
On 31/05/2011 08:21, Carsten Dominik wrote: [...] Finally: this patch goes clearly beyond the TINYCHANGE limits. What is yours, and Lawrence's copyright status with the FSF? I have papers with the FSF for past and future changes to Emacs, so I believe my contributions are covered. Lawrence
Re: [O] Export options being ignored
Carsten Dominik wrote: On 5.5.2011, at 07:08, Nick Dokos wrote: [...] explains the problem: \ matches the empty string at the beginning of a word (i.e. if the syntax class of the next character is word) but it does not at the beginning of a char that is of some other syntax class (I think it will not match anything in this case). So Eden diagnosed it correctly: it *is* a parsing problem and it *does* involve the non-word options. This is fixed now, by looking for white space instead of beginning-of-word. Thanks for the analysis. Indeed, thanks. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] Re: [BUG] Crash with LaTeX exporter
Jambunathan K wrote: [1. text/plain] Exporting the below table to LaTeX throws an error. Let me know if you need any additional info. [2. text/x-verbatim] *** Table.el Table with no Spanning +---+---+ |Term |Percentage | +---+---+ |Quarter|25%| |One-Fourth | | +---+---+ |Half |50%| |One-by-Two | | +---+---+ |Three-Quarters |75%| |Three-Fourths | | +---+---+ |Full |100% | |Whole | | +---+---+ [3. text/plain] A more minimal table demonstrating the problem is: +---+---+ |foo|bar| +---+---+ |baz|33%| +---+---+ This is because the percent signs are escaped in the table that table.el sees, but the column width is not updated appropriately. The export process converts % into \% so that table.el sees the following table: +---+---+ |foo|bar| +---+---+ |baz|33\%| +---+---+ And so column/row calculations are incorrect. Since table.el's export correctly deals with escaping of percent signs, one could just remove the escapes from the table. It's possible that something like the below would fix things. diff --git a/lisp/org-latex.el b/lisp/org-latex.el index b8be87a..d591358 100644 --- a/lisp/org-latex.el +++ b/lisp/org-latex.el @@ -1963,6 +1963,9 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER. floatp (or label caption)) (and (get-buffer *org-export-table*) (kill-buffer (get-buffer *org-export-table*))) +(save-excursion + (while (search-forward \\% nil t) + (replace-match % nil t))) (table-generate-source 'latex *org-export-table* caption) (setq tbl (with-current-buffer *org-export-table* (buffer-string))) Patchwork maintainers, please don't pick this up, it's a horrible fix :P. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] [PATCH] org-latex: Fix export of table.el tables with captions
* lisp/org-latex.el (org-export-latex-convert-table.el-table): Fix
format-string for insertion of captions.
This fixes a bug introduced in caa5da1 since when the caption itself
is not placed inside the caption command.
---
lisp/org-latex.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index d60e174..b8be87a 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1991,7 +1991,7 @@ The conversion is made depending of STRING-BEFORE and
STRING-AFTER.
(setq tbl (concat \\begin{center}\n tbl \\end{center})))
(when floatp
(setq tbl (concat \\begin{table}\n
- (format \\caption%s{%s}%s\n
+ (format \\caption%s{%s%s}\n
(if shortn (format [%s] shortn) )
(if label (format \\label{%s} label) )
(or caption ))
--
1.7.4.rc2.18.gb20e9
[O] Re: [PATCH] org-latex: Don't append newline to end of footnote
Nicolas wrote: Hello, Lawrence Mitchell we...@gmx.li writes: [...] The analysis is good, but unfortunately the patch has a flaw. In fact, your patch work in that particular situation, but not if a footnote definition ends with a list, nor if it ends with a link. To solve the latter, you need to insert a white-space before the closing bracket. To solve the former, I thought adding a newline instead of the white-space was enough, but it now appears it was a bad idea. Thus, the solution lies elsewhere. Ugh, indeed. I wonder whether it would be enough to add the correct list indent to the beginning of the line with the closing brace. ALthough I notice without my patch, the export of a footnote containing a list which is in a list also does not work: - Hello [fn:1] * Footnotes [fn:1] Goodbye - an item No idea how to fix this though, sorry. Lawrence -- Lawrence Mitchell we...@gmx.li
[O] [PATCH] org-html: Fix logic for export of section numbers
* lisp/org-html.el (org-export-as-html) (org-html-level-start): Fix logic for section number printing when NUM is an integer. Fixes a bug introduced in 9f57b8e which considered all non-integer values of the num option to be nil. --- Bernt Hansen wrote: Hi Lawrence, Numbering of the Table of Contents is broken in master for HTML export. git bisect identifies the following commit as the cause of this regression. Indeed, I introduced a logic error that considered non-integer values of the num option as nil even when non-nil. I believe this patch fixes the problem, your test case now works as expected again. Cheers, Lawrence lisp/org-html.el | 24 +--- 1 files changed, 13 insertions(+), 11 deletions(-) diff --git a/lisp/org-html.el b/lisp/org-html.el index 62fce1b..48b6740 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -1356,7 +1356,9 @@ lang=\%s\ xml:lang=\%s\ (if (string-match quote-re0 txt) (setq txt (replace-match t t txt))) (setq snumber (org-section-number level)) - (if (and num (integerp num) (= num level)) + (if (and num (if (integerp num) + (= num level) + num)) (setq txt (concat snumber txt))) (if (= level (max umax umax-toc)) (setq head-count (+ head-count 1))) @@ -2404,16 +2406,16 @@ When TITLE is nil, just close all open levels. (setq title (concat (format span class=\section-number-%d\%s/span level -(if (and (integerp num) - ;; fix up num to take into - ;; account the top-level - ;; heading value - (= (+ num -org-export-html-toplevel-hlevel --1) - level)) - snumber -)) +(if (and num + (if (integerp num) + ;; fix up num to take into + ;; account the top-level + ;; heading value + (= (+ num org-export-html-toplevel-hlevel -1) + level) + num)) +snumber + )) title))) (unless (= head-count 1) (insert \n/div\n)) (setq href (cdr (assoc (concat sec- snu) org-export-preferred-target-alist))) -- 1.7.4.rc2.18.gb20e9
[O] [PATCH] org: Match case of todo keywords when determining empty headings
* lisp/org.el (org-point-at-end-of-empty-headline): Bind case-fold-search to nil. --- Samuel Wales wrote: I have found another todo keyword bug of the same type as the other 6. A headline with a word that is the same as a todo keyword but not in upper case has different behavior. Example: * test * Question[] * test Have QUESTION as a todo keyword. Put point at the marked spot. Press TAB. The headline will outdent instead of cycling visibility. It should cycle visibility as it does with other headlines. This is because the check for an empty heading thinks Question is a todo keyword, because it doesn't match the case of the values in org-todo-keywords. This patch fixes the problem by binding case-fold-search to nil in the relevant place. Cheers, Lawrence lisp/org.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 28025ea..7a4c504 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19649,8 +19649,9 @@ empty. (and (looking-at [ \t]*$) (save-excursion (beginning-of-line 1) - (looking-at (concat ^\\(\\*+\\)[ \t]+\\( org-todo-regexp -\\)?[ \t]*$) +(let ((case-fold-search nil)) + (looking-at (concat ^\\(\\*+\\)[ \t]+\\( org-todo-regexp + \\)?[ \t]*$)) (defun org-at-heading-or-item-p () (or (org-on-heading-p) (org-at-item-p))) -- 1.7.4.rc2.18.gb20e9
[O] [PATCH] org-latex: Don't append newline to end of footnote
* lisp/org-latex.el (org-export-latex-preprocess): Don't add a newline
character to a processed footnote.
The extra newline before the closing } character in a footnote
confuses the list parsing code. The } appears at the beginning of a
line, so it looks like the end of the list. LaTeX gobbles the space
anyway, so don't add it.
---
Hi
if I export the fiollowing snippet
* Project Participants
- Rainer M Krug :: [fn::My email]
My address
The list is closed incorrectly. This appears to be a problem in
the interaction between the list parsing and footnote processing
code. When exporting footnotes, we add a newline at the end, so
in the above example the intermediate file seen by the list
processing code is:
| * Project Participants
| - Rainer M Krug :: \footnote{My email
| }
| ORG-LIST-END-MARKER
| My address
The } at the beginning of the line below the list entry is
considered to end the list, so we get:
| * Project Participants
| \begin{description}
| \item[Rainer M Krug] \footnote{My email
| \end{description}
| }
| ORG-LIST-END-MARKER
| My address
Note how the description list is ended /inside/ the footnote
command.
Since LaTeX gobbles the trailing space in the footnote anyway, it
makes sense not to insert it in the first place, which this patch
does. Your test case now exports correctly.
Cheers,
Lawrence
lisp/org-latex.el |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 0460a84..3eb54b2 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -2432,9 +2432,7 @@ The conversion is made depending of STRING-BEFORE and
STRING-AFTER.
(let ((end (save-excursion
(if (re-search-forward ^$\\|^#.*$\\|\\[[0-9]+\\]
nil t)
(match-beginning 0) (point-max)
-(setq footnote (concat (org-trim (buffer-substring (point)
end))
- ; last } won't be part of a link or
list.
- \n))
+(setq footnote (org-trim (buffer-substring (point) end)))
(delete-region (point) end))
(goto-char foot-beg)
(delete-region foot-beg foot-end)
--
1.7.4.rc2.18.gb20e9
[O] [PATCH] Prefer matching line beginnings in org-export-latex-special-chars
* lisp/org-latex.el (org-export-latex-special-chars): Fix regexp for
`single' special characters and ellipsis.
Repeated special characters are exported differently depending on
their position in the buffer. A string at the start of a line is
exported as \ whereas in the middle of a line you get \\. The
former is incorrect. Fix this by matching the beginning of a line
before a character. While we're at it, amalgamate the regexps for the
different special characters.
---
Suvayu Ali wrote:
Hi Orgers,
I wanted to insert comments in the exported tex file for latex export.
Is there an standard way to do that? I found normal '%text' gets
exported as '\%text'. However I can export comments by putting
'%%text', it gets exported as '%\%text'.
Although this feels like a potentially useful feature, I believe
it is a bug. Doubled special characters are exported differently
depending on where they are on a line:
foo
= \ foo
whereas
foo
= foo \\
This is because the regexp for finding special characters prefers
matching a character over the start of a line \\(.\\|^\\)\\(\\)
will set (match-string 1) to and (match-string 2) to if
occurs at the start of a line, although the intention is that
(match-string 1) should be the empty line-start string and
(match-string 2) the first ampersand. We can fix this by
changing the regexp to \\(^\\|.\\)\\(\\) as in this patch.
Cheers,
Lawrence
lisp/org-latex.el |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 605795c..30f7b4a 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1684,13 +1684,7 @@ See the `org-export-latex.el' code for a complete
conversion table.
\\(\\(?\\$\\)\\)
\\([a-zA-Z0-9()]+\\|[
\t\n]\\|\\b\\|\\)\\(_\\|\\^\\)\\({[^{}]+}\\|[a-zA-Z0-9]+\\|[
\t\n]\\|[:punct:]\\|)\\|{[a-zA-Z0-9]+}\\|([a-zA-Z0-9]+)\\)
\\(.\\|^\\)\\(\\)\\([
\t\n]\\|\\([#%{}\]\\|[a-zA-Z][a-zA-Z0-9]*\\)\\)
- \\(.\\|^\\)\\(\\)
- \\(.\\|^\\)\\(#\\)
- \\(.\\|^\\)\\(%\\)
- \\(.\\|^\\)\\({\\)
- \\(.\\|^\\)\\(}\\)
- \\(.\\|^\\)\\(~\\)
- \\(.\\|^\\)\\(\\.\\.\\.\\)
+ \\(^\\|.\\)\\([#%{}~]\\|\\.\\.\\.\\)
;; (?\ . \\textless{})
;; (?\ . \\textgreater{})
)))
--
1.7.4.rc2.18.gb20e9
[O] [PATCH] Ensure org-export-handle-comments protects its insertions
* lisp/org-exp.el (org-export-handle-comments): Add the org-protected property to the replacement string. Although org-export-handle-comments adds the org-protected property to the matched string, the subsequent `replace-match' call to change the comment character does not add this property to the entire format string. Fix this by propertizing the entirety of the newtext argument to replace-match. --- I think this change makes the actual implementation match the intention of the code, we want the replacement comment character to be protected as well, however, I'm not sure if this breaks the usecases in ob-tangle and the like. lisp/org-exp.el |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 3e84314..da2475e 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -1853,7 +1853,10 @@ When it is nil, all comments will be removed. (not (equal (char-before (match-end 1)) ?+))) (progn (add-text-properties (match-beginning 0) (match-end 0) '(org-protected t)) - (replace-match (format commentsp (match-string 2)) t t)) + (replace-match (propertize + (format commentsp (match-string 2)) + 'org-protected t) + t t)) (goto-char (1+ pos)) (replace-match ) (goto-char (max (point-min) (1- pos -- 1.7.4.rc2.18.gb20e9
[O] [PATCH] Allow mixed export of numbered and unnumbered sections in HTML
* lisp/org-html.el (org-export-as-html): Get local value of org-export-with-section-numbers from the buffer's plist. Deal specially with the case the resulting value is an integer. (org-html-level-start): New optional argument of the option plist used instead of `org-export-with-section-numbers'. Also deal specially with the case that the value is an integer. When `org-export-with-section-numbers' (or the buffer-local :section-numbers option) is an integer, we now export the first NUM levels of headings with numbers and lower-level headings without. --- lisp/org-html.el | 24 ++-- 1 files changed, 18 insertions(+), 6 deletions(-) Nick Dokos wrote: Suvayu Ali fatkasuvayu+li...@gmail.com wrote: This works too, but Lawrence's patch makes it much easier and probably works for other export formats too. Thanks a lot. :) As Nick points out, each exporter backend needs a similar change. No doubt Lawrence's patch can be extended to work for other exports, but it's not there yet: each exporter would need a change similar to the one that he made to the LaTeX exporter. Here's the matching change to the HTML exporter, which is the only other one I'm familiar with. Maintainers, if you don't want the special-casing on integerp, the change to move from `org-export-with-section-numbers' to (plist-get opt-plist :section-numbers) is the correct one anyway. I can split the patches if required. diff --git a/lisp/org-html.el b/lisp/org-html.el index b13fb93..06305f6 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -1150,6 +1150,7 @@ PUB-DIR is set, use this as the publishing directory. (language(plist-get opt-plist :language)) (keywords(plist-get opt-plist :keywords)) (description (plist-get opt-plist :description)) +(num (plist-get opt-plist :section-numbers)) (lang-words nil) (head-count 0) cnt (start 0) @@ -1355,7 +1356,7 @@ lang=\%s\ xml:lang=\%s\ (if (string-match quote-re0 txt) (setq txt (replace-match t t txt))) (setq snumber (org-section-number level)) - (if org-export-with-section-numbers + (if (and num (integerp num) (= num level)) (setq txt (concat snumber txt))) (if (= level (max umax umax-toc)) (setq head-count (+ head-count 1))) @@ -1591,7 +1592,7 @@ lang=\%s\ xml:lang=\%s\ (setq first-heading-pos (or first-heading-pos (point))) (org-html-level-start level txt umax (and org-export-with-toc (= level umax)) - head-count) + head-count opt-plist) ;; QUOTES (when (string-match quote-re line) @@ -1684,7 +1685,7 @@ lang=\%s\ xml:lang=\%s\ (org-html-level-start 1 nil umax (and org-export-with-toc (= level umax)) - head-count) + head-count opt-plist) ;; the /div to close the last text-... div. (when (and ( umax 0) first-heading-pos) (insert /div\n)) @@ -2330,7 +2331,7 @@ If there are links in the string, don't modify these. (insert (if (equal type d) /dd\n /li\n))) (defvar body-only) ; dynamically scoped into this. -(defun org-html-level-start (level title umax with-toc head-count) +(defun org-html-level-start (level title umax with-toc head-count optional opt-plist) Insert a new level in HTML export. When TITLE is nil, just close all open levels. (org-close-par-maybe) @@ -2341,6 +2342,7 @@ When TITLE is nil, just close all open levels. (preferred (and target (cdr (assoc target org-export-preferred-target-alist (l org-level-max) +(num (plist-get opt-plist :section-numbers)) snumber snu href suffix) (setq extra-targets (remove (or preferred target) extra-targets)) (setq extra-targets @@ -2395,10 +2397,20 @@ When TITLE is nil, just close all open levels. (setq snumber (org-section-number level) snu (replace-regexp-in-string \\. _ snumber)) (setq level (+ level org-export-html-toplevel-hlevel -1)) - (if (and org-export-with-section-numbers (not body-only)) + (if (and num (not body-only)) (setq title (concat (format span class=\section-number-%d\%s/span -level snumber) +level +(if (and (integerp num) + ;; fix up num to take into + ;; account the top-level + ;; heading value +
[O] [PATCH] Protect starred commands in LaTeX export correctly
* lisp/org-latex.el (org-export-latex-preprocess): Correctly
match starred command names.
Many LaTeX commands exist in both normal and starred forms. Adjust
the regexp in `org-export-latex-preprocess' to match the starred form
as well.
---
lisp/org-latex.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Eric S Fraga wrote:
Eric Abrahamsen e...@ericabrahamsen.net writes:
Hi,
In a certain org file I put this line into the export options:
#+begin_src org-mode
#+TEXT: \vspace*{0.5in}
#+end_src
Should this not be
#+LATEX: \vspace*{0.5in}
instead of TEXT?
[...]
One could argue that the latex escaping that org does should
include *'ed commands as well... but this may have other repercussions
that I am not aware of.
Indeed it probably should, here's a patch that does exactly that,
avoiding the need for the above workaround. With this change
\vspace*{1cm} is correctly exported like \vspace{1cm}.
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 2acc169..912ebba 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -2364,7 +2364,7 @@ The conversion is made depending of STRING-BEFORE and
STRING-AFTER.
;; Protect LaTeX commands like \command[...]{...} or \command{...}
(goto-char (point-min))
(let ((re (concat
-\\([a-zA-Z]+\\)
+\\([a-zA-Z]+\\*?\\)
\\(?:[^\n]*\\)*
\\(?:\\[[^][\n]*?\\]\\)*
\\(?:[^\n]*\\)*
--
1.7.4.rc2.18.gb20e9
[O] [PATCH] Allow mixed export of numbered and unnumbered sections in LaTeX
* lisp/org-latex.el (org-export-latex-subcontent): Deal specially with
the case that NUM is an integer.
We would sometimes like to have numbered \sections in LaTeX export but
unnumbered \subsections and so forth. That is, use the starred
equivalents for all sectioning commands below a certain level.
Previously, the num: option specification could only specify whether
sections should be numbered or unnumbered at all levels. We now treat
an integer value specially, if num:N is supplied then the highest N
levels are numbered, and lower levels are exported without numbering.
---
lisp/org-latex.el |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
[...]
Wouldn't it be nice if #+OPTIONS: num:2 exported
\section{foo}
\subsection{bar}
\subsubsection*{baz}
It turns out the patch is relatively straightforward. I haven't
included a doc update, but could do so if required.
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index fbdeb5e..7a3c629 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1151,7 +1151,9 @@ and its content.
(defun org-export-latex-subcontent (subcontent num)
Export each cell of SUBCONTENT to LaTeX.
-If NUM, export sections as numerical sections.
+If NUM is non-nil export numbered sections, otherwise use unnumbered
+sections. If NUM is an integer, export the highest NUM levels as
+numbered sections and lower levels as unnumbered sections.
(let* ((heading (cdr (assoc 'heading subcontent)))
(level (- (cdr (assoc 'level subcontent))
org-export-latex-add-level))
@@ -1187,6 +1189,9 @@ If NUM, export sections as numerical sections.
;; Normal conversion
((= level depth)
(let* ((sec (nth (1- level) sectioning))
+(num (if (integerp num)
+ (= num level)
+ num))
start end)
(if (consp (cdr sec))
(setq start (nth (if num 0 2) sec)
--
1.7.4.rc2.18.gb20e9
Re: [O] Slow movement in large buffers
Carsten Dominik wrote: On Mar 15, 2011, at 4:25 AM, Matt Lundin wrote: I've been navigating the org-issues file (14000+ lines) and have found movement within the file to be fairly slow. Sometimes Emacs will lock up for several seconds. For instance, to move from the level one heading * Other to * Closed issues when the outline is folded takes over three seconds: --8---cut here---start-8--- next-line 1 3.015289 3.015289 --8---cut here---end---8--- Wow, this is really bad. Could you use elp and instrument org, outline, and font-lock, and do that motion and report the results? For me, all the time is spent in vertical-motion (which is C level, so I can't get a more detailed breakdown). In my experience, the maximum workable size of org files is around 10,000 lines. Beyond that, Emacs starts to spin its wheels. Not good at all. I believe it is likely to be due to org's large use of overlays. Here's a quote from the elisp manual: | (elisp)Overlays |The visual effect of an overlay is the same as of the corresponding | text property However, due to a different | implementation, *overlays generally don't scale well* (many operations | take a time that is proportional to the number of overlays in the | buffer). If you need to affect the visual appearance of many portions | in the buffer, we recommend using text properties. Emphasis added. For example, in org-issues.org: M-: (loop for l in (overlay-lists) sum (length l)) RET = 3823 And vertical motion (with C-n, C-p) takes a long time. remove all the overlays M-: (remove-overlays) RET collapse the buffer again M-x org-shifttab RET Now vertical motion is rapid. This suggests that one should try and see if overlays in org buffers can be replaced by text properties. Which do not cause the same slowdown. Lawrence -- Lawrence Mitchell we...@gmx.li
Re: [O] Questions on LaTeX Exporter
Thomas S. Dye wrote:
[...]
,
| * section
| #+latex: \label{sec:sec}
`
But there /must/ be a better way to this, eh?
Good point. It would be great to leverage Org-links to resolve cross
references to document sections.
If you do:
(setq org-export-latex-hyperref-format \\ref{%s}) then you can
refer to sections by their numbers with as we see in section
[[section]] and it works nicely.
--
Lawrence Mitchell we...@gmx.li
Re: [O] Questions on LaTeX Exporter
Rasmus wrote: However, I have noticed at least one non-acceptable issue. When using using English, LaTeX (via Babel or just default) full-stops (≈double space) will be inserted after dots. However, with abbrevation one would use an ordinary space (i.e.\ an escaped space (\ ) in LaTeX). Org does not seem to notice abbrivations—how could it?—and further \ is interpreted literaly. I need to have an escaped space. (setq org-entities-user '((space \\ nil))) then this is some text, e.g.\space foo bar = this is some text, e.g.\ foo bar [...] Lawrence -- Lawrence Mitchell we...@gmx.li
Re: [O] Title page in latex export
Suvayu Ali wrote:
Hi Camille,
Thanks a lot for your response.
On Fri, 4 Mar 2011 11:48:39 +0100
Camille persson camille.pers...@gmail.com wrote:
Hi,
I think that what it already does
I don't think it does that. e.g.
Try this patch to org-latex.el:
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 19baa40..4db38d6 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1352,9 +1352,6 @@ OPT-PLIST is the options plist for current buffer.
(org-export-apply-macros-in-string org-export-latex-append-header)
;; define alert if not yet defined
\n\\providecommand{\\alert}[1]{\\textbf{#1}}
- ;; beginning of the document
- \n\\begin{document}\n\n
- ;; insert the title
(format
\n\n\\title{%s}\n
;; convert the title
@@ -1374,6 +1371,9 @@ OPT-PLIST is the options plist for current buffer.
(format-time-string
(or (plist-get opt-plist :date)
org-export-latex-date-format)))
+ ;; beginning of the document
+ \n\\begin{document}\n\n
+ ;; insert the title
;; insert the title command
(when (string-match \\S- title)
(if (string-match %s org-export-latex-title-command)
--
Lawrence Mitchell we...@gmx.li
[O] [PATCH] Support modifiers in effort durations (was: Re: Does Effort support hours only?)
Luke Crook wrote: Is it possible to specify estimated effort in something other than hours (0.5, or 0:30)? For example 1w, 1m, 2d etc? Here's a cleaned up patch that allows user-specified modifiers for effort strings. The new variable `org-effort-durations' lists modifiers, and their mapping to minutes (words, as well as single-letter modifiers, are supported). The default value is: ((h . 60) (d . 480) ; 8 hours (w . 2400) ; five days (m . 9600) ; 4 weeks (y . 96000)) ; 40 weeks But you can change this. Old effort strings (HH:MM) are still interpreted correctly. See the docstrings of `org-effort-durations' and `org-duration-string-to-minutes' for more details. From a0e24b14755eb4087d9c47bb4eea11eb9151efcf Mon Sep 17 00:00:00 2001 From: Lawrence Mitchell we...@gmx.li Date: Fri, 18 Feb 2011 11:01:46 + Subject: [PATCH] Allow human-readable effort durations To: emacs-orgmode@gnu.org * lisp/org.el (org-effort-durations): New variable. * lisp/org.el (org-duration-string-to-minutes): New function. * lisp/org-agenda.el (org-agenda-filter-effort-form) (org-format-agenda-item): Use it. * lisp/org-clock.el (org-clock-notify-once-if-expired) (org-clock-modify-effort-estimate, org-clock-get-clock-string): Use it. Specifying large effort durations in hours and minutes is difficult. Is 130:25 more than two weeks effort? More than three? This patch allows specification of an effort duration as a friendly string. For example 2w 5d is two weeks and five days of effort. Existing H:MM entries will still be recognised correctly. --- lisp/org-agenda.el |4 ++-- lisp/org-clock.el |8 lisp/org.el| 41 + 3 files changed, 47 insertions(+), 6 deletions(-) diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index dee23e0..87602dc 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -5334,7 +5334,7 @@ Any match of REMOVE-RE will be removed from TXT. (get-text-property 0 'org-marker txt))) (error nil))) (when effort - (setq neffort (org-hh:mm-string-to-minutes effort) + (setq neffort (org-duration-string-to-minutes effort) effort (setq effort (concat [ effort ] ) (when remove-re @@ -6061,7 +6061,7 @@ E looks like \+2:25\. ((equal op ??) op) (t '=))) (list 'org-agenda-compare-effort (list 'quote op) - (org-hh:mm-string-to-minutes e + (org-duration-string-to-minutes e (defun org-agenda-compare-effort (op value) Compare the effort of the current line with VALUE, using OP. diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 6b45ca5..cc11f3c 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -487,7 +487,7 @@ If not, show simply the clocked time like 01:50. (m (- clocked-time (* 60 h (if org-clock-effort (let* ((effort-in-minutes - (org-hh:mm-string-to-minutes org-clock-effort)) + (org-duration-string-to-minutes org-clock-effort)) (effort-h (floor effort-in-minutes 60)) (effort-m (- effort-in-minutes (* effort-h 60))) (work-done-str @@ -561,10 +561,10 @@ the mode line. ;; A string. See if it is a delta (setq sign (string-to-char value)) (if (member sign '(?- ?+)) - (setq current (org-hh:mm-string-to-minutes current) + (setq current (org-duration-string-to-minutes current) value (substring value 1)) (setq current 0)) - (setq value (org-hh:mm-string-to-minutes value)) + (setq value (org-duration-string-to-minutes value)) (if (equal ?- sign) (setq value (- current value)) (if (equal ?+ sign) (setq value (+ current value) @@ -581,7 +581,7 @@ the mode line. Show notification if we spent more time than we estimated before. Notification is shown only once. (when (org-clocking-p) -(let ((effort-in-minutes (org-hh:mm-string-to-minutes org-clock-effort)) +(let ((effort-in-minutes (org-duration-string-to-minutes org-clock-effort)) (clocked-time (org-clock-get-clocked-time))) (if (setq org-task-overrun (if (or (null effort-in-minutes) (zerop effort-in-minutes)) diff --git a/lisp/org.el b/lisp/org.el index 03f0b72..9cf1c94 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15499,6 +15499,47 @@ If no number is found, the return value is 0. (string-to-number (match-string 1 s))) (t 0))) +(defcustom org-effort-durations + `((h . 60) +(d . ,(* 60 8)) +(w . ,(* 60 8 5)) +(m . ,(* 60 8 5 4)) +(y . ,(* 60 8 5 40))) + Conversion factor to minutes for an effort modifier. + +Each entry has the form (MODIFIER . MINUTES). + +In an effort string, a number followed by MODIFIER is multiplied +by the specified number of MINUTES to obtain an effort in +minutes. + +For example, if the value of this variable
[Orgmode] Re: Does Effort support hours only?
Sébastien Vauban wrote: Hi Bastien and Luke, Bastien wrote: Luke Crook l...@balooga.com writes: Is it possible to specify estimated effort in something other than hours (0.5, or 0:30)? No, it's not possible right now. But I second this idea: that'd be a great addition. Too often, we have to play with figures such as 64:00 or 80:00 just to indicate 8 or 10 days... Being able to specify suffixes like `d' for days or `w' for weeks would be awesome. But I guess it's very, very complex, though. Turns out probably not, unless I've missed something. I think this set of patches does what's necessary to allow duration strings in effort properties. And as a bonus its backwards compatible to the old style. Try it and see if it works, if it does I'll roll it into a proper patch. diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el index 54de775..6634801 100644 --- a/lisp/org-agenda.el +++ b/lisp/org-agenda.el @@ -5319,7 +5319,7 @@ Any match of REMOVE-RE will be removed from TXT. (get-text-property 0 'org-marker txt))) (error nil))) (when effort - (setq neffort (org-hh:mm-string-to-minutes effort) + (setq neffort (org-duration-string-to-minutes effort) effort (setq effort (concat [ effort ] ) (when remove-re @@ -6046,7 +6046,7 @@ E looks like \+2:25\. ((equal op ??) op) (t '=))) (list 'org-agenda-compare-effort (list 'quote op) - (org-hh:mm-string-to-minutes e + (org-duration-string-to-minutes e (defun org-agenda-compare-effort (op value) Compare the effort of the current line with VALUE, using OP. diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 07cc952..0747210 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -486,7 +486,7 @@ If not, show simply the clocked time like 01:50. (m (- clocked-time (* 60 h (if org-clock-effort (let* ((effort-in-minutes - (org-hh:mm-string-to-minutes org-clock-effort)) + (org-duration-string-to-minutes org-clock-effort)) (effort-h (floor effort-in-minutes 60)) (effort-m (- effort-in-minutes (* effort-h 60))) (work-done-str @@ -560,10 +560,10 @@ the mode line. ;; A string. See if it is a delta (setq sign (string-to-char value)) (if (member sign '(?- ?+)) - (setq current (org-hh:mm-string-to-minutes current) + (setq current (org-duration-string-to-minutes current) value (substring value 1)) (setq current 0)) - (setq value (org-hh:mm-string-to-minutes value)) + (setq value (org-duration-string-to-minutes value)) (if (equal ?- sign) (setq value (- current value)) (if (equal ?+ sign) (setq value (+ current value) @@ -580,7 +580,7 @@ the mode line. Show notification if we spent more time than we estimated before. Notification is shown only once. (when (org-clocking-p) -(let ((effort-in-minutes (org-hh:mm-string-to-minutes org-clock-effort)) +(let ((effort-in-minutes (org-duration-string-to-minutes org-clock-effort)) (clocked-time (org-clock-get-clocked-time))) (if (setq org-task-overrun (if (or (null effort-in-minutes) (zerop effort-in-minutes)) diff --git a/lisp/org.el b/lisp/org.el index 82a0986..3e8fbba 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -15446,6 +15446,32 @@ If no number is found, the return value is 0. (string-to-number (match-string 1 s))) (t 0))) +(defun org-duration-string-to-minutes (s) + Convert a duration string S to minutes. + +A bare number is interpreted as minutes, the following suffixes are +recognised: + h - hours + d - days + w - weeks (7 days) + m - months (30 days) + y - years (365 days) + +Entries containing a colon are interpreted as H:MM by +`org-hh:mm-string-to-minutes'. + (let ((conversion `((h . 60) + (d . ,(* 60 24)) + (w . ,(* 60 24 7)) + (m . ,(* 60 24 7 30)) + (y . ,(* 60 24 7 365 + (result 0)) +(while (string-match \\([0-9]+\\)\\([hdwmy]\\) s) + (incf result (* (cdr (assoc (match-string 2 s) conversion)) + (string-to-number (match-string 1 s + (setq s (replace-match nil t s))) +(incf result (org-hh:mm-string-to-minutes s)) +result)) + Files (defun org-save-all-org-buffers () -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Using latexmk for LaTeX compilation
Dror Atariah wrote: I want to use latexmk as the LaTeX exporting engine, I following this link's (http://orgmode.org/worg/org-faq.html#using-xelatex-for-pdf-export) instruction, but it didn't work. Note, that exporting the .org to .tex file and then manually running latexmk -pdf works flawlessly. This setting works for me to produce pdfs via latexmk. (setq org-latex-to-pdf-process (list latexmk -f -pdf %f)) Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Export error. Have a look at my backtrace?
Jeff Horn wrote: Hey orgsters, Export started behaving weirdly for me earlier this week. When I export to HTML or ASCII to a temporary buffer, I get the attached backtrace. This occurs in emacs 24 (Aquamacs) with org-mode 7.4. The error does not occur if I export to file. Also, exporting to a temporary buffer works as expected in emacs 23.2 with org-mode 7.4 in terminal emacs. Error occurs with every file I have tried in the past few days. Can anyone else reproduce? I'll come up with a minimal working example if needed. This is an Aquamacs specific issue, I believe. What happens is that Emacs tries to guess the major mode of the temporary buffer. Aquamacs has the following entry in either magic-mode-alist, or magic-fallback-mode-alist. (objc-mode-buffer-check . objc-mode) So it calls the objc-mode-buffer-check function, and puts the buffer in objc-mode if the former returns non-nil. Here's the definition of said function: (defun objc-mode-buffer-check () (if (string-match \\.m$ buffer-file-name) (save-restriction (narrow-to-region (point-min) (min (point-max) (+ (point-min) magic-mode-regexp-match-limit))) (looking-at \\(.\\|\n\\)*#\\(include\\|define\\|import\\) The culprit is the first line, this function should first check that buffer-file-name is a string before trying to match against it. So you should probably shout at the Aquamacs developers :P. Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: window rearrangements when exporting to pdf
Stephen Eglen wrote: [...] (emacs-version) GNU Emacs 23.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.0) of 2010-05-24 on maps My guess would be that org-fit-window-to-buffer is doing this. It seems more likely that the call to delete-other-windows in org-export is the cause of the problem. Can you try removing it to see what happens. I presume it is there in case you have an Org buffer and /many/ other small buffers, in that case you don't want to pop up the help message in one of the small buffers, because you might not see it all. Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [Feature Request] Cross headings in tables
Achim Gratz wrote: [...] The first header is still determined like it always was. Headers inside table need to get a special hline, the choice of ~ for this was dictated by most of the other characters already being used for various markup inside or outside tables. When I say halfway there, I mean that the export is working and the lines are recognized as hlines everywhere I could find (there may still be some regexpressions floating around that don't). However, aligning tables will replace the wigglies with plain dashes since I have not yet found a way to inject the correct character for the currently hardcoded -. The HTML export for the above table looks like this: [...] If somebody has an idea how to make the table alignment work, please lend me a hand. Experimental patch is attached, comments are welcome. How about the following two patches on top. The first fixes table alignment, the second fixes LaTeX export of these tables. From c555b7e15b617538490210a041bd4af45e51d752 Mon Sep 17 00:00:00 2001 From: Lawrence Mitchell we...@gmx.li Date: Wed, 2 Feb 2011 12:20:12 + Subject: [PATCH 1/2] Correctly realign tables with internal headers To: emacs-orgmode@gnu.org * lisp/org-table.el (org-table-align): Deal with internal headers (specified by ?~) when realigning. --- lisp/org-table.el | 38 -- 1 files changed, 24 insertions(+), 14 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 9437ae1..498a6fc 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -632,7 +632,7 @@ When nil, simply write \#ERROR\ in corrupted fields.) lines (new ) lengths l typenums ty fields maxfields i column (indent ) cnt frac -rfmt hfmt +rfmt hfmt tfmt (spaces '(1 . 1)) (sp1 (car spaces)) (sp2 (cdr spaces)) @@ -640,6 +640,8 @@ When nil, simply write \#ERROR\ in corrupted fields.) (make-string sp2 ?\ ) %%%s%ds (make-string sp1 ?\ ) |)) (hfmt1 (concat (make-string sp2 ?-) %s (make-string sp1 ?-) +)) +(tfmt1 (concat +(make-string sp2 ?~) %s (make-string sp1 ?~) +)) emptystrings links dates emph raise narrow falign falign1 fmax f1 len c e space) (untabify beg end) @@ -680,17 +682,19 @@ When nil, simply write \#ERROR\ in corrupted fields.) ;; Mark the hlines by setting the corresponding element to nil ;; At the same time, we remove trailing space. (setq lines (mapcar (lambda (l) - (if (string-match ^ *|[-~] l) - nil - (if (string-match [ \t]+$ l) - (substring l 0 (match-beginning 0)) - l))) + (cond ((string-match ^ *|[-] l) +'dash) + ((string-match ^ *|[~] l) +'tilde) + ((string-match [ \t]+$ l) +(substring l 0 (match-beginning 0))) + (t l))) lines)) ;; Get the data fields by splitting the lines. (setq fields (mapcar (lambda (l) (org-split-string l *| *)) - (delq nil (copy-sequence lines + (delq 'dash (delq 'tilde (copy-sequence lines) ;; How many fields in the longest line? (condition-case nil (setq maxfields (apply 'max (mapcar 'length fields))) @@ -770,19 +774,25 @@ When nil, simply write \#ERROR\ in corrupted fields.) (concat (car c) space ;; Compute the formats needed for output of the table -(setq rfmt (concat indent |) hfmt (concat indent |)) +(setq rfmt (concat indent |) hfmt (concat indent |) + tfmt (concat indent |)) (while (setq l (pop lengths)) (setq ty (if (pop typenums) -)) ; number types flushright (setq rfmt (concat rfmt (format rfmt1 ty l)) - hfmt (concat hfmt (format hfmt1 (make-string l ?-) + hfmt (concat hfmt (format hfmt1 (make-string l ?-))) + tfmt (concat tfmt (format tfmt1 (make-string l ?~) (setq rfmt (concat rfmt \n) - hfmt (concat (substring hfmt 0 -1) |\n)) - + hfmt (concat (substring hfmt 0 -1) |\n) + tfmt (concat (substring tfmt 0 -1) |\n)) (setq new (mapconcat (lambda (l) -(if l (apply 'format rfmt - (append (pop fields) emptystrings)) - hfmt)) +(cond ((eq l 'dash) + hfmt) + ((eq l 'tilde) + tfmt) + (t + (apply 'format rfmt + (append (pop fields) emptystrings) lines
[Orgmode] Re: [bug] latex export ignores org-export-latex-default-packages-alist?
Eric S Fraga wrote: I need to use the amsmath package for a paper I am writing. This conflicts, unfortunately, with the wasysym package which is loaded by default in the org-latex exporter. Checking the documentation for org-export-latex-classes, I find: , | - Calls to \usepackage for all packages mentioned in the variables | `org-export-latex-default-packages-alist' and | `org-export-latex-packages-alist'. Thus, your header definitions should | avoid to also request these packages. ` I then checked out the first of these lists and customised it (first, by hand, then by emacs's own customisation method) to turn off the inclusion of wasysym. The value of the variable, upon restarting emacs just to make sure, is: [...] If SNIPPET-FLAG is t, the package also needs to be included when compiling LaTeX snippets into images for inclusion into HTML. You've set SNIPPET-FLAG to nil for wasysym, but this means that wasysym will not be included for compiling latex snippets. When producing the whole document it will still be included. To use wasysym along with amsmath, you need to pass the integrals option to wasysym. To do this, customize the options list of the wasysym entry to be (integrals wasysym t) rather than ( wasysym t) This is what I do to use amsmath in Org exports: | (add-to-list 'org-export-latex-packages-alist '( amsmath t)) | (setcar (rassoc '(wasysym t) org-export-latex-default-packages-alist) | integrals) The latter has to be done after loading org-latex. [...] Cheers, Lawrence ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [BUG/PATCH] Set fill-indent-according-to-mode to nil in Org buffers
* lisp/org.el (org-mode): Locally set `fill-indent-according-to-mode' to nil. `org-adaptive-fill-function' attempts to correctly pick up a fill prefix for hand-indented paragraphs and lists. This is defeated by the indentation code, which does not recognise sublists correctly and gets the indentation wrong. By setting `fill-indent-according-to-mode' to nil, we tell Emacs' filling code to pay attention to `adaptive-fill-prefix' rather than using `indent-line-function'. This is not a perfect solution, since refilling a list entry still does not work correctly unless the entire item is on a single line. --- The filling code is a maze of twisty passages all alike, so I don't really understand what's going on. The problem is demonstrated with auto-fill-mode on when typing sublist entries that wrap over more than a single line #+begin_src org * Header - List + Sublist entry with lots and lots and lots and lots of text is wrapped like this #+end_src org And like this is incorrectly considered to be be part of the List entry, rather than the Sublist entry. This change fixes this problem for auto-fill-mode wrapping, but it doesn't work correctly for refilling, for reasons that are unclear to me. Cheers, Lawrence lisp/org.el |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index fcdf245..268223b 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4716,6 +4716,7 @@ The following commands are available: ;; Paragraphs and auto-filling (org-set-autofill-regexps) (setq indent-line-function 'org-indent-line-function) + (set (make-local-variable 'fill-indent-according-to-mode) nil) (org-update-radio-target-regexp) ;; Beginning/end of defun (org-set-local 'beginning-of-defun-function 'org-beginning-of-defun) -- 1.7.4.rc1.7.g2cf08 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG/PATCH] Set fill-indent-according-to-mode to nil in Org buffers
Nicolas Goaziou wrote: Hello, This is defeated by the indentation code, which does not recognise sublists correctly and gets the indentation wrong. Would you mind elaborating? I fail to see where the indentation code has some problem recognizing lists. Hopefully the example below clears things up a bit. By setting `fill-indent-according-to-mode' to nil, we tell Emacs' filling code to pay attention to `adaptive-fill-prefix' rather than using `indent-line-function'. Not using `org-indent-line-function' sounds like a very bad idea to me. Before ignoring this function, perhaps we could try to see what is wrong with it. This is not a perfect solution, since refilling a list entry still does not work correctly unless the entire item is on a single line. Huh? Again, could you provide an example, please? emacs -Q C-x C-f $TMP/foo.org M-: (erase-buffer) RET M-x auto-fill-mode RET M-: (insert * Header\n- List entry\n - Sublist entry) RET Now type some more text so that the sublist entry line goes past the fill column. Note where the line-wrapping puts the continuation of the sublist entry: 1 | * Header 2 | - List entry 3 | - Sublist entry here we have some more text to make the line very 4 | very long and trigger line-wrapping. So the text on line 4 is considered to be part of the sublist entry, while I would expect it to be so (it would have been if auto-fill-mode were off). If fill-indent-according-to-mode is set to nil then doing the same thing leads to: 1 | * Header 2 | - List entry 3 | - Sublist entry here we have some more text to make the line very 4 | very long and trigger line-wrapping. Notice how in this case the continuation of the sublist entry is correct. Furthermore, if you've formatted the document as in the second example by hand, but fill-indent-according-to-mode is t, and you hit M-q on the sublist entry, the indentation of line 4 is changed from 4 spaces to 2 spaces. This changes line 4 from being part of the sublist entry to being part of the list entry from line 2. Hope this clarifies things. Cheers, Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [BUG/PATCH] Set fill-indent-according-to-mode to nil in Org buffers
Nicolas Goaziou wrote: Lawrence Mitchell writes: Hopefully the example below clears things up a bit. I cannot reproduce it, even when following your steps. This would appear to be due to driver error on my part. My .emacs sets fill-indent-according-to-mode to t, whereas by default it is nil. So to reproduce, follow my recipe and add M-: (setq fill-indent-according-to-mode t) RET after opening the org-mode buffer. Given that the default value of fill-indent-according-to-mode does /not/ cause a problem, maybe there's no reason to explicitly set it to nil in org-mode. I'll leave others to decide. Cheers, Lawrence ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Quote \[cmd] in docstring of org-export-with-LaTeX-fragments
* org-exp.el (org-export-with-LaTeX-fragments): Fix docstring so that \\[ a = b \\] is not interpreted as a keybinding by `substitute-command-keys'. In a docstring \\[text] is used to indicate that text should be interpreted by `substitute-command-keys'. To avoid this interpretation, we need to prefix it with \\=. --- lisp/org-exp.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 7c814cd..9954227 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -475,8 +475,8 @@ This option can also be set with the +OPTIONS line, e.g. \TeX:nil\. Non-nil means process LaTeX math fragments for HTML display. When set, the exporter will find and process LaTeX environments if the \\begin line is the first non-white thing on a line. It will also find -and process the math delimiters like $a=b$ and \\( a=b \\) for inline math, -$$a=b$$ and \\[ a=b \\] for display math. +and process the math delimiters like $a=b$ and \\( a=b \\) for inline math, +$$a=b$$ and \\=\\[ a=b \\] for display math. This option can also be set with the +OPTIONS line, e.g. \LaTeX:mathjax\. -- 1.7.4.rc1.7.g2cf08 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH 1/2] Only match complete words in org-export-add-options-to-plist
* org-exp.el (org-export-add-options-to-plist): Require match to start at a word-boundary. Previously, if an option was the suffix of another option (such as TeX and LaTeX) the setting for the former would propagator to the latter. This seems like an unintended consequence of a lax regexp in org-export-add-options-to-plist. This patch allows options to share a suffix with another option by requiring that the match against an option starts at a word-boundary. --- lisp/org-exp.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 9954227..d099c82 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -824,7 +824,7 @@ security risks. (let ((op org-export-plist-vars)) (while (setq o (pop op)) (if (and (nth 1 o) - (string-match (concat (regexp-quote (nth 1 o)) + (string-match (concat \\ (regexp-quote (nth 1 o)) :\\([^ \t\n\r;,.]*\\)) options)) (setq p (plist-put p (car o) -- 1.7.4.rc1.7.g2cf08 ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH 0/2] References auto-generated labels with \ref in LaTeX export
when writing latex, I prefer referring to previous sections by
saying As we saw earlier in section \ref{some-section}. When
writing with Org and then exporting to latex, there doesn't
appear to be any way to reproduce this. Using As we saw earlier
in section [[section header]] produces a hyperref, rather than a
plain ref.
This patch set introduces a new option
`org-latex-unprettify-internal-links' which, if non-nil, converts
bare references to auto-generated section labels into a \ref
rather than a \hyperref.
The first patch fixes up treatment of the options plist, so that
options that are the suffix of another option do not
inadvertantly match both. This should probably be applied either
way, since the current behaviour seems like a bug.
The second patch introduces the new functionality and attempts to
document it in the most obvious place I could find in the manual.
Cheers,
Lawrence
Lawrence Mitchell (2):
Only match complete words in org-export-add-options-to-plist
Allow option of using bare \ref links in LaTeX export
doc/org.texi | 37 +
lisp/org-exp.el |6 --
lisp/org-latex.el | 25 +
3 files changed, 62 insertions(+), 6 deletions(-)
--
1.7.4.rc1.7.g2cf08
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: evaluating all R code blocks (newbie question)
Julian Burgos wrote: Dear list, Hopefully this is not too basic, nor has been answered before. I would like to know if there is away to have alll R code blocks in a document evaluated automatically (i.e. without query) when exporting to Latex. Now I have to answer yes multiple times to the question Evaluate this R code block in your system every time I do an export, which is somewhat annoying. See the variable `org-confirm-babel-evaluate'. Be careful about unilaterally setting it to nil in case you receive org files with code blocks from people you don't trust. Cheers, Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: evaluating all R code blocks (newbie question)
Julian Burgos wrote: Many thanks Lawrence. Yes, I'm aware of the risks, but for now I am only working with my own files. Do you know if it is possible to evaluation confirmation as a header option, so I can left it on but turn it off in my own files? I don't believe it is. If you think about, this is also a security hole, since a malicious user could put the relevant header in, even if you've set org-confirm-babel-evaluate to t. Cheers, Lawrence ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Allow inclusion of author's email in LaTeX export
* org-latex.el (org-export-latex-make-header): Export email in
author line if `org-export-email-info' is non-nil.
Previously exporting to LaTeX would not include the document author's
email address when org-export-email-info was set. This patch corrects
this oversight using the \thanks command to add a footnote to the
author line.
---
lisp/org-latex.el | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 8a9f9eb..4b36273 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1276,7 +1276,9 @@ TITLE is the current title from the buffer or region.
OPT-PLIST is the options plist for current buffer.
(let ((toc (plist-get opt-plist :table-of-contents))
(author (org-export-apply-macros-in-string
-(plist-get opt-plist :author
+(plist-get opt-plist :author)))
+ (email (org-export-apply-macros-in-string
+ (plist-get opt-plist :email
(concat
(if (plist-get opt-plist :time-stamp-file)
(format-time-string %% Created %Y-%m-%d %a %H:%M\n))
@@ -1300,8 +1302,12 @@ OPT-PLIST is the options plist for current buffer.
(org-export-latex-fontify-headline title))
;; insert author info
(if (plist-get opt-plist :author-info)
-(format \\author{%s}\n
-(org-export-latex-fontify-headline (or author user-full-name)))
+(format \\author{%s%s}\n
+(org-export-latex-fontify-headline (or author user-full-name))
+(if (and org-export-email-info email
+ (string-match \\S- email))
+(format \\thanks{%s} email)
+ ))
(format %%\\author{%s}\n
(org-export-latex-fontify-headline (or author user-full-name
;; insert the date
--
1.7.4.rc1.7.g2cf08
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Inconsistencies in email and author export
The decision for when to add email and author information to an exported document seems to be treated somewhat inconsistently between export backends. The intent appears to be that the global default for exporting the author's name is controlled by org-export-author-info, and the email by org-export-email-info. These can be overriden by options in the file of the form author:value and email:value respectively. To check whether a backend should export the relevant info it appears one should use: (if (plist-get opt-plist :author-info) ;; we can export author info now ) And similarly for email export. This obeys the file-local setting first and foremost and then falls back on the default value if no local setting is in effect. However, most backends do not seem to stick to this. For example org-docbook.el exports the author info unilaterally and the email info if org-export-email-info is non-nil. org-ascii.el exports the author info if org-export-author-info is non-nil and email if both org-export-author-info and org-export-email-info are non-nil. org-latex.el exports the author info if :author-info is non-nil in the options plist, and doesn't export the email info at all (see my recent patch fixing this). org-html.el uses org-export-author-info and org-export-email-info. It seems then that most backends do not pay attention to file-local settings, which does feel like a bug. Any thoughts? Cheers, Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: [PATCH 3/3] org-agenda: allow %() in prefix format
Julien Danjou wrote: + %(expression) Eval expression and replaces the control string +by the result Nitpick, use replace, not replaces. [...] Cheers, Lawrence -- Lawrence Mitchell we...@gmx.li ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] [PATCH] Quote any special characters in org-make-target-link-regexp
* lisp/org.el (org-make-target-link-regexp): regexp-quote target before replacing whitespace. Previously a radio link ... would match all three-letter words in the buffer. The manual indicates the radio links are meant to match literally (modulo whitespace differences), so we should regexp-quote all the targets to avoid over-eager matching. --- This problem bit me when writing up some notes on CUDA, which uses ... to indicate a function call from a CPU onto a GPU. I think this is the right fix, since I can't imagine a situation where you would want foo.bar to match foo.bar, rather than foo\\.bar. lisp/org.el |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 6d1062c..5733d67 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5424,6 +5424,7 @@ between words. ( (mapconcat (lambda (x) + (setq x (regexp-quote x)) (while (string-match + x) (setq x (replace-match \\s-+ t t x))) x) -- 1.7.3.3.398.g0b0cd ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
