Re: [O] [babel] cannot comment out noweb references
I get this: Debugger entered--Lisp error: (wrong-type-argument char-or-string-p nil) org-babel-expand-noweb-references(nil) org-babel-expand-noweb-references(("sh" "echo <>" ((:comments . "") (:shebang . "") (:cache . "no") (:padline . "") (:noweb . "yes") (:tangle . "no") (:exports . "code") (:results . "replace output") (:session . "none") (:hlines . "no") (:result-type . output) (:result-params "output" "replace") (:rowname-names) (:colname-names)) "" nil 0 #)) org-babel-execute-src-block(nil) org-babel-execute-src-block-maybe() org-babel-execute-maybe() org-babel-execute-safely-maybe() run-hook-with-args-until-success(org-babel-execute-safely-maybe) org-ctrl-c-ctrl-c(nil) call-interactively(org-ctrl-c-ctrl-c nil nil) On 2/5/14, Eric Schulte wrote: > When executing the last code block I get the expected output, namely > "a". > > #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever > a > #+END_SRC > > # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever > # b > # #+END_SRC > > #+BEGIN_SRC sh :results output :noweb yes > echo <> > #+END_SRC > > #+RESULTS: > : a > > Best, > > -- > Eric Schulte > https://cs.unm.edu/~eschulte > PGP: 0x614CA05D > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
[O] Feature request: filling of long captions
Hi all, a currently active thread about filling (http://permalink.gmane.org/gmane.emacs.orgmode/77700) reminded me of a long standing wish of mine: Filling of captions. Would it be possible to have filling of captions? Ideally that would mean at least two things: auto-fill and M-q working on long captions. Example: --8<---cut here---start->8--- #+name: test #+begin_src R :results graphics :file tettr.png plot(1:10, 1:10) #+end_src #+results: test [[file:tettr.png]] #+caption: A very long long long long long long long long long long long long long long long long long long long long long long long long long long caption. [[file:tettr.png]] It would be very convenient if that could be automatically broken to #+caption: A very long long long long long long long long long long long long long long #+caption: long long long long long long long long long long long long caption. [[file:tettr.png]] --8<---cut here---end--->8--- Regards, Andreas
Re: [O] Auto-refreshing rendered images from org-babel
Thanks. I've changed it to the version below, which covers my needs. I think it would make sense as a (default?) feature for ob-dot, ob-ditaa, and any other babel language that renders images. Evgeni ;; Must be defined in a lexical environment (defun es-org-babel-refresh-images-after-execution () (let (refresh-and-remove-self) (setq refresh-and-remove-self (lambda () (org-redisplay-inline-images) (remove-hook 'org-babel-after-execute-hook refresh-and-remove-self))) (add-hook 'org-babel-after-execute-hook refresh-and-remove-self))) (defadvice org-babel-execute:dot (after refresh-images activate) (es-org-babel-refresh-images-after-execution)) Bastien writes: > E Sabof writes: > >> I have the org snippet below. What I would like, is to see the >> rendered image when I press C-c C-c. I can achieve this with the elisp >> snippet below. Is there a "proper", or at least a better way of doing >> this? > > Not tested but should work: > > (add-hook 'org-babel-after-execute-hook 'org-redisplay-inline-images) > > HTH,
[O] Bug: shift-enter in org tables leaves cursor in wrong position [8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/)]
Hi, when using the Shift- feature in a table to copy values down, it fails to place the cursor where you expect it to if the previous column has a fixed width and the contents of the cell is truncated. Steps to reproduce: enter the following org table: | | <7> | | |---+-+---| | 4 | podsdfsfsadastatoes | 1 | | 5 | podsdfsfsadastatoes | 2 | | 6 | | | press C-c C-c to ensure the second column is showing abbreviated. place cursor on the number 1, Shift- copies values to the next line but leaves the cursor in the wrong position, at the end of the string in the row that starts with 5 if you remove the <7> and repeat the experiment, the cursor moves down the third column as you expect it to. I expect it should work the same whether or not the previous column has truncated contents. Emacs : GNU Emacs 24.3.50.2 (i686-pc-cygwin) of 2014-01-15 on jade Package: Org-mode version 8.2.5h (8.2.5h-6-g8e1386-elpa @ /cygdrive/c/Users/jason/.emacs.d/elpa/org-20140203/) current state: == (setq org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-latex-format-headline-function 'org-latex-format-headline-default-function org-html-format-inlinetask-function 'ignore outline-minor-mode-hook '(mediawiki-outline-magic-keys) org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe org-babel-header-arg-expand) org-refile-targets '((nil :maxlevel . 9) (org-agenda-files :maxlevel . 9)) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-hide-inline-tasks org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default org-babel-pre-tangle-hook '(save-buffer) org-occur-hook '(org-first-headline-recenter) org-html-format-headline-function 'ignore org-metaup-hook '(org-babel-load-in-session-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-default-notes-file "~/Dropbox/org/todo.org" org-latex-format-drawer-function '(lambda (name contents) contents) org-blank-before-new-entry nil org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-mode-hook '(#[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-show-block-all append local] 5] #[nil "\300\301\302\303\304$\207" [org-add-hook change-major-mode-hook org-babel-show-result-all append local] 5] org-babel-result-hide-spec org-babel-hide-all-hashes (lambda nil (flyspell-mode -1))) org-ascii-format-drawer-function '(lambda (name contents width) contents) org-directory "~/Dropbox/org" org-from-is-user-regexp "\\" org-html-format-drawer-function '(lambda (name contents) contents) org-metadown-hook '(org-babel-pop-to-session-maybe) org-agenda-files '("~/Dropbox/org/todo.org" "~/Dropbox/org" "~/Dropbox/org/todo.org") org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-after-todo-state-change-hook '(org-clock-out-if-current) org-latex-format-inlinetask-function 'ignore org-M-RET-may-split-line '((default)) org-confirm-shell-link-function 'yes-or-no-p ) signature.asc Description: OpenPGP digital signature
[O] semantic-mode is conflict with org-mode
semantic-mode uses `C-c ,' as a prefix for several commands. org-mode uses `C-c ,' for org-priority. I don't use semantic-mode within org-mode. Is there a way to disable semantic-mode just in org-mode buffers in Emacs? If so, can someone include in in [[info:org#Conflicts]]? (I'm using Org 8.2.5c on Emacs 24.3.50.) -- http://www.gnu.org/software/emacs/
[O] How to get effort summary in clocktable in agenda?
Hi, i've got an agenda report that includes a clocktable that looks like this: | File | Effort | ALLTAGS | Headline | Time | |--++-+--+| | | ALL| | *Total time* | *8:24* | |--++-+--+| | Work-log.org || | *File time* | *8:24* | | || :514: | PPTDEV-514 Miscellaneous | 1:06 | | || :514: | \__ W06 email, morning | 1:06 | | || :513: | PPTDEV-513 smt 2014 Meetings | 0:17 | | || :513: | \__ Standup | 0:17 | | || | PPTDEV-318 HVE Industry - Feed runner... | 4:47 | | | 0:15 | | \__ SPEC redo spec with RDE | 1:39 | | || | \__ TODO Modify... | 3:08 | | || :389: | JWRK PPTDEV-389 VBA macros | 2:14 | | || :389: | \__ Notes | 2:14 | What I'd really love to have is a column that shows the summarized Effort estimate for the top level headings. IE PPTDEV-318-HVE Industry has a time summary of 4:47 for the day, but only shows the the effort estimate for the individual subtasks that are displayed. If I increase the task level I can see more of the underlying structure, but not a summary. Is there a variable I'm missing here to set up my column as a summary? While I'm at it, is there an easy way to include a calculated column in the clock table (either in the agenda or one generated in my org file) that would show Effort - time for a given headline? Thanks! Subhan -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
Re: [O] [babel] shell does not unquote
Use org-babel-expand-block (C-c C-v v) to view the code block with the variable expansion. Best, Samuel Wales writes: > i don't know why the shell does not unquote here: > > #+BEGIN_SRC sh :results verbatim output :var how="a 'b' \c \"d\" e" > :var dothis="echo \"hi\"" > echo $how > $dothis > #+END_SRC > > #+RESULTS: > #+begin_example > a 'b' c "d" e > "hi" > #+end_example > > thanks. > > samuel -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [babel] cannot comment out noweb references
Samuel Wales writes: > hi eric, > > #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever > a > #+END_SRC > # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever > # b > # #+END_SRC > #+BEGIN_SRC sh :results output :noweb yes > echo <> > #+END_SRC > > it is a bug that babel tries to use b. > > babel tries to use COMMENT comments also. > > samuel When executing the last code block I get the expected output, namely "a". #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever a #+END_SRC # #+BEGIN_SRC org :results verbatim output :noweb yes :noweb-ref whatever # b # #+END_SRC #+BEGIN_SRC sh :results output :noweb yes echo <> #+END_SRC #+RESULTS: : a Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Moving by block in the block agenda
Thanks! Works wonderland wonderfully. Kind regards Bart Bastien writes: > Hi Bart, > > "Bart Bunting" writes: > >> I have a block agenda defined which is mostly taken from Bernt Hansen's >> org-mode.org. >> >> Some of the blocks contain many entries. I am trying to find out if >> there is a simple way to navigate between agenda blocks. >> >> The most likely thing I found was org-agenda-goto-block-beginning but it >> doesn't appear to do that. >> >> What am I missing? > > Nothing -- I just pushed a change in master which remap > `backward-paragraph' and `forward-paragraph' to the new commands > `org-agenda-backward-block' and `org-agenda-forward-block'. > > Let me know if it does what you want and thanks for raising this. > > Thanks, > > -- > Bastien Bart -- Kind regards Bart
Re: [O] bug: "Please save the buffer to a file before refiling" when the buffer is already saved"
Samuel Wales writes: > one thing i don't understand is why there need to be 2 olpaths for the > identical location. Well, this is the part of the bug that I never managed to reproduce. If you have time for a recipe that produces just this bug, let's go. I wish someone else could report the same bug too -- that'd give us another perspective, and more food for thought. Anyway, I hope we can fix this soon. -- Bastien
Re: [O] Auto-refreshing rendered images from org-babel
E Sabof writes: > I have the org snippet below. What I would like, is to see the > rendered image when I press C-c C-c. I can achieve this with the elisp > snippet below. Is there a "proper", or at least a better way of doing > this? Not tested but should work: (add-hook 'org-babel-after-execute-hook 'org-redisplay-inline-images) HTH, -- Bastien
Re: [O] org-map-entries moves point
Hi Florian, Florian Beck writes: > Missed that. But this reverts commit > 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) > > I was talking about > fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to > org-agenda-prepare-buffer) > > In fact, the revert *caused* my bug. Again, the recipe: > > The bug doesn't really move the point, rather it recenters the current > line. To see it, move into the middle of a document, unfold a second > level headline and in the middle of the window execute > > (org-map-entries (lambda () >;; do something or even nothing >) nil 'tree) > > This works correctly if either commit [1] is restored or [2] is > reverted. I partially revert [2] (only replacing `save-window-excursion' by `save-excursion') and didn't touch [1] -- if we can produce a bug from there, let's fix it the right way this time. Thanks in advance for digging further, -- Bastien
Re: [O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Hello Nick, Thanks for your quick reply. The variable org-edit-src-content-indentation does indeed have to do with the indentation I was referring to. But it is relative. According to the documentation, it sets the "Indentation for the content of a source code block. This should be the number of spaces added to the indentation of the #+begin line in order to compute the indentation of the block content after editing it with M-x org-edit-src-code. Has no effect if `org-src-preserve-indentation' is non-nil." I wonder if one can set it to be zero as an absolute value, meaning that if the a line of code in the source block starts at column n of the buffer, it is left at column n after M-q. Regarding the behavior you observe, as I said I get that too from time to time. In fact, doing M-q on my own example in a fresh Org mode buffer, I now get what you get: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, "Hello, World!" end program main #+END_SRC I don't have any special settings for the f90 mode in my .emacs. In fact, I have observed the same behavior for other languages too when edited in an Org source block. The "destructive" nature of this behavior is very special (C-/ (undo) doesn't work). Many a times, I have tried refilling a line of comments and ended up with a huge mix of code and comment that was impossible to undo (at least to the best of my knowledge) and I had to either revert the change if I had the file under version control, go to an auto backup file, or painfully and manually separate the code and comments to get back the original code block. Omid On 02/05/2014 04:34 PM, Nick Dokos wrote: > Omid writes: > >> Hello, >> >> I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. >> I have two questions about the behavior of the fantastic Org >> mode+Babel with respect to code and comments: >> >> Here is a minimal example: >> >> #+BEGIN_SRC f90 :results verbatim :exports both >> program main >> ! This is a very very very very very very very very very very very very >> very very very very long comment line. >> print *, "Hello, World!" >> end program main >> #+END_SRC >> >> Below is the code snippet after M-q (fill-paragraph) on the comment >> line. The comment line has been refilled (intended behavior) but all >> lines have been indented. This may also be an intended behavior; but >> >> FIRST QUESTION: Is there a way to disable this indentation upon M-Q in >> Org Babel code snippets? >> > > Try setting org-edit-src-content-indentation to 0. I'm not sure that > it is going to work, but (based on rather flimsy numerological evidence, > namely that its default value is 2 as is the indent below) it might. > >> #+BEGIN_SRC f90 :results verbatim :exports both >> program main >> ! This is a very very very very very very very very very very very very >> ! very very very very long comment line. >> print *, "Hello, World!" >> end program main >> #+END_SRC >> > > BTW, I don't get this behavior but I don't use f90 mode, so I'm not sure > whether there is some setup I'm missing. I get (with > org-edit-src-content-indentation set to 0): > > #+BEGIN_SRC f90 :results verbatim :exports both > program main ! This is a very very very very very very very very very > very very very very very very very long comment line. print *, > "Hello, World!" end program main > #+END_SRC > > Nick > > >
Re: [O] org-map-entries moves point
Florian Beck writes: > On 05.02.2014 21:59, Nick Dokos wrote: > >> John Kitchin reported this last week and Bastien reverted that commit: >> >>http://thread.gmane.org/gmane.emacs.orgmode/81587 > > Missed that. But this reverts commit > 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) > > I was talking about > fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to > org-agenda-prepare-buffer) > > In fact, the revert *caused* my bug. Again, the recipe: > > The bug doesn't really move the point, rather it recenters the current > line. To see it, move into the middle of a document, unfold a second > level headline and in the middle of the window execute > > (org-map-entries (lambda () >;; do something or even nothing >) nil 'tree) > > This works correctly if either commit [1] is restored or [2] is reverted. > > Does all of [2] have to be reverted? Or can save-window-excursion be changed back to save-excursion? AFAICT, the rest of the fix is independent of that. -- Nick
Re: [O] org-map-entries moves point
On 05.02.2014 21:59, Nick Dokos wrote: John Kitchin reported this last week and Bastien reverted that commit: http://thread.gmane.org/gmane.emacs.orgmode/81587 Missed that. But this reverts commit 3ec38f5c064c3270f54876ba33c5ca1097b46853 [1] (in org-map-entries) I was talking about fe3379bda6ca23474639b114592958bf14431c88 [2] (which did the same to org-agenda-prepare-buffer) In fact, the revert *caused* my bug. Again, the recipe: The bug doesn't really move the point, rather it recenters the current line. To see it, move into the middle of a document, unfold a second level headline and in the middle of the window execute (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) This works correctly if either commit [1] is restored or [2] is reverted. But it's not clear *why* that commit was done in the first place so if you get some enlightenment from your experiments, please share. Will do. Nick -- Florian Beck
Re: [O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Omid writes: > Hello, > > I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. > I have two questions about the behavior of the fantastic Org > mode+Babel with respect to code and comments: > > Here is a minimal example: > > #+BEGIN_SRC f90 :results verbatim :exports both > program main > ! This is a very very very very very very very very very very very very > very very very very long comment line. > print *, "Hello, World!" > end program main > #+END_SRC > > Below is the code snippet after M-q (fill-paragraph) on the comment > line. The comment line has been refilled (intended behavior) but all > lines have been indented. This may also be an intended behavior; but > > FIRST QUESTION: Is there a way to disable this indentation upon M-Q in > Org Babel code snippets? > Try setting org-edit-src-content-indentation to 0. I'm not sure that it is going to work, but (based on rather flimsy numerological evidence, namely that its default value is 2 as is the indent below) it might. > #+BEGIN_SRC f90 :results verbatim :exports both > program main > ! This is a very very very very very very very very very very very very > ! very very very very long comment line. > print *, "Hello, World!" > end program main > #+END_SRC > BTW, I don't get this behavior but I don't use f90 mode, so I'm not sure whether there is some setup I'm missing. I get (with org-edit-src-content-indentation set to 0): #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, "Hello, World!" end program main #+END_SRC Nick
Re: [O] bug: "Please save the buffer to a file before refiling" when the buffer is already saved"
one thing i don't understand is why there need to be 2 olpaths for the identical location. in maint i get both in ido [when it is in same file]. i only need 1 [always]. the bugs aside, there is no reason to /have/ to choose one. right? so why are 2 included? On 1/29/14, Bastien wrote: > Hi Samuel, > > Samuel Wales writes: > >> i have very little capacity to do this properly, doing the best i can >> so you get timely feedback. perhaps this gives you a little to go on. >> if not, this will take much longer. > > Thanks -- I'll explore this using ido, which I do not use ordinarily. > > If other users want to chim in and test, that'd be great too, > especially for the bugfixes I explained in my previous email. > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] org-map-entries moves point
Florian Beck writes: > When I call org-map-entries with scope set to 'tree, the current > heading gets realigned to the top. > > Behold: > > (org-map-entries (lambda () > ;; do something or even nothing > ) nil 'tree) > > I think the culprit is the call to `org-agenda-prepare-buffers', or > rather commit fe3379bda6ca23474639b114592958bf14431c88, which replaces > save-excursion with save-window-excursion. > > What's interesting: This does NOT restore the window > configuration. When I replace save-window-excursion with > save-excursion the window configuration is restored again. > > I'm not sure *why* this happens. John Kitchin reported this last week and Bastien reverted that commit: http://thread.gmane.org/gmane.emacs.orgmode/81587 But it's not clear *why* that commit was done in the first place so if you get some enlightenment from your experiments, please share. Nick
Re: [O] [bug?] File contents of SETUPFILE's is read twice
Hi Bastien, Bastien wrote: > "Sebastien Vauban" writes: > >> It seems wrong to me that the SETUPFILE's are accessed twice. > > That's because setupfile is checked within > `org-macro-initialize-templates' and `org-set-regexps-and-options', > both called from org-mode. So, you mean that SETUPFILE *must* be read twice, right? I understand the first call. The second one (in `org-set-regexps-and-options') stays a bit cryptic to me, right now. Best regards, Seb -- Sebastien Vauban
Re: [O] Agenda views skip function hide parent projects
On Wed, Feb 5, 2014 at 2:40 PM, Alan Schmitt wrote: > > I highly recommend reading this: http://doc.norang.ca/org-mode.html > > Alan Thank you for the reply. I was hoping there was a function that did the opposite of '(org-tags-list-sublevels nil)'. But if not, I will have to do something similar to your suggestion. -Tim
[O] Behavior of Org mode Babel code snippets with respect to M-q (fill-paragraph) and C-/ (undo)
Hello, I am using Org-mode version 8.2.5g (8.2.5g-elpa) in GNU Emacs 24.3.1. I have two questions about the behavior of the fantastic Org mode+Babel with respect to code and comments: Here is a minimal example: #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very very very very very long comment line. print *, "Hello, World!" end program main #+END_SRC Below is the code snippet after M-q (fill-paragraph) on the comment line. The comment line has been refilled (intended behavior) but all lines have been indented. This may also be an intended behavior; but FIRST QUESTION: Is there a way to disable this indentation upon M-Q in Org Babel code snippets? #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very very very very long comment line. print *, "Hello, World!" end program main #+END_SRC Below is the code snippet after a C-/ (undo). Note that the indentation and the refill which were done by the last command above (M-q) are not being undone. The text in the comment is being removed which I believe means that the previous (self-insert-command)'s that created the text are being undone. This is very undesirable since even a user who is aware of this behavior may by mistake issue the command M-q, have the code snippet formatted in an undesirable way (e.g., sometimes new lines are not respected and code and comments get mixed up), without any immediate way to undo this reformatting. SECOND QUESTION: How can one get the usual (undo) behavior in a Babel code snippet? #+BEGIN_SRC f90 :results verbatim :exports both program main ! This is a very very very very very very very very very very very very ! very v comment line. print *, "Hello, World!" end program main #+END_SRC Please note that these edits are done in the Org mode buffer directly. If I switch to the native language mode using C-c ' things work as expected. Thanks, Omid
[O] org-map-entries moves point
When I call org-map-entries with scope set to 'tree, the current heading gets realigned to the top. Behold: (org-map-entries (lambda () ;; do something or even nothing ) nil 'tree) I think the culprit is the call to `org-agenda-prepare-buffers', or rather commit fe3379bda6ca23474639b114592958bf14431c88, which replaces save-excursion with save-window-excursion. What's interesting: This does NOT restore the window configuration. When I replace save-window-excursion with save-excursion the window configuration is restored again. I'm not sure *why* this happens. -- Florian Beck
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, Nicolas Goaziou wrote: > Bastien writes: >> "Fabrice Niessen" writes: >> >>> As the DOCSTRING of the function `org-macro--collect-macros' tells it, >>> it "collects macro definitions in current buffer and setup files", not >>> from INCLUDE files. >> >> Then your patch should change the docstring too. Right! >> I think we want to collect macros from setupfile only, >> that's one of the differences between INCLUDE and SETUPFILE. > > I agree. > > Not all "Include" files are Org files. OK, but that shouldn't be a problem either: if there is no #+MACRO in an "Include" file, that doesn't matter... > Moreover, "INCLUDE" keywords are expanded before initializing macro > templates during export, so "MACRO" keywords should be read when > appropriate. You say that the order of operations, during export, is: - Include files through "INCLUDE" keywords - Expand macros OK. Still, I don't understand what you mean by "so MACRO keywords should be read when appropriate"? Anyway, let me explain what I wish such a feature (_or_ the opposite: that Babel blocks are allowed in SETUPFILE)... I'm sharing on GitHub a project [1] where I write Org macros that everybody could once need, and these are easily accessible (once cloned) in every file, after a simple directive such as: #+INCLUDE: /path/to/org-macros.setup As I do have Babel code blocks inside the `org-macros.setup' file, it needs to be loaded via the "INCLUDE" directive, not via a "SETUPFILE". Example of such macro calling a Babel code block: ╭ │ #+name: version-history │ #+begin_src sh :exports none :results silent :colnames '(Version Date Author Comment) │ git log --pretty=format:"%h%x09%ad%x09%an%x09%s" --date=short | head -n 5 │ #+end_src │ │ #+MACRO: version-history call_version-history[:eval yes]()[:eval yes :results table :colnames '(Version Date Author Comment)] ╰ So, thanks to the INCLUDE directive, I already have a one-liner to include such "extended macros". But these aren't collected by `org-macro--collect-macros'... Best regards, Fabrice [1] https://github.com/fniessen/org-macros -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] Agenda views skip function hide parent projects
it would be interesting to do this with dimming ancestors instead of skipping them. how would you do that? it would also be interesting to dim descendants. there is the blocked task concept, but that is different. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. Denmark: free Karina Hansen NOW.
Re: [O] Agenda views skip function hide parent projects
Wiskey 5 Alpha writes: > Hello all. > > I am sure this is documented somewhere, but I cant seem to put together > the correct custom agenda view to support my way of project planning > > I have the following todo keywords defined : TODO NEXT DONE WAIT > I like to list everything as a TODO, even if sub items may be a TODO, > like this > > ** TODO Main Test Project > *** TODO Main sub project 1 > NEXT first task > *** TODO Main sub project 2 (stuck) > > What I would like to see is : > on my projects list > TODO Main sub project 1 > > The problem is that my project list looks like this > TODO Main Test Project > TODO Main sub project 1 > > I have some projects that are 4 levels deep, so this is quite annoying. > How do > I get just the "deepest" level project to show without it's parents ? I highly recommend reading this: http://doc.norang.ca/org-mode.html In particular, if you read this section http://doc.norang.ca/org-mode.html#Projects you will find functions that tell you if something is a project (i.e., is a task with a subtask). I guess one could write something like this: #+begin_src emacs-lisp (defun bh/has-subproject-p () "Any task with a todo keyword subtask that is a project" (save-restriction (widen) (let ((has-subproject) (subtree-end (save-excursion (org-end-of-subtree t))) (is-a-task (member (nth 2 (org-heading-components)) org-todo-keywords-1))) (save-excursion (forward-line 1) (while (and (not has-subproject) (< (point) subtree-end) (re-search-forward "^\*+ " subtree-end t)) (when (bh/is-project-p) (setq has-subproject t (and is-a-task has-subtask #end_src then combine "is-project-p" and "has-subproject-p" to decide whether to include something. Alan
[O] Agenda views skip function hide parent projects
Hello all. I am sure this is documented somewhere, but I cant seem to put together the correct custom agenda view to support my way of project planning I have the following todo keywords defined : TODO NEXT DONE WAIT I like to list everything as a TODO, even if sub items may be a TODO, like this ** TODO Main Test Project *** TODO Main sub project 1 NEXT first task *** TODO Main sub project 2 (stuck) What I would like to see is : on my projects list TODO Main sub project 1 The problem is that my project list looks like this TODO Main Test Project TODO Main sub project 1 I have some projects that are 4 levels deep, so this is quite annoying. How do I get just the "deepest" level project to show without it's parents ? here is my custom agenda view for projects ("p" "@Projects" tags-todo "-IGNORE-someday-wait/TODO" ( (org-agenda-overriding-header "@Projects") (org-agenda-tags-todo-honor-ignore-options t) (org-agenda-skip-function (lambda nil (org-agenda-skip-subtree-if (quote notregexp) "\\* NEXT") ) ) Thank you in advance -Tim
[O] Auto-refreshing rendered images from org-babel
I have the org snippet below. What I would like, is to see the rendered image when I press C-c C-c. I can achieve this with the elisp snippet below. Is there a "proper", or at least a better way of doing this? Evgeni #+BEGIN_SRC dot :file files/graphviz/example1.png digraph test { size="6,5"; home [label = "Home"]; prod [label = "Products"]; news [label = "News"]; cont [label = "Contact"]; home -> {prod news cont} } #+END_SRC (org-babel-do-load-languages 'org-babel-load-languages '((dot . t) )) (defadvice org-babel-execute:dot (after refresh-images activate) (run-with-timer 1 nil 'org-display-inline-images))
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, Bastien writes: > "Fabrice Niessen" > writes: > >> As the DOCSTRING of the function `org-macro--collect-macros' tells it, >> it "collects macro definitions in current buffer and setup files", not >> from INCLUDE files. > > Then your patch should change the docstring too. > > I think we want to collect macros from setupfile only, > that's one of the differences between INCLUDE and SETUPFILE. I agree. Not all "Include" files are Org files. Moreover, "INCLUDE" keywords are expanded before initializing macro templates during export, so "MACRO" keywords should be read when appropriate. Regards, -- Nicolas Goaziou
Re: [O] any way how to look on what was done on particular day?
Thanks to all, yes, 'v L' is the stuff I'm looking for Eric S Fraga writes: > Have you tried "v l" or "v L" from within the agenda view on the > particular day? It should show some of the activities you want. > -- > : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.5h-585-g5f0ca0
[O] time tracking math is confusing
I hope there a general rule I'm missing or something I'm doing wrong, because I find the time tracking math in Org confusing. It seems that numbers I enter (ex: 8:00, 5d) are in units of 8-hour days. But math that Org does is in units of 24 hour days. So If I have * Task :PROPERTIES: :ID: test-task :END: ** SubTask 1 :PROPERTIES: :Effort: 5d :END: ** SubTask 2 :PROPERTIES: :Effort: 8:00 :END: Then the total work is 6 days (8 hour units, 48 hours) or 2d (24 hour units, 48 hours). This makes sense to me so far. When I make a time tracking table (i'm not sure of the function name, but C-c C-x i and then enter "test-task" at the prompt, I see the following table: #+BEGIN: <> | Task | Effort | |--+-+ | * Task | 2d 0:00 | | ** SubTask 1 | 5d | | ** SubTask 2 |8:00 | #+END: This is confusing because the units (24 hour, 8 hour) are mixed. The top row entry, "2d", is 24 hour units, but immedediately below it, the "5d" entry is in 8 hour units, as is the 8:00 effort below that. I can work in either unit, but mixing is confusing. It seems human-entered times and estimates are 8 hour, and Org-calculated is 24 hour. Is this always correct? The issue then is that there is no clear indicator of what is human and what is Org on this table. -k.
Re: [O] Behavior of M-q on comments in code blocks
"Sebastien Vauban" writes: > Though, when doing it on the first line (comment), we don't have the > same behavior whether the `M-q' is done on the code block itself (in the > Org file) or in the indirect buffer: while the first fails, the latter > does work as expected. See http://screencast.com/t/iwE7xbxKj. I've seen this but I've no time for this right now and the fix in Emacs will also fix this -- feel free to explore, of course! -- Bastien
Re: [O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
"Fabrice Niessen" writes: > As the DOCSTRING of the function `org-macro--collect-macros' tells it, > it "collects macro definitions in current buffer and setup files", not > from INCLUDE files. Then your patch should change the docstring too. I think we want to collect macros from setupfile only, that's one of the differences between INCLUDE and SETUPFILE. But I'll let Nicolas review and decide. -- Bastien
[O] [PATCH] `org-macro--collect-macros' can collect macro definitions from include files
Hello, As the DOCSTRING of the function `org-macro--collect-macros' tells it, it "collects macro definitions in current buffer and setup files", not from INCLUDE files. This patch ensures that the above does work. >From a8737be0b12ce700cd348c47f91694bfc0fbe7b8 Mon Sep 17 00:00:00 2001 From: "Fabrice Niessen" Date: Wed, 5 Feb 2014 16:59:58 +0100 Subject: [PATCH] Collect macro definitions from INCLUDE files as well * org-macro.el (org-macro--collect-macros): INCLUDE files are looked up when searching for macro definitions. --- lisp/org-macro.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org-macro.el b/lisp/org-macro.el index 50ce438..7f438ed 100644 --- a/lisp/org-macro.el +++ b/lisp/org-macro.el @@ -78,7 +78,7 @@ Return an alist containing all macro templates found." (org-with-wide-buffer (goto-char (point-min)) (while (re-search-forward - "^[ \t]*#\\+\\(MACRO\\|SETUPFILE\\):" nil t) + "^[ \t]*#\\+\\(MACRO\\|SETUPFILE\\|INCLUDE\\):" nil t) (let ((element (org-element-at-point))) (when (eq (org-element-type element) 'keyword) (let ((val (org-element-property :value element))) -- Fabrice Niessen Leuven, Belgium http://www.pirilampo.org/
Re: [O] Behavior of M-q on comments in code blocks
Bastien wrote: > "Sebastien Vauban" writes: > >> I just type M-q on the comment line and the lines are completely mixed >> up: > > Actually M-q in shell-mode on the "echo ..." line will produce the > problem. So I think you should first report this as an Emacs bug. True for `M-q' on the second line (echo line) -- did know about that. I'll report it. Though, when doing it on the first line (comment), we don't have the same behavior whether the `M-q' is done on the code block itself (in the Org file) or in the indirect buffer: while the first fails, the latter does work as expected. See http://screencast.com/t/iwE7xbxKj. Best regards, Seb -- Sebastien Vauban
Re: [O] [bug?] File contents of SETUPFILE's is read twice
Hi Sébastien, "Sebastien Vauban" writes: > It seems wrong to me that the SETUPFILE's are accessed twice. That's because setupfile is checked within `org-macro-initialize-templates' and `org-set-regexps-and-options', both called from org-mode. -- Bastien
Re: [O] Behavior of M-q on comments in code blocks
"Sebastien Vauban" writes: > I just type M-q on the comment line and the lines are completely mixed > up: Actually M-q in shell-mode on the "echo ..." line will produce the problem. So I think you should first report this as an Emacs bug. -- Bastien
[O] [bug?] File contents of SETUPFILE's is read twice
Hello, It seems wrong to me that the SETUPFILE's are accessed twice. Here is the proof... Org file (containing a reference to a non-existing setup file): --8<---cut here---start->8--- #+SETUPFILE: ~/missing-file.setup * Test Blah... --8<---cut here---end--->8--- Minimal Emacs configuration file: --8<---cut here---start->8--- ;; Org mode (add-to-list 'load-path "~/Public/Repositories/org-mode/lisp") (find-file "~/test.org") --8<---cut here---end--->8--- Resulting *Messages* buffer: --8<---cut here---start->8--- For information about GNU Emacs and the GNU system, type C-h C-a. Cannot read file "d:/Users/fni/missing-file.setup" [2 times] --8<---cut here---end--->8--- WDYT? (this could have a performance impact, even if marginal?) Best regards, Seb -- Sebastien Vauban
Re: [O] Quotes for LaTeX export
Laurens Van Houtven <_...@lvh.io> writes: > On Wed, Feb 5, 2014 at 2:37 PM, Nicolas Goaziou wrote: > >> We already have a working solution for many languages, and more general >> that this LaTeX-centered command. It has limitations, but "csquotes" >> support would inherit them anyway since it would be built on top of >> smart quotes mechanism. >> > > This is only for LaTeX-export, so I don't see how LaTeX-centered is > relevant. I really don't see how it affects other export langs; The current quote mechanism is built at the export framework level so that each export back-end doesn't need to bring up its own recipe. I'd rather not add back-end specific code unless it is an improvement. So far, I don't see the improvement. Do you have an example of an Org document that produces a wrong tex file, which would be correct if it used "csquotes"? > plus, it was in the old LaTeX exporter anyway! True. And? I gave you a solution to use "csquotes" feature in your documents. > The reason is that the exporter occasionally produces TeX code that renders > poorly on some setups (we're still figuring out which those are exactly). > csquotes never does this. I assume it will render poorly in setups that do not use that package. I'm surprised that "csquotes" is compulsory in some setups. Of course, it would be good to know about them so we can find a workaround. Regards, -- Nicolas Goaziou
Re: [O] Quotes for LaTeX export
Hi Rasmus, On Wed, Feb 5, 2014 at 2:44 PM, Rasmus wrote: > >> Org already has semantic quote characters, namely '"' and "'". > > > > Right: I'm talking about TeX and not org-mode there. The semantic way to > > say "this is quoted" is csquotes and \enquote. > > But this is the Org-ML. I assume you're interested in using Org for > producing your tex files? > Yes, that is the only thing I am doing. I am trying to get org's idea of semantic quoting to map to LaTeX's idea of semantic quoting. As a result I also don't understand why anyone cares what the \enquote{whatever} looks like in the TeX file. Personally I only care what it looks like in Org. This is also why I think the macro solution is bad. Org has semantic quotes. It's just not doing a good job of convincing my LaTeX stack that it has semantic quotes. > I was not able to produce non-working files via Org either. . . But I > didn't test from emacs -q. The exported TeX source appears to be functionally equivalent to the snippet you pasted, so the issue is probably in the TeX step. thanks again, lvh
Re: [O] Behavior of M-q on comments in code blocks
Hi Thorsten and Bastien, Bastien wrote: > "Sebastien Vauban" writes: > >> Though, I can't say whether the fact it does not work anymore is due to >> changes in Org or in my Emacs configuration. Any hint? > > Works fine here, surely something in your configuration. Here is a reproducible recipe... Can you please try it, and confirm me you see the same things as I do? Org file: --8<---cut here---start->8--- * Test The comment in the code block is not correctly refilled (on M-q). #+begin_src sh # display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) echo Some text #+end_src --8<---cut here---end--->8--- Minimal Emacs configuration file: --8<---cut here---start->8--- ;; Org mode (add-to-list 'load-path "~/Public/Repositories/org-mode/lisp") (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (sh . t))) (find-file "~/test.org") (message "Loading Minimal Emacs... Done") --8<---cut here---end--->8--- See the demo at http://screencast.com/t/fA0hIhnCQgbr. I just type M-q on the comment line and the lines are completely mixed up: --8<---cut here---start->8--- #+begin_src sh # display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) echo Some text #+end_src --8<---cut here---end--->8--- Best regards, Seb -- Sebastien Vauban
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 2:37 PM, Nicolas Goaziou wrote: > We already have a working solution for many languages, and more general > that this LaTeX-centered command. It has limitations, but "csquotes" > support would inherit them anyway since it would be built on top of > smart quotes mechanism. > This is only for LaTeX-export, so I don't see how LaTeX-centered is relevant. I really don't see how it affects other export langs; plus, it was in the old LaTeX exporter anyway! The reason is that the exporter occasionally produces TeX code that renders poorly on some setups (we're still figuring out which those are exactly). csquotes never does this. lvh
Re: [O] [bug] "_ID" in "CUSTOM_ID" being fontified as `org-latex-and-related'
Hello, Bastien writes: > I don't know if Nicolas will have time to dive into this and > fix `org-match-substring-regexp' (if that's the thing to do.) > I'd rather not fiddle with this part of the code myself. The only right way to fix is to use the parser for fontification. This is on my TODO list, but I first need to improve parser cache (hopefully before 8.3). IMO, we can live with this (and some others) fontification artifact until then. Regards, -- Nicolas Goaziou
Re: [O] Quotes for LaTeX export
Hi Laurens, Laurens Van Houtven <_...@lvh.io> writes: > On Wed, Feb 5, 2014 at 1:12 PM, Rasmus wrote: > >> This is exactly the reasons why I don't want to use csquotes: >> >> \enquote{something}. >> > > I'm not sure I understand. Are you suggesting the syntax is bad? I'm suggesting it makes adds noise that makes the source even harder to read than it is. With Emacs you could of course make it look pretty again. . . >> But check for instance org-latex-tables-booktabs, which makes optional >> support for booktabs. That kind of support for csquote is of course >> OK. One reason I'd not use this is that the quotes exported to HTML >> and LaTeX are no longer in sync. Which is why I'd rather see >> customization through a user smart quote alist. >> > Okay, that's a fair argument. It would require consistent configuration in > more than one place, unless (I think?) Org's LaTeX export automagically > use/configure Babel. To use Babel add ("AUTO" "babel" nil) to org-latex-packages-alist or -default-package-alist. AUTO is replaced with the correct language. >> Org already has semantic quote characters, namely '"' and "'". > > Right: I'm talking about TeX and not org-mode there. The semantic way to > say "this is quoted" is csquotes and \enquote. But this is the Org-ML. I assume you're interested in using Org for producing your tex files? > Are those code points U+0022 QUOTATION MARK and U+0027 APOSTROPHE? (I am > not an org-mode expert. I'm assuming org-mode does operate on code points, > not bytes?). On my computer I produce the quotation with S-2. On most layouts these are the most straightforward quoting characters. If you use smartquotes they are exported according to your language. >>\documentclass{article} >>\usepackage{fontspec} >>\addfontfeatures{Mapping=} >>\addfontfeatures{Ligatures=} >>\begin{document} >>``test'' >>\end{document} >> >> Could you share a snip that reproduces your problem? > That appears to compile correctly on my machine as well. Perhaps there is a > discrepancy between how I'm building the tex file and how org is building > the intermediary tex file. I will investigate :) I was not able to produce non-working files via Org either. . . But I didn't test from emacs -q. –Rasmus -- C is for Cookie
Re: [O] [bug] "_ID" in "CUSTOM_ID" being fontified as `org-latex-and-related'
"Sebastien Vauban" writes: > ;; highlight LaTeX and related syntax > (setq org-highlight-latex-and-related '(latex script entities)) Thanks. I see the bug (I'd say it's a minor annoyance, though). I don't know if Nicolas will have time to dive into this and fix `org-match-substring-regexp' (if that's the thing to do.) I'd rather not fiddle with this part of the code myself. -- Bastien
Re: [O] Quotes for LaTeX export
Hello, Laurens Van Houtven <_...@lvh.io> writes: > On Wed, Feb 5, 2014 at 8:46 AM, Bastien wrote: > >> Nick Dokos writes: >> >> > IIRC, there was support for csquotes in the old exporter[fn:1] but I >> guess >> > it went away when the new exporter came along. >> >> Yes, it'd be good to make it possible again to use >> \usepackage{csquotes} and \enquote{something}. > > > I guess it's obvious, but yes; I agree :) I'm still not convinced about the need to support this package out of the box. We already have a working solution for many languages, and more general that this LaTeX-centered command. It has limitations, but "csquotes" support would inherit them anyway since it would be built on top of smart quotes mechanism. If you want to csquotes, I suggest to: 1. Disable smart quotes. 2. Define a macro like: #+MACRO: q \enquote{$1} 3. Call the macro when you need it: {{{q(something)}}} Regards, -- Nicolas Goaziou
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 1:12 PM, Rasmus wrote: > This is exactly the reasons why I don't want to use csquotes: > > \enquote{something}. > I'm not sure I understand. Are you suggesting the syntax is bad? But check for instance org-latex-tables-booktabs, which makes optional > support for booktabs. That kind of support for csquote is of course > OK. One reason I'd not use this is that the quotes exported to HTML > and LaTeX are no longer in sync. Which is why I'd rather see > customization through a user smart quote alist. > Okay, that's a fair argument. It would require consistent configuration in more than one place, unless (I think?) Org's LaTeX export automagically use/configure Babel. > > > I think it would make sense to support this for org, and perhaps > >> eventually > >> > make it default behavior. FWIW: I had no idea about this until it bit > me > >> > when my LaTeX document suddenly had bogus quotes in it. > >> > >> This has never happened to me, despite extensive usage of LaTeX for > >> almost ten years. > >> > > > > This is a fairly new occurrence, and it is not true for all LaTeXes > > currently available. The motivation is the one that I have given above: > > See below. > > > quotations are language-specific and semantic markup is preferable. > > Org already has semantic quote characters, namely '"' and "'". > Right: I'm talking about TeX and not org-mode there. The semantic way to say "this is quoted" is csquotes and \enquote. Are those code points U+0022 QUOTATION MARK and U+0027 APOSTROPHE? (I am not an org-mode expert. I'm assuming org-mode does operate on code points, not bytes?) \documentclass{article} >\usepackage{fontspec} >\addfontfeatures{Mapping=} >\addfontfeatures{Ligatures=} >\begin{document} >``test'' >\end{document} > > Could you share a snip that reproduces your problem? > That appears to compile correctly on my machine as well. Perhaps there is a discrepancy between how I'm building the tex file and how org is building the intermediary tex file. I will investigate :) thanks again lvh
Re: [O] [bug] "_ID" in "CUSTOM_ID" being fontified as `org-latex-and-related'
Bastien wrote: > "Sebastien Vauban" writes: > >> As you can see on http://screencast.com/t/58dgm0sE1LgX, the "_ID" part >> of the string "CUSTOM_ID" is not fontified correctly: it should be >> `org-special-keyword' everywhere. > > I can't reproduce this. > > What version of Org? Latest of the day! > Reproducible recipe? Org file: --8<---cut here---start->8--- * Test :PROPERTIES: :CUSTOM_ID: test :END: This is the 1^st time. --8<---cut here---end--->8--- Emacs configuration file: --8<---cut here---start->8--- (load-theme 'leuven t) ;; highlight LaTeX and related syntax (setq org-highlight-latex-and-related '(latex script entities)) (require 'org) --8<---cut here---end--->8--- Se http://screencast.com/t/AT6TE0hE0dJ6. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hi Sébastien, "Sebastien Vauban" writes: > I think that I would have left one pair of {} visible around macro calls > (for making it clear that it's something special, even if we can play > with the face `org-macro'); Playing with the face is the right thing to do I guess. -- Bastien
Re: [O] [bug] "_ID" in "CUSTOM_ID" being fontified as `org-latex-and-related'
Hi Sébastien, "Sebastien Vauban" writes: > As you can see on http://screencast.com/t/58dgm0sE1LgX, the "_ID" part > of the string "CUSTOM_ID" is not fontified correctly: it should be > `org-special-keyword' everywhere. I can't reproduce this. What version of Org? Reproducible recipe? Thanks! -- Bastien
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hello Florian and Bastien, Bastien wrote: > Bastien writes: >> Florian Beck writes: >> >>> I gave it a try. Well, I spend most of my time on formatting this >>> patch. Hope it works. >> >> Works well, thanks. Unless someone is against this change, I'll apply >> it next week. > > This is now in master -- thanks! I just tested it. I think that I would have left one pair of {} visible around macro calls (for making it clear that it's something special, even if we can play with the face `org-macro'); but, anyway, I find this to be a nice improvement. Thanks for it! Best regards, Seb -- Sebastien Vauban
Re: [O] I erroneously pushed a documentation patch to "maint"
Hi Alan, don't worry. ox-koma-letter.el is not yet part of Org core, so the fix in maint will not go into Emacs 24.4. And since we are close to merging master into maint (for 8.3), there is no real harm. Best, -- Bastien
[O] [bug] "_ID" in "CUSTOM_ID" being fontified as `org-latex-and-related'
Hello, As you can see on http://screencast.com/t/58dgm0sE1LgX, the "_ID" part of the string "CUSTOM_ID" is not fontified correctly: it should be `org-special-keyword' everywhere. Best regards, Seb -- Sebastien Vauban
[O] I erroneously pushed a documentation patch to "maint"
Hello, I just did what I hope is a small mistake: I pushed the documentation patch below (for ox-koma-letter.el) to maint instead of to master. My first thought was that I could do another commit to remove this, but then it would pollute the history of this branch. Hence my questions: - should this commit be removed? - if so, what the best way to proceed? I'm very sorry for this blunder, Alan --8<---cut here---start->8--- 240cd3cb40fcc5f958eed7772e9520ef87bf9bd4 HEAD origin/maint maint Author: Rasmus Date: Sat Jan 25 14:08:15 2014 +0100 Documentation fixes for ox-koma-script.el * ox-koma-letter.el commentary (org-koma-letter-use-backaddress): Better documentation. Signed-off-by: Alan Schmitt 1 file changed, 18 insertions(+), 14 deletions(-) contrib/lisp/ox-koma-letter.el | 32 ++-- Modified contrib/lisp/ox-koma-letter.el diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 2b7e847..a42a3a5 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -34,14 +34,14 @@ ;; On top of buffer keywords supported by `latex' back-end (see ;; `org-latex-options-alist'), this back-end introduces the following ;; keywords: -;; - "CLOSING" (see `org-koma-letter-closing'), -;; - "FROM_ADDRESS" (see `org-koma-letter-from-address'), -;; - "LCO" (see `org-koma-letter-class-option-file'), -;; - "OPENING" (see `org-koma-letter-opening'), -;; - "PHONE_NUMBER" (see `org-koma-letter-phone-number'), -;; - "SIGNATURE" (see `org-koma-letter-signature') -;; - "PLACE" (see `org-koma-letter-place') -;; - and "TO_ADDRESS". If unspecified this is set to "\mbox{}". +;; - CLOSING: see `org-koma-letter-closing', +;; - FROM_ADDRESS: see `org-koma-letter-from-address', +;; - LCO: see `org-koma-letter-class-option-file', +;; - OPENING: see `org-koma-letter-opening', +;; - PHONE_NUMBER: see `org-koma-letter-phone-number', +;; - SIGNATURE: see `org-koma-letter-signature', +;; - PLACE: see `org-koma-letter-place', +;; - TO_ADDRESS: If unspecified this is set to "\mbox{}". ;; ;; TO_ADDRESS and FROM_ADDRESS can also be specified using heading ;; with the special tags specified in @@ -67,8 +67,9 @@ ;; (see `org-koma-letter-special-tags-after-letter'). ;; ;; The following variables works differently from the main LaTeX class -;; - "AUTHOR": default to user-full-name but may be disabled. (see org-koma-letter-author), -;; - "EMAIL": same as AUTHOR, (see org-koma-letter-email), +;; - AUTHOR: Default to user-full-name but may be disabled. +;; (See also `org-koma-letter-author'), +;; - EMAIL: Same as AUTHOR. (see also `org-koma-letter-email'), ;; ;; Headlines are in general ignored. However, headlines with special ;; tags can be used for specified contents like postscript (ps), @@ -111,11 +112,16 @@ ;; \[EXTRA]")) ;; ;; Then, in your Org document, be sure to require the proper class -;; with : +;; with: ;; ;;#+LATEX_CLASS: my-letter ;; ;; Or by setting `org-koma-letter-default-class'. +;; +;; You may have to load (LaTeX) Babel as well, e.g., by adding +;; it to `org-latex-packages-alist', +;; +;;(add-to-list 'org-latex-packages-alist '("AUTO" "babel" nil)) ;;; Code: @@ -230,10 +236,8 @@ English manual of 2012-07-22)." (string)) :group 'org-export-koma-letter) - - (defcustom org-koma-letter-use-backaddress nil - "Print return address in small line above to address." + "Print return address in line above to address." :group 'org-export-koma-letter :type 'boolean) --8<---cut here---end--->8---
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Rasmus writes: > Alan Schmitt writes: > >> Rasmus: do you want to change these, or should I do it and apply the >> patch? (The former would be simpler, I have to say.) > > Attached. Sorry about the delay. They should fix Nicholas' > 'concerns'. Applied and pushed, thanks. Alan
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Alan Schmitt writes: > Hello Rasmus, > > I applied the first patch, with the following small changes. Please ignore this email, there was something wrong in my setup (I was in the maint branch ...). Sorry for the noise. Alan
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Hello Rasmus, I applied the first patch, with the following small changes. This part would not apply: --8<---cut here---start->8--- @@ -252,7 +258,7 @@ This option can also be set with the OPTIONS keyword, e.g.: :group 'org-export-koma-letter) (defcustom org-koma-letter-use-backaddress nil - "Non-nil prints return address in small line above to address. + "Non-nil prints return address in line above to address. This option can also be set with the OPTIONS keyword, e.g.: \"backaddress:t\"." :group 'org-export-koma-letter --8<---cut here---end--->8--- (because the string starts with "Print" now.) I just removed the "small" from the sentence, and some spurious white lines. Here is what I got: --8<---cut here---start->8--- @@ -230,10 +236,8 @@ English manual of 2012-07-22)." (string)) :group 'org-export-koma-letter) - - (defcustom org-koma-letter-use-backaddress nil - "Print return address in small line above to address." + "Print return address in line above to address." :group 'org-export-koma-letter :type 'boolean) --8<---cut here---end--->8--- (The line numbers are quite different ... there may be some edits on your side that have not made it to the patch.) I could not apply the second patch because the line numbers are too different. For instance, this chunk is supposed to start on line 266, not 336 here. --8<---cut here---start->8--- @@ -336,6 +338,16 @@ This option can also be set with the OPTIONS keyword, e.g.: :group 'org-export-koma-letter :type 'boolean) +(defcustom org-koma-letter-use-title t + "Non-nil means use a title in the letter if present. +This option can also be set with the OPTIONS keyword, +e.g. \"with-title:nil\". + +See also `org-koma-letter-prefer-subject' for the handling of +title versus subject." + :group 'org-export-koma-letter + :type 'boolean) + (defcustom org-koma-letter-default-class "default-koma-letter" "Default class for `org-koma-letter'. The value must be a member of `org-latex-classes'." --8<---cut here---end--->8--- Also, what is the text after the "@@" in the first line? I can manually apply the patch (it's not that big), or you can regenerate it. Please let me know what you prefer. Best, Alan
Re: [O] Quotes for LaTeX export
Hi Laurens, Laurens Van Houtven <_...@lvh.io> writes: > Hi Rasmus, > > On Tue, Feb 4, 2014 at 10:42 PM, Rasmus wrote: > >> Hi Laurens, >> >> Laurens Van Houtven <_...@lvh.io> writes: >> >> > I'm writing a book using org-mode. On export, org-mode turns double >> quotes >> > like "hello" into ``hello''. Some modern LaTeXes no longer support that >> > form, instead preferring semantic markup. (The reasoning being that the >> > markup implies a particular quote style, whereas quotation style is >> > language-dependent.) >> >> This is not true. Quotes depend on your LANGUAGE-cookie. See >> org-export-smart-quotes-alist. >> > > To more accurately: *my* org-mode is turning double quotes into > ``something'' when I export to LaTeX. I do not have an explicit language > cookie set. That is the part you objected to, not the LaTeX part, right? The language is org-export-default-language if no LANGUAGE is set. >> > As a result, I get >> > >> > The preferred way to do that these days is, in the preamble: >> > >> > \usepackage{csquotes} >> > >> > ... and then later: >> > >> > \enquote{something} >> >> But this would require us to load an extra package. Org is quite >> capable of handling this on the lisp side (and Org ≠ LaTeX). Clearly, >> we could have a org-export-user-smart-quote-alist taking priority over d>> the predefined one. >> > > A package that, IIUC, is quite commonly available. Plus, the consequence is > that on a bunch of new setups, you get busted quotes, whereas the csquote + > enquote approach AFAIK works on pretty much any reasonable LaTeX > installation. This is exactly the reasons why I don't want to use csquotes: \enquote{something}. But check for instance org-latex-tables-booktabs, which makes optional support for booktabs. That kind of support for csquote is of course OK. One reason I'd not use this is that the quotes exported to HTML and LaTeX are no longer in sync. Which is why I'd rather see customization through a user smart quote alist. > > I think it would make sense to support this for org, and perhaps >> eventually >> > make it default behavior. FWIW: I had no idea about this until it bit me >> > when my LaTeX document suddenly had bogus quotes in it. >> >> This has never happened to me, despite extensive usage of LaTeX for >> almost ten years. >> > > This is a fairly new occurrence, and it is not true for all LaTeXes > currently available. The motivation is the one that I have given above: See below. > quotations are language-specific and semantic markup is preferable. Org already has semantic quote characters, namely '"' and "'". Compare the output of #+LANGUAGE: fr #+OPTIONS: ':t "test" and #+LANGUAGE: en #+OPTIONS: ':t "test" > I don't have an exact list of which, but e.g. in ConTeXt MkIV it is > now the default, and it is also the default for me on the current > TeX Live when using lualatex or xelatex. This leads me to believe > that perhaps it is not a *common* issue, but it > > Here is an example: > https://f.cloud.github.com/assets/97816/2078835/cac687b6-8dc2-11e3-8b6a-00c1a8175c94.png I'm unable to reproduce with TeXLive up-to-date 2013 with both XeLaTeX and LuaLaTeX. I don't have context installed. Here's my code where I tried to disable fancy features of fontspec: \documentclass{article} \usepackage{fontspec} \addfontfeatures{Mapping=} \addfontfeatures{Ligatures=} \begin{document} ``test'' \end{document} Could you share a snip that reproduces your problem? –Rasmus -- I hear there's rumors on the, uh, Internets. . .
Re: [O] Behavior of M-q on comments in code blocks
"Sebastien Vauban" writes: > Though, I can't say whether the fact it does not work anymore is due to > changes in Org or in my Emacs configuration. Any hint? Works fine here, surely something in your configuration. -- Bastien
Re: [O] Behavior of M-q on comments in code blocks
"Sebastien Vauban" writes: Hello, > Some time ago, doing a M-q on a comment in a code block did work. > > For example, the following: I followed up to you post using gnus/message-mode with outorg (i.e. writing the mail in full org-mode), outcommented your first code block and did M-q on the comment line: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for ;; AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages ;; that have documentation in Info) (global-set-key (kbd "") 'info-lookup-symbol) #+end_src the result looks fine, so it might be related to your config. PS #+BEGIN_SRC emacs-lisp (message "%s" (org-version)) #+END_SRC #+results: : 8.2.5g -- cheers, Thorsten
Re: [O] Quotes for LaTeX export
On Wed, Feb 5, 2014 at 8:46 AM, Bastien wrote: > Nick Dokos writes: > > > IIRC, there was support for csquotes in the old exporter[fn:1] but I > guess > > it went away when the new exporter came along. > > Yes, it'd be good to make it possible again to use > \usepackage{csquotes} and \enquote{something}. I guess it's obvious, but yes; I agree :) hth lvh
Re: [O] Quotes for LaTeX export
Hi Rasmus, On Tue, Feb 4, 2014 at 10:42 PM, Rasmus wrote: > Hi Laurens, > > Laurens Van Houtven <_...@lvh.io> writes: > > > I'm writing a book using org-mode. On export, org-mode turns double > quotes > > like "hello" into ``hello''. Some modern LaTeXes no longer support that > > form, instead preferring semantic markup. (The reasoning being that the > > markup implies a particular quote style, whereas quotation style is > > language-dependent.) > > This is not true. Quotes depend on your LANGUAGE-cookie. See > org-export-smart-quotes-alist. > To more accurately: *my* org-mode is turning double quotes into ``something'' when I export to LaTeX. I do not have an explicit language cookie set. That is the part you objected to, not the LaTeX part, right? > > As a result, I get > > > > The preferred way to do that these days is, in the preamble: > > > > \usepackage{csquotes} > > > > ... and then later: > > > > \enquote{something} > > But this would require us to load an extra package. Org is quite > capable of handling this on the lisp side (and Org ≠ LaTeX). Clearly, > we could have a org-export-user-smart-quote-alist taking priority over > the predefined one. > A package that, IIUC, is quite commonly available. Plus, the consequence is that on a bunch of new setups, you get busted quotes, whereas the csquote + enquote approach AFAIK works on pretty much any reasonable LaTeX installation. That said, if org does it, that's fine by me too. > I think it would make sense to support this for org, and perhaps > eventually > > make it default behavior. FWIW: I had no idea about this until it bit me > > when my LaTeX document suddenly had bogus quotes in it. > > This has never happened to me, despite extensive usage of LaTeX for > almost ten years. > This is a fairly new occurrence, and it is not true for all LaTeXes currently available. The motivation is the one that I have given above: quotations are language-specific and semantic markup is preferable. I don't have an exact list of which, but e.g. in ConTeXt MkIV it is now the default, and it is also the default for me on the current TeX Live when using lualatex or xelatex. This leads me to believe that perhaps it is not a *common* issue, but it Here is an example: https://f.cloud.github.com/assets/97816/2078835/cac687b6-8dc2-11e3-8b6a-00c1a8175c94.png > If there is no interest to add this to org, how do I hack org so that this > > is what it does? > > The cleanest way would be a filter, probably > org-export-filter-quote-block-functions and filter-plain-text. > > The easiest way would be a macro or simply redefining > org-export-smart-quotes-alist to suit your needs. > thanks! lvh
Re: [O] Simple quote becomes double in LaTeX export
Hello Nicolas, Nicolas Goaziou wrote: > "Sebastien Vauban" writes: > >> With a text in French, and Babel present in my list of LaTeX classes, >> the following title gets its simple quote converted to a double one: >> >> [...] > > This should be fixed in maint. > > Thank you for reporting it. In a similar vain, though different, the following: --8<---cut here---start->8--- #+LANGUAGE: fr * Note Avant, quand on faisait `M-q' sur un commentaire ... --8<---cut here---end--->8--- does generate the following when exported (to HTML, in this case): --8<---cut here---start->8--- Avant, quand on faisait `M-q » sur un commentaire ... --8<---cut here---end--->8--- Now, let's be honest, I can completely understand that this wouldn't be a bug, because I used particular syntax (how variables are enclosed in Emacs Lisp documentation), which is not correct. Though, I wanted to report it, as I was surprised to see a single quote converted to a double French quote. Disregard this if needed! Best regards, Seb -- Sebastien Vauban
[O] Behavior of M-q on comments in code blocks
Hello, Some time ago, doing a M-q on a comment in a code block did work. For example, the following: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for AWK, C, Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have documentation in Info) (global-set-key (kbd "") 'info-lookup-symbol) #+end_src became: #+begin_src emacs-lisp ;; display symbol definitions, as found in the relevant manual (for AWK, C, ;; Emacs Lisp, LaTeX, M4, Makefile, Sh and other languages that have ;; documentation in Info) (global-set-key (kbd "") 'info-lookup-symbol) #+end_src after `M-q' on the comment line (without going to the indirect buffer). This does not work anymore, as you can see on http://screencast.com/t/iauhzbvnmXXn. It even completely breaks the block itself. Though, I can't say whether the fact it does not work anymore is due to changes in Org or in my Emacs configuration. Any hint? Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Font-lock: allow hiding of brackets surrounding macros
Hi Florian, Bastien writes: > Florian Beck writes: > >> I gave it a try. Well, I spend most of my time on formatting this >> patch. Hope it works. > > Works well, thanks. Unless someone is against this change, I'll apply > it next week. This is now in master -- thanks! -- Bastien
Re: [O] [RFC] Make QUOTE an export keyword instead of an element type
Nicolas Goaziou writes: > Here is the function. If it is good enough, I'll add tests and wrap it > up in a patch. I don't think we should prevent users to convert a headline into a fixed-width line. Also, better to use the IGNORE-INVISIBLE arg of org-move-to-column IMO. Otherwise works fine, thanks! -- Bastien
Re: [O] unexpected link behavior in headlines - maybe bug
Hi John John Kitchin writes: > I discovered an unexpected behavior with two links in a headline. The > simplest example to reproduce it is here: > > * file:dft-course-mode.el [[file:my-theme.el][another file]] This is now fixed in maint, thanks for reporting this. -- Bastien
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Nicolas Goaziou writes: > No. Other groups are `org-export-latex', `org-export-html'... Bastien writes: > Unless I miss something, other groups are > > org-export-html > org-export-latex > > etc. > > so org-export-koma-letter seems right. Right. That's a late night blunder on my part! Thanks for pointing me in the right direction. -- Er du tosset for noge' lårt!
Re: [O] Moving by block in the block agenda
Hi Bart, "Bart Bunting" writes: > I have a block agenda defined which is mostly taken from Bernt Hansen's > org-mode.org. > > Some of the blocks contain many entries. I am trying to find out if > there is a simple way to navigate between agenda blocks. > > The most likely thing I found was org-agenda-goto-block-beginning but it > doesn't appear to do that. > > What am I missing? Nothing -- I just pushed a change in master which remap `backward-paragraph' and `forward-paragraph' to the new commands `org-agenda-backward-block' and `org-agenda-forward-block'. Let me know if it does what you want and thanks for raising this. Thanks, -- Bastien
Re: [O] [PATCH] Add autoload cookie for function org-table-iterate-buffer-tables
Hi Sébastien, "Sebastien Vauban" writes: > When checking the status of some patches I provided, I just noticed that > the function `org-update-all-dblocks' is NOT autoloaded anymore. > > Can you put the autoload cookie back? Thanks. Why is it necessary? -- Bastien
Re: [O] [PATCH] Add autoload cookie for function org-table-iterate-buffer-tables
Hi Bastien, Bastien wrote: > "Sebastien Vauban" writes: > >> In the same vein, I found `org-update-all-dblocks', for which I propose a >> patch hereafter. > > Applied against master, thanks. > >> [...] > >> From 3df73c03d9a8c56189cbe91ec752bcc3269536ca Mon Sep 17 00:00:00 2001 >> From: Sebastien Vauban >> Date: Wed, 18 Apr 2012 11:12:00 +0200 >> Subject: [PATCH 3/3] Add autoload cookie for org-update-all-dblocks >> >> * org.el (org-update-all-dblocks): Autoload function. When checking the status of some patches I provided, I just noticed that the function `org-update-all-dblocks' is NOT autoloaded anymore. Can you put the autoload cookie back? Thanks. Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH][ox-koma-letter] changed-in-buffer, subject, minor fixes
Rasmus writes: > Quick but unrelated question. I'm updating the Worg page and I > noticed that the customize-group for ox-koma-letter is > org-export-koma-letter. Given that other groups are org-latex and > org-html etc., should the group not be called org-koma-letter? Yes, org-koma-letter sounds better. Alan