Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
Hi Eric, I personally don't have time to make these changes right now, but I'd be happy to provide guidance and answer questions to anyone who wanted to try to submit a patch. Also, there are a number of files which can serve as examples of how to compile and execute code with Babel e.g., ob-java.el and ob-C.el. That's what I suspected judging from the behaviour I've seen. Is anyone else interested in such work? I don't have much time either, in particular I'm not sufficiently familiar with emacs and Lisp to do something useful quickly. I would prefer to keep haskell as the source block type if only so that the blocks are fontified with haskell-mode. However something like an :engine or :compiler keyword could be used to specify ghc or hugs. Good idea, but specifying ghc is ambiguous: it'll have to be either ghci, runghc/runhaskell, oder hugs, or maybe some other interpreter/compiler someone else would like to use (nhc98, etc., there a quite a few). At least the three options I listed all have incompatibilities in even the simplest use cases, owing to the peculiarities of Haskell as a pure, declarative language. Also, using runghc would require the code block to be tangled first into a temporary file. Is that easily done in babel? András
[O] talk about org-mode
Hi, is anyone interested in giving a blistering talk about org-mode at the Snow headquarters in the Netherlands (the town of Geldermalsen)? Our original plan to have someone talk about hacking DECT and other protocols had to be postponed. The public consists of about 80 Unix and Security Specialists. The date is September 1st. Regards, Joost Helberg -- Snow B.V.http://snow.nl
Re: [O] indenting nested TODOs in agenda views
On Mon, Aug 22 2011, Sebastien Vauban wrote: Hi Eric, Eric Abrahamsen wrote: On Mon, Aug 22 2011, Bernt Hansen wrote: Eric Abrahamsen e...@ericabrahamsen.net writes: What would it take to get an Agenda tags view that indented nested TODOs? I've always been bothered by the fact that nested TODOs within a subtree are all flattened for the agenda view, so sometimes it's hard to tell that several TODOs all belong to one bigger TODO. I guess it would have to go in `org-finalize-agenda-entries', after the filter function is run, and somehow instead of the way org entries are currently fed to the sorting function. Would this be a desirable option? Set (org-tags-match-list-sublevels 'indented) in your agenda view. That's pretty interesting, but not quite what I meant: I was thinking that TODOs would be first sorted by outline level, and then only TODOs that belonged to a subtree with higher TODOs would be indented. With indented, a second-level TODO can come after a first-level TODO and appear to be subordinate to it, though they belong to completely different subtrees. But stating the problem this way makes me realize it's more complicated than I thought… Just an incentive to tell you I'd also would love that feature. Best regards, Seb I'm going to have a whack at this, will probably take me a week or more… E
[O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi, here is an example that delivers an error reference 'table1' not found in this buffer when trying to export to HTML (others not tried yet): #+tblname: table1 :noexport: | n | x | y1 | y2 | |---+---+-+--| | 0 | 1 | 2.0 | 3.0 | | 1 | 2 | 2.1 | 2.0 | | 2 | 3 | 2.0 | 0.3 | | 3 | 4 | 1.0 | 0.6 | | 4 | 5 | 1.4 | -0.1 | | 5 | 6 | 1.6 | 1.2 | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 set size square plot t u 2:3 w lp, t u 2:4 w lp #+end_src If I remove the :noexport: tag, everything works fine. Am I doing something wrong here? I don't think that :noexport: should affect the use of the table for other purposes. András Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.7 (release_7.7.167.gfceb) current state: == (setq org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t) (haskell . t) (latex . t) (octave . t) (R . t) (ruby . t) (scheme . t) (sh . t)) org-metaup-hook '(org-babel-load-in-session-maybe) org-after-todo-state-change-hook '(org-clock-out-if-current) org-babel-tangle-lang-exts '((ruby . rb) (latex . tex) (haskell . hs) (asymptote . asy) (emacs-lisp . el)) org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup) org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-confirm-shell-link-function 'yes-or-no-p org-export-first-hook '(org-beamer-initialize-open-trackers) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-blank-before-new-entry nil org-babel-pre-tangle-hook '(save-buffer) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) 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) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src org-babel-exp-inline-src-blocks)) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-occur-hook '(org-first-headline-recenter) org-from-is-user-regexp nil org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-confirm-babel-evaluate nil org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) org-metadown-hook '(org-babel-pop-to-session-maybe) org-export-blocks '((src org-babel-exp-src-block nil) (comment org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil)) )
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András al., András Major wrote: here is an example that delivers an error reference 'table1' not found in this buffer when trying to export to HTML (others not tried yet): #+tblname: table1 :noexport: | n | x | y1 | y2 | |---+---+-+--| | 0 | 1 | 2.0 | 3.0 | | 1 | 2 | 2.1 | 2.0 | | 2 | 3 | 2.0 | 0.3 | | 3 | 4 | 1.0 | 0.6 | | 4 | 5 | 1.4 | -0.1 | | 5 | 6 | 1.6 | 1.2 | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 set size square plot t u 2:3 w lp, t u 2:4 w lp #+end_src If I remove the :noexport: tag, everything works fine. Am I doing something wrong here? I don't think that :noexport: should affect the use of the table for other purposes. I will let answer the ones who decide on such things. Though, I am amazed you put a tag on the table itself. I'd have expected the noexport tag to be on a section containing the table. So, my extra question (to the same persons) is: is this an allowed use of a tag? Or just an undocumented feature which temporarily works? -- euh, or not even works, in fact... Best regards, Seb -- Sebastien Vauban
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Sebastian, I will let answer the ones who decide on such things. Though, I am amazed you put a tag on the table itself. I'd have expected the noexport tag to be on a section containing the table. I forgot to mention in the report that of course I tried that too: if I place the table and the code in two sections and tag the section containing the table with :noexport:, the result is exactly the same. Omitting the tag makes it work again. So, my extra question (to the same persons) is: is this an allowed use of a tag? Or just an undocumented feature which temporarily works? -- euh, or not even works, in fact... In my little experience, it work, and I think it's a desirable feature too. I'm not really keen on creating a section for a table just so that I can hide it. András
[O] Bug: named columns in tables not working if name contains _
Hi, Yet another one I just stumbled across: if I create a table and use ! in the first column to assign names to the columns, I can only reference those columns by name in #+TBLFM: if the names don't contain a _ character. This isn't mentioned in the docs and shouldn't be so, IMHO. I haven't checked for other common characters that are prohibited, but the _ bites me quite a bit. András
Re: [O] Bug: named columns in tables not working if name contains _
András Major andras.g.ma...@gmail.com wrote: Yet another one I just stumbled across: if I create a table and use ! in the first column to assign names to the columns, I can only reference those columns by name in #+TBLFM: if the names don't contain a _ character. This isn't mentioned in the docs and shouldn't be so, IMHO. I haven't checked for other common characters that are prohibited, but the _ bites me quite a bit. Try adding an underscore to the regexp on line 2179 of org-table.el - something like this (untested): ... (if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name) (push (cons name (int-to-string cnt)) org-table-column-names The only characters permitted are alphanumerics. That can probably be easily relaxed. Nick
Re: [O] Bug: named columns in tables not working if name contains
Try adding an underscore to the regexp on line 2179 of org-table.el - something like this (untested): ... (if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name) (push (cons name (int-to-string cnt)) org-table-column-names The only characters permitted are alphanumerics. That can probably be easily relaxed. Thanks Nick. It would be nice if the documentation reflected such an arbitrary choice of characters you can use... András
Re: [O] Bug: named columns in tables not working if name contains _
On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote: András Major andras.g.ma...@gmail.com wrote: Yet another one I just stumbled across: if I create a table and use ! in the first column to assign names to the columns, I can only reference those columns by name in #+TBLFM: if the names don't contain a _ character. This isn't mentioned in the docs and shouldn't be so, IMHO. I haven't checked for other common characters that are prohibited, but the _ bites me quite a bit. Try adding an underscore to the regexp on line 2179 of org-table.el - something like this (untested): ... (if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name) (push (cons name (int-to-string cnt)) org-table-column-names The only characters permitted are alphanumerics. That can probably be easily relaxed. Hi Nick, I don't think it can be easily relaxed. Many other characters are operators in Calc and would lead to confusion. But amending the docs is certainly a good idea. Thanks - Carsten
Re: [O] Bug: named columns in tables not working if name contains _
Carsten Dominik carsten.domi...@gmail.com wrote:
On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote:
András Major andras.g.ma...@gmail.com wrote:
Yet another one I just stumbled across: if I create a table and use
! in the first column to assign names to the columns, I can only
reference those columns by name in #+TBLFM: if the names don't contain
a _ character. This isn't mentioned in the docs and shouldn't be
so, IMHO. I haven't checked for other common characters that are
prohibited, but the _ bites me quite a bit.
Try adding an underscore to the regexp on line 2179 of org-table.el -
something like this (untested):
...
(if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name)
(push (cons name (int-to-string cnt)) org-table-column-names
The only characters permitted are alphanumerics. That can probably be
easily relaxed.
Hi Nick, I don't think it can be easily relaxed. Many other characters are
operators in Calc and would lead to confusion.
So add more syntax: formulas can use {this+is-a*/strange\@name}.
OK, ok - just kidding.
Thanks,
Nick
PS. This is a paraphrase of the indirection principle: Any problem can
be solved by adding yet another layer of syntax...
[O] [odt] equation labels
Hello,
I am using the excellent org-odt, so thanks to Jambunathan K, and
everyone who has ever contributed to orgmode.
This may be quite simple so I am asking before making an minimal
example. Does anyone know how to cause a label such as Figure 1. in
the odt (for the resulting png), and set the caption for an equation
such as:
#+CAPTION: some caption
#+LABEL: eqn:psychrometric
\begin{equation*}
\label{eq:psychrometric}
\capillaryPressure = ln(RH)\cdot \dens_w\frac{RT}{M_w}
\end{equation*}
?
The orgmode manual says that captions and labels are for images and
tables so unless there is a special trick I would probably try to wrap
the latex in something first, for dvipng to return the png to org, to
apply the CAPTION to, before exporting to odt.
Extra points for making it Equation 1. instead of Figure 1..
Thanks,
Myles
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major andras.g.ma...@gmail.com writes: Hi, here is an example that delivers an error reference 'table1' not found in this buffer when trying to export to HTML (others not tried yet): #+tblname: table1 :noexport: | n | x | y1 | y2 | |---+---+-+--| | 0 | 1 | 2.0 | 3.0 | | 1 | 2 | 2.1 | 2.0 | | 2 | 3 | 2.0 | 0.3 | | 3 | 4 | 1.0 | 0.6 | | 4 | 5 | 1.4 | -0.1 | | 5 | 6 | 1.6 | 1.2 | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 set size square plot t u 2:3 w lp, t u 2:4 w lp #+end_src If I remove the :noexport: tag, everything works fine. Am I doing something wrong here? I don't think that :noexport: should affect the use of the table for other purposes. This is the first time I've seen a tag applied to a table. I've updated the results regular expression so that it will now admit examples like yours above. Please let me know if this doesn't work with the latest Org-mode. Best -- Eric András Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.7 (release_7.7.167.gfceb) current state: == (setq org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars) org-speed-command-hook '(org-speed-command-default-hook org-babel-speed-command-hook) org-babel-load-languages '((asymptote . t) (ditaa . t) (dot . t) (gnuplot . t) (haskell . t) (latex . t) (octave . t) (R . t) (ruby . t) (scheme . t) (sh . t)) org-metaup-hook '(org-babel-load-in-session-maybe) org-after-todo-state-change-hook '(org-clock-out-if-current) org-babel-tangle-lang-exts '((ruby . rb) (latex . tex) (haskell . hs) (asymptote . asy) (emacs-lisp . el)) org-export-blocks-postblock-hook '(org-exp-res/src-name-cleanup) org-export-latex-format-toc-function 'org-export-latex-format-toc-default org-tab-first-hook '(org-hide-block-toggle-maybe org-src-native-tab-command-maybe org-babel-hide-result-toggle-maybe) org-src-mode-hook '(org-src-babel-configure-edit-buffer org-src-mode-configure-edit-buffer) org-confirm-shell-link-function 'yes-or-no-p org-export-first-hook '(org-beamer-initialize-open-trackers) org-agenda-before-write-hook '(org-agenda-add-entry-text) org-blank-before-new-entry nil org-babel-pre-tangle-hook '(save-buffer) org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers org-cycle-show-empty-lines org-optimize-window-after-visibility-change) org-export-preprocess-before-normalizing-links-hook '(org-remove-file-link-modifiers) 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) org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point org-babel-execute-safely-maybe) org-confirm-elisp-link-function 'yes-or-no-p org-export-interblocks '((lob org-babel-exp-lob-one-liners) (src org-babel-exp-inline-src-blocks)) org-clock-out-hook '(org-clock-remove-empty-clock-drawer) org-occur-hook '(org-first-headline-recenter) org-from-is-user-regexp nil org-export-preprocess-before-selecting-backend-code-hook '(org-beamer-select-beamer-code) org-confirm-babel-evaluate nil org-export-latex-final-hook '(org-beamer-amend-header org-beamer-fix-toc org-beamer-auto-fragile-frames org-beamer-place-default-actions-for-lists) org-metadown-hook '(org-babel-pop-to-session-maybe) org-export-blocks '((src org-babel-exp-src-block nil) (comment org-export-blocks-format-comment t) (ditaa org-export-blocks-format-ditaa nil) (dot org-export-blocks-format-dot nil)) ) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: Babel: haskell code evaluation inconsistency [7.7 (release_7.7.160.g3e33)]
András Major andras.g.ma...@gmail.com writes: Hi Eric, I personally don't have time to make these changes right now, but I'd be happy to provide guidance and answer questions to anyone who wanted to try to submit a patch. Also, there are a number of files which can serve as examples of how to compile and execute code with Babel e.g., ob-java.el and ob-C.el. That's what I suspected judging from the behaviour I've seen. Is anyone else interested in such work? I don't have much time either, in particular I'm not sufficiently familiar with emacs and Lisp to do something useful quickly. I would prefer to keep haskell as the source block type if only so that the blocks are fontified with haskell-mode. However something like an :engine or :compiler keyword could be used to specify ghc or hugs. Good idea, but specifying ghc is ambiguous: it'll have to be either ghci, runghc/runhaskell, oder hugs, or maybe some other interpreter/compiler someone else would like to use (nhc98, etc., there a quite a few). At least the three options I listed all have incompatibilities in even the simplest use cases, owing to the peculiarities of Haskell as a pure, declarative language. A more open-ended :compiler or :interpreter header argument accepting ghc, rungch, hugs and nhc98 among others, sounds like a good idea. Also, using runghc would require the code block to be tangled first into a temporary file. Is that easily done in babel? Very easily, see ob-java.el. Adopting the compile-then-run functionality from there should not be a large task. Best -- Eric András -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] git repository over http?
Bastien b...@altern.org writes: Hi Jason, Jason Dunsmore emacs-orgm...@dunsmor.com writes: I ran some tests and found that the download speed is proportional to the size of the repo: Good to know, thanks. If you clone via git://, it does some optimizations during the transfer, whereas cloning via http:// does not. If I do a git gc on the repo, it reduces the size of the repo on the server and the time to download via http:// Okay -- can you git gc on the server? Okay, done: --8---cut here---start-8--- orgmode@org:~$ du -sh org-mode.git 225Morg-mode.git orgmode@org:~/org-mode.git$ find objects/|wc -l 6523 orgmode@org:~/org-mode.git$ git gc Counting objects: 52023, done. Delta compression using up to 4 threads. Compressing objects: 100% (14474/14474), done. Writing objects: 100% (52023/52023), done. Total 52023 (delta 41421), reused 46864 (delta 37483) Removing duplicate objects: 100% (256/256), done. orgmode@org:~/org-mode.git$ du -sh 56M . orgmode@org:~/org-mode.git$ find objects/|wc -l 66 --8---cut here---end---8--- I lowered the git auto-gc threshold from the default of 6700 (loose objects) to 1000. orgmode@org:~/org-mode.git$ git config gc.auto 1000 Regards, Jason
Re: [O] Blog-like sitemap for org-publish
On Thu 2011-08-18 at 19:09, Bastien wrote: Hi Jon, Jon Anders Skorpen jasko...@mindmutation.net writes: I have made a function which creates a blog-like sitemap. It works as an alternative sitemap function to org-publish. This looks very interesting -- do you have a webpage we can look at to see the result? Thanks! -- Bastien Yes. Here is a link to a test blog with some test posts, and one real post in norwegian. http://beta.mindmutation.net Since my initial email I have found a couple of things that should be done a little different, but I haven't had time to fix them. This includes the way keywords and dates are exported, and a couple of other things. -Jon Anders
Re: [O] Bug: named columns in tables not working if name contains _
On Aug 23, 2011, at 4:32 PM, Nick Dokos wrote:
Carsten Dominik carsten.domi...@gmail.com wrote:
On Aug 23, 2011, at 3:53 PM, Nick Dokos wrote:
András Major andras.g.ma...@gmail.com wrote:
Yet another one I just stumbled across: if I create a table and use
! in the first column to assign names to the columns, I can only
reference those columns by name in #+TBLFM: if the names don't contain
a _ character. This isn't mentioned in the docs and shouldn't be
so, IMHO. I haven't checked for other common characters that are
prohibited, but the _ bites me quite a bit.
Try adding an underscore to the regexp on line 2179 of org-table.el -
something like this (untested):
...
(if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name)
(push (cons name (int-to-string cnt)) org-table-column-names
The only characters permitted are alphanumerics. That can probably be
easily relaxed.
Hi Nick, I don't think it can be easily relaxed. Many other characters are
operators in Calc and would lead to confusion.
So add more syntax: formulas can use {this+is-a*/strange\@name}.
OK, ok - just kidding.
Thanks,
Nick
PS. This is a paraphrase of the indirection principle: Any problem can
be solved by adding yet another layer of syntax...
:) Yes, true!
- Carsten
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, This is the first time I've seen a tag applied to a table. I've updated the results regular expression so that it will now admit examples like yours above. Please let me know if this doesn't work with the latest Org-mode. That's good news! Well, the bad news is that it doesn't work. I've just pulled the current version (release_7.7.174.g63fae) and now the behaviour is different: - :noexport: in the #+tblname: has no effect. - The :noexport: tag in a section including the table still has the same effect as before: table1 is not available as an input to the code block. - There are certain subtleties which I will report separately as they probably were there before and are unrelated, I just never bumped into them. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major andras.g.ma...@gmail.com writes: Hi Eric, This is the first time I've seen a tag applied to a table. I've updated the results regular expression so that it will now admit examples like yours above. Please let me know if this doesn't work with the latest Org-mode. That's good news! Well, the bad news is that it doesn't work. I've just pulled the current version (release_7.7.174.g63fae) and now the behaviour is different: - :noexport: in the #+tblname: has no effect. I'm not sure that it is legal to apply tags to tables, so I'm not sure if this is a bug. - The :noexport: tag in a section including the table still has the same effect as before: table1 is not available as an input to the code block. Oh, this was actually due to a slightly different issue, which I've just fixed. Specifically the following org-mode file now exports as successfully. * top ** not to be exported :noexport: #+data: something | 0 | | 1 | | 1 | | 2 | | 3 | | 5 | | 8 | ** to be exported #+begin_src emacs-lisp :var fib=something :exports results (car (nth 4 fib)) #+end_src - There are certain subtleties which I will report separately as they probably were there before and are unrelated, I just never bumped into them. András -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, That's good news! Well, the bad news is that it doesn't work. I've just pulled the current version (release_7.7.174.g63fae) and now the behaviour is different: - :noexport: in the #+tblname: has no effect. I'm not sure that it is legal to apply tags to tables, so I'm not sure if this is a bug. Certainly, I'm just saying that it used to work but now it doesn't. I think that anything that works despite being designed and documented otherwise is confusing to the user and should be considered a bug. I'm happy that it no longer works and hope that it stays that way. - The :noexport: tag in a section including the table still has the same effect as before: table1 is not available as an input to the code block. Oh, this was actually due to a slightly different issue, which I've just fixed. Specifically the following org-mode file now exports as successfully. Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major andras.g.ma...@gmail.com writes: here is an example that delivers an error reference 'table1' not found in this buffer when trying to export to HTML (others not tried yet): #+tblname: table1 :noexport: | n | x | y1 | y2 | |---+---+-+--| | 0 | 1 | 2.0 | 3.0 | | 1 | 2 | 2.1 | 2.0 | | 2 | 3 | 2.0 | 0.3 | | 3 | 4 | 1.0 | 0.6 | | 4 | 5 | 1.4 | -0.1 | | 5 | 6 | 1.6 | 1.2 | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 set size square plot t u 2:3 w lp, t u 2:4 w lp #+end_src If I remove the :noexport: tag, everything works fine. Am I doing something wrong here? Yes -- :noexport: is to be used on headlines only, not on tables. If you remove the :noexport: you should get the correct png (see attached.) HTH, attachment: bug_gnuplot.png -- Bastien
Re: [O] Bug: named columns in tables not working if name contains
Hi András, András Major andras.g.ma...@gmail.com writes: Thanks Nick. It would be nice if the documentation reflected such an arbitrary choice of characters you can use... I added a footnote. -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major andras.g.ma...@gmail.com writes: I'd have expected the noexport tag to be on a section containing the table. I forgot to mention in the report that of course I tried that too: if I place the table and the code in two sections and tag the section containing the table with :noexport:, the result is exactly the same. I'm not sure I understand -- does it mean that C-cC-c on #+begin_src fails in the example below? , | * Headline :noexport: | | #+tblname: table1 | | n | x | y1 | y2 | | |---+---+-+--| | | 0 | 1 | 2.0 | 3.0 | | | 1 | 2 | 2.1 | 2.0 | | | 2 | 3 | 2.0 | 0.3 | | | 3 | 4 | 1.0 | 0.6 | | | 4 | 5 | 1.4 | -0.1 | | | 5 | 6 | 1.6 | 1.2 | | | #+begin_src gnuplot :file bug_gnuplot.png :var t=table1 | set size square | plot t u 2:3 w lp, t u 2:4 w lp | #+end_src ` It works for me. In my little experience, it work, and I think it's a desirable feature too. I'm not really keen on creating a section for a table just so that I can hide it. Tags only have meaning on headlines, whether it's for really tagging the headlines or for (un)selecting them during the export process. If we want export-related function specifically for tables, I'd rather use something like #+export_table: and a list of options. HTH, -- Bastien
Re: [O] Bug: Toggle descriptive and literal links [7.4]
Hi Thomas, t...@tsdye.com (Thomas S. Dye) writes: Thanks for adding this. I work with literal links and this potentially saves time and effort. I wonder if I'm using it correctly? In .emacs I set org-link-display-descriptive nil and have: org-link-display-descriptive is a variable defined in `org.el'. Its value is nil Documentation: Non-nil means Org will display descriptive links. E.g. [[http://orgmode.org][Org website]] will be displayed as Org Website, hiding the link itself and just displaying its description. When set to `nil', Org will display the full links literally. You can interactively set the value of this variable using the `org-toggle-link-display'. But when I open an Org-mode buffer I find the links displayed descriptively. The initialization of the link display relied on `org-descriptive-links' and I discover this variable (doh!) So I've now remove `org-link-display-descriptive' and use `org-descriptive-links' instead for backward compatibility. Please use this variable too and let me know if things are all right now. Best, -- Bastien
Re: [O] Bug: named columns in tables not working if name contains _
Hi Nick, Nick Dokos nicholas.do...@hp.com writes: Try adding an underscore to the regexp on line 2179 of org-table.el - something like this (untested): ... (if (string-match ^[a-zA-Z][a-zA-Z0-9_]*$ name) (push (cons name (int-to-string cnt)) org-table-column-names The only characters permitted are alphanumerics. That can probably be easily relaxed. Thanks for the suggested fix. I've pushed a change to allow the underscore char in both field and column names. Best, -- Bastien
Re: [O] Error because org-refile calls org-back-to-heading
Matt Lundin m...@imapmail.org writes: Matt Lundin m...@imapmail.org writes: Since the commit c25165c25dc9fdb5b57b3c66b2e0ec0efdbeb7ad on August 18, I can only call this function when I am beneath the first level heading of an org-mode file. Otherwise I receive the following error: Here's a patch that allows one to call (org-refile t) in a non org-mode buffer without resulting in an error. Applied, thanks! -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, Eric Schulte schulte.e...@gmail.com writes: I'm not sure that it is legal to apply tags to tables, so I'm not sure if this is a bug. I confirm tags are for headlines only. If we want to add more export options to tables, let's use the usual #+[option] syntax -- like #+caption does. -- Bastien
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi András, András Major andras.g.ma...@gmail.com writes: I think that anything that works despite being designed and documented otherwise is confusing to the user and should be considered a bug. I'm happy that it no longer works and hope that it stays that way. I think tags are clearly documented as being properties of the headlines -- if there is places in the manual that we can improve in this respect, please suggest a patch. I don't think it's reasonable to document the fact that tags are not meant to be used in tables, blocks, lists, timestamps, etc. But there are some borderline cases that may happen, and I'm happy to fix the doc in these cases. Also, your question raises again the issue of a full description of Org's (implicit) syntax -- so let's try to make progress on this. Best, -- Bastien
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Michael Brand michael.ch.br...@gmail.com writes: If the shell is a special case for babel anyway, why not something like the following? Ehm, no. But I think that it would be generally useful (not just for shell blocks) to be able to capture stderr, either together with stdout or separately into a result target block and have the return status available as a variable (although that does not work for consecutive invocations in a session). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Bug: named columns in tables not working if name contains _
Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: The only characters permitted are alphanumerics. That can probably be easily relaxed. Hi Nick, I don't think it can be easily relaxed. Many other characters are operators in Calc and would lead to confusion. So perhaps my recent commit is wrong. I did a few tests and found no problem, but I'm certainly not using calc operators that much. Please feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if necessary... But amending the docs is certainly a good idea. ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. Thanks! -- Bastien
Re: [O] Problem with shift-up [solved]
Hi Peter, Peter Frings peter.fri...@agfa.com writes: Yes, I did. I did find the offending command. Hooray! Great -- thanks for sharing! (setq org-replace-disputed-keys t) Was set in the init.el file of the starter-kit. Now, is it just me or is the relation between this variable and ‘org-support-shift-select’ slightly confusing? Mhh... maybe. I need to investigate further. If you have time to investigate on your side, please share your results! Thanks for the patience and the support! You're welcome, Best, -- Bastien
Re: [O] Bug: named columns in tables not working if name contains _
Nick Dokos nicholas.do...@hp.com writes: The only characters permitted are alphanumerics. That can probably be easily relaxed. Only if you don't want to have _underlined_ still working and perhaps never use calc on that table. The problem with simple syntax is that the quoting rules become bizarre and the other way around. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] [babel] [bug] inline src_R breaks downstream src block
Eric Schulte schulte.e...@gmail.com writes: It will probably be a couple of days before I have sufficient time to address these issues, but rest assured it is only my TODO list. Thanks for your persistence in fixing this! -- Bastien
Re: [O] git repository over http?
Jason Dunsmore emacs-orgm...@dunsmor.com writes: Okay -- can you git gc on the server? Okay, done: Great -- thanks a lot! -- Bastien
Re: [O] Bug: named columns in tables not working if name contains _
On 23.8.2011, at 18:20, Bastien wrote: Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: The only characters permitted are alphanumerics. That can probably be easily relaxed. Hi Nick, I don't think it can be easily relaxed. Many other characters are operators in Calc and would lead to confusion. So perhaps my recent commit is wrong. I did a few tests and found no problem, but I'm certainly not using calc operators that much. Please feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if necessary... I'll take a look. - Carsten But amending the docs is certainly a good idea. ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. Thanks! -- Bastien
Re: [O] Bug: Toggle descriptive and literal links [7.4]
Bastien b...@altern.org writes: Hi Thomas, t...@tsdye.com (Thomas S. Dye) writes: Thanks for adding this. I work with literal links and this potentially saves time and effort. I wonder if I'm using it correctly? In .emacs I set org-link-display-descriptive nil and have: org-link-display-descriptive is a variable defined in `org.el'. Its value is nil Documentation: Non-nil means Org will display descriptive links. E.g. [[http://orgmode.org][Org website]] will be displayed as Org Website, hiding the link itself and just displaying its description. When set to `nil', Org will display the full links literally. You can interactively set the value of this variable using the `org-toggle-link-display'. But when I open an Org-mode buffer I find the links displayed descriptively. The initialization of the link display relied on `org-descriptive-links' and I discover this variable (doh!) So I've now remove `org-link-display-descriptive' and use `org-descriptive-links' instead for backward compatibility. Please use this variable too and let me know if things are all right now. Best, Aloha Bastien, I pulled from git and put this in .emacs: (setq org-descriptive-links nil) Now links display as expected on startup. Thanks for looking into this. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Achim Gratz strom...@nexgo.de writes: Michael Brand michael.ch.br...@gmail.com writes: If the shell is a special case for babel anyway, why not something like the following? Ehm, no. But I think that it would be generally useful (not just for shell blocks) to be able to capture stderr, either together with stdout or separately into a result target block and have the return status available as a variable (although that does not work for consecutive invocations in a session). Hmm, I do think that a :results stderr option could be useful, however this would not be a trivial implementation as it may require adjustments to all of the language files. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: babel: results switch (output vs. value) has no or wrong effect for sh source block [7.7 (release_7.7.107.g7a82)]
Michael Brand michael.ch.br...@gmail.com writes:
Hi Eric
2011/8/20 Eric Schulte schulte.e...@gmail.com:
[...] I would lean towards thinking
that passing along error messages is more important than returning error
codes, but if the community thinks differently I'm happy to change the
ob-sh behavior.
A non-zero exit status and stderr of a process are not necessarily
related. Because a process may also use
- a non-zero exit status without error situation (e. g. grep, diff)
- stderr for output not related with errors
- stdout for error messages
I would like very much to be able to collect all available feedback
from a process at the same run. Even with an optional indication of
the origin, for ambiguity like the hello below or just for clarification.
I agree that some mechanism for collecting output from STDERR could be
useful, however its implementation would not be trivial.
Unfortunately it seems that in either case the sh code blocks will need
to be different than other languages either in its handling of errors or
of return values. This is unavoidable due to the overloading of return
values in the shell as error indicators.
If the shell is a special case for babel anyway, why not something
like the following?
#+begin_src sh :exports stdout stderr exit_status -v
echo hello
echo hello 2
false
#+end_src
#+results:
: 2: hello
: 1: hello
: exit status: 1
This would have been
- with an option -v for verbosity to prefix
stdout with 1: , stderr with 2: and the exit status
- with the exit status of the last command without the need of an
extra echo $?.
My habit as a background info: To learn more from the shell I use
- a shell prompt with the exit status of the last command
- when I sometimes want to visually divide stdout and stderr (bash):
{ { echo hello; echo hello 2; } 31 12 23 | sed 's/^/2: /'; } \
31 12 23 | sed 's/^/1: /'; 3-
to output:
2: hello
1: hello
I think that in general mixing the output status with STDOUT would not
be a clean solution, as it would require parsing to use. Also, I don't
think that the example above would help to bring the behavior of sh code
blocks more in-line with other code blocks.
Note that during interactive evaluation if the exit status is non-0 then
STDERR will be dumped into a babel error buffer which will be poped up,
so this information will not be silently discarded.
Best -- Eric
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. Best -- Eric -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] how to add font-lock keywords
Hi all, I wasn't able to google a clear examples of how to do this. For example, I'd like to highlight all text between double-quotes. -- Le
Re: [O] org-odt numbering (Applying custom templates)
sort of hijacking this thread with a quick note: In order to remove numbering from the headings produced by org-odt, simply export a file, go to Tools - Outline Numbering in libreoffice/openoffice, and turn numbering off for levels 1-10 (probalby you only need about 4 levels anyway). Then save the resulting file somewhere safe, customize the variable org-export-odt-styles-file to the path to that file, and you're done. I only write this because I had a little trouble figuring out how outline numbering works in openoffice. It would be pretty cool if the org option num: had an effect here, but I think that would require some work to implement (you'd have to have org override settings in styles.xml, presumably introducing the possibility of various errors).
Re: [O] Bug: named columns in tables not working if name contains _
On 23.8.2011, at 18:20, Bastien wrote: Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: The only characters permitted are alphanumerics. That can probably be easily relaxed. Hi Nick, I don't think it can be easily relaxed. Many other characters are operators in Calc and would lead to confusion. So perhaps my recent commit is wrong. I did a few tests and found no problem, but I'm certainly not using calc operators that much. Please feel free to revert commit 76ab4dd422216ff2c574be4586ba161b8c40704e if necessary... I have checked, underscore is aceptable, calc allows it in variables names. However, I would not recommend adding any more characters to this regexp. - Carsten But amending the docs is certainly a good idea. ... and commit f893659b272ef80c1da8c0420d55b6237a4c3f00 about the doc. Thanks! -- Bastien
[O] Dimming ancestors in the agenda (relevant to indenting nested TODOs in agenda views)
Here is a different solution. It is from my notes from long ago. To me, one issue with indenting is that you expect the previous line to be a direct parent, analogously with the outline. This conflicts with sorting and non-child descendents. If you sort, you can't take advantage of the feature and have it look right. If it's not a direct child, you can't take advantage of it either because you either confusingly indent too much or modify the semantics. Also, indenting interferes with putting as much information on the line as possible. Those with large fonts or small (e.g. mobile) displays value the real estate. === Here is an alternate, which might or might not satisfy the OP's needs tangentially, but might spark discussion in either case. One feature I have long wanted, but have not been able to implement, is to dim (or color) any agenda entry that has a descendant in the same agenda view. === This is a completely different thing from dimming blocked tasks, because it only looks at other tasks in the same view, and doesn't care about todo keywords. The pseudocode is this: loop for i in all headlines in agenda (even a combined agenda) if i has an ancestor in agenda, dim that ancestor Motivation is that sometimes I mark a task as important (or any other tag), and mark its child as important. When I look at the agenda view for important items without inheritance, I am less interested in the parent because there is something important in a descendent. But when B is done, I am interested in A again. I don't want to manipulate tags. I just want to have both there all the time in the agenda, but one dimmed. * deal with company A :important: * call B at company A :important: * call C === Hope this idea helps the OP's indenting need or similar ones. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com I support the Whittemore-Peterson Institute (WPI) === Bigotry against people with serious diseases is still bigotry.
Re: [O] Bug: named columns in tables not working if name contains _
Carsten Dominik carsten.domi...@gmail.com writes: I have checked, underscore is aceptable, calc allows it in variables names. However, I would not recommend adding any more characters to this regexp. Thanks for the quick feedback! -- Bastien
Re: [O] ebib configuration for org-bibtex
Hi Eric, Bastien b...@altern.org writes: I think this fix is causing some mischief. I reverted this commit -- let's wait Eric is back and can fix this with a better solution. Eric -- just making sure this is under your radar. I reverted your fix because it was not answering Thomas' problem, but it looks like your fix is right anyway, though not addressing the issue at hand. Could you have another look? Thanks in advance! -- Bastien
Re: [O] ebib configuration for org-bibtex
Bastien b...@altern.org writes: Hi Eric, Bastien b...@altern.org writes: I think this fix is causing some mischief. I reverted this commit -- let's wait Eric is back and can fix this with a better solution. Eric -- just making sure this is under your radar. Thanks, I had lost track of the end of this thread. I reverted your fix because it was not answering Thomas' problem, but it looks like your fix is right anyway, though not addressing the issue at hand. Could you have another look? I've just reverted your reversion :). I'll take a look at Toms problem (which does appear to be separate) separately. Thanks -- Eric Thanks in advance!
Re: [O] ebib configuration for org-bibtex
t...@tsdye.com (Thomas S. Dye) writes: Eric Schulte schulte.e...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: Aloha all, I'm trying, partially successfully, to configure org-bibtex so it mimics some useful features of ebib. In particular, I'm wanting to add several optional fields that ebib uses. I have this in .emacs: #+begin_src emacs-lisp :tangle yes (dolist (type org-bibtex-types) (push :url (cdr (assoc :optional (cdr type (push :annote (cdr (assoc :optional (cdr type (push :abstract (cdr (assoc :optional (cdr type (push :keywords (cdr (assoc :optional (cdr type (push :file (cdr (assoc :optional (cdr type ) (push (cons :url A URL for the reference) org-bibtex-fields) (push (cons :annote Annotation is typically not exported) org-bibtex-fields) (push (cons :abstract Abstract for annotated bibliography) org-bibtex-fields) (push (cons :keywords Keywords for sorting with ebib) org-bibtex-fields) (push (cons :file A local file path used by ebib to open the reference in an appropriate application) org-bibtex-fields) #+end_src Most of it works fine, but the optional :file field doesn't respect its argument. So, the following entry in the Org-mode file: Hi Tom, The :file property is treated in a special manner when Org-mode resolves properties (notice it is an element of the `org-special-properties' variable). I've just pushed up a change which temporarily removes :file from this list while resolving bibtex entries. This change should fix your reported problem -- please let me know if it doesn't. If any other elements of `org-special-properties' seem likely to cause problems we can temporarily remove them as well. Best -- Eric Hi Eric, I think this fix is causing some mischief. In the Org-mode file where a :FILE: property is set to preza-thesis.pdf R source code blocks misbehave, as follows: #+source: land-sale-plot #+begin_src R :var y=sales str(y) #+end_src #+results: land-sale-plot [[file:preza-thesis.pdf]] Hi Tom, Are you still experiencing the problem mentioned above? I'm unable to reproduce it locally. If so, would you mind trying to recreate the problem with an emacs session launched using emacs -Q to see if the cause lies somewhere in your personal configuration? I *do* have a file header argument for code blocks inside of subtrees which explicitly specify a file property (which can be easily checked using C-c C-v I), e.g., ** inheriting the file property :PROPERTIES: :FILE: something.png :END: #+begin_src ditaa +-+ | | |+-+ | || | +-+| || | | || |+-+ | || | | || | file | || | inheritance +-+| | | +-+ #+end_src #+results: [[file:something.png]] However when I do not specify such a FILE property, then no :file entry is present in the code blocks parameters. Thanks -- Eric
[O] Bug: typo in org-list - point-maker
Commit 08ca5be491f5704cc0c6cb87013a5e8537218488 causes an error because of typo: i.e., point-maker instead of point-marker Best, Matt
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Bastien, I'm not sure I understand -- does it mean that C-cC-c on #+begin_src fails in the example below? No, it means that exporting to HTML fails with that error message. It should actually evaluate the code and include the resulting PNG in the output (and that's what it does when :noexport: isn't present). András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Bastien, I think that anything that works despite being designed and documented otherwise is confusing to the user and should be considered a bug. I'm happy that it no longer works and hope that it stays that way. I think tags are clearly documented as being properties of the headlines -- if there is places in the manual that we can improve in this respect, please suggest a patch. I'm not talking about the manual. In my opinion, if there is a function that works only on headlines according to the manual, then it *must not* work in any other place. Otherwise some users might try the function they once heard of in a sense not specified in the documentation (here: in a table) and see that it works, and be surprised when it no longer does (in a future version of org-mode, or on a different computer). Therefore such ghost features must actively be eliminated. To me, the documentation is the leading specification of a piece of software. Anything the software doesn't do that is in the docs is a bug, but likewise anything it does do which the docs don't cover is also a bug. I don't think it's reasonable to document the fact that tags are not meant to be used in tables, blocks, lists, timestamps, etc. I fully agree. András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Hi Eric, Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. OK, in that case the example still doesn't work for me. Whether I use #+data or #+tblname, specifying the :noexport: tag in the section containing the table causes the HTML export to report the error reference 'table1' not found in this buffer. As Bastien pointed out earlier, I'm not talking about simple evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so far). András
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major andras.g.ma...@gmail.com wrote: Hi Eric, Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. OK, in that case the example still doesn't work for me. Whether I use #+data or #+tblname, specifying the :noexport: tag in the section containing the table causes the HTML export to report the error reference 'table1' not found in this buffer. As Bastien pointed out earlier, I'm not talking about simple evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so far). This is probably caused by org-export-preprocess-string: it does things in a certain order, and it probably kills the :noexport: stuff before it gets to the evaluation of the source block. It might be possible to change the order (ISTR a couple of cases, where behavior was changed by doing exactly this), but it's probably fraught with peril: approach with caution. Nick PS. Warning: the above is a guess: it may have nothing to do with reality.
Re: [O] ebib configuration for org-bibtex
Eric Schulte schulte.e...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: Eric Schulte schulte.e...@gmail.com writes: t...@tsdye.com (Thomas S. Dye) writes: Aloha all, I'm trying, partially successfully, to configure org-bibtex so it mimics some useful features of ebib. In particular, I'm wanting to add several optional fields that ebib uses. I have this in .emacs: #+begin_src emacs-lisp :tangle yes (dolist (type org-bibtex-types) (push :url (cdr (assoc :optional (cdr type (push :annote (cdr (assoc :optional (cdr type (push :abstract (cdr (assoc :optional (cdr type (push :keywords (cdr (assoc :optional (cdr type (push :file (cdr (assoc :optional (cdr type ) (push (cons :url A URL for the reference) org-bibtex-fields) (push (cons :annote Annotation is typically not exported) org-bibtex-fields) (push (cons :abstract Abstract for annotated bibliography) org-bibtex-fields) (push (cons :keywords Keywords for sorting with ebib) org-bibtex-fields) (push (cons :file A local file path used by ebib to open the reference in an appropriate application) org-bibtex-fields) #+end_src Most of it works fine, but the optional :file field doesn't respect its argument. So, the following entry in the Org-mode file: Hi Tom, The :file property is treated in a special manner when Org-mode resolves properties (notice it is an element of the `org-special-properties' variable). I've just pushed up a change which temporarily removes :file from this list while resolving bibtex entries. This change should fix your reported problem -- please let me know if it doesn't. If any other elements of `org-special-properties' seem likely to cause problems we can temporarily remove them as well. Best -- Eric Hi Eric, I think this fix is causing some mischief. In the Org-mode file where a :FILE: property is set to preza-thesis.pdf R source code blocks misbehave, as follows: #+source: land-sale-plot #+begin_src R :var y=sales str(y) #+end_src #+results: land-sale-plot [[file:preza-thesis.pdf]] Hi Tom, Are you still experiencing the problem mentioned above? I'm unable to reproduce it locally. If so, would you mind trying to recreate the problem with an emacs session launched using emacs -Q to see if the cause lies somewhere in your personal configuration? I *do* have a file header argument for code blocks inside of subtrees which explicitly specify a file property (which can be easily checked using C-c C-v I), e.g., ** inheriting the file property :PROPERTIES: :FILE: something.png :END: #+begin_src ditaa +-+ | | |+-+ | || | +-+| || | | || |+-+ | || | | || | file | || | inheritance +-+| | | +-+ #+end_src #+results: [[file:something.png]] However when I do not specify such a FILE property, then no :file entry is present in the code blocks parameters. Thanks -- Eric Hi Eric, I think the confusion leading to my messages has been the cause of some mischief. Apologies for that. The change you implemented to let the :FILE: property work correctly with ebib does what it is supposed to do. It does not cause the mischief that I was experiencing. AFAICT, your re-reversion of the code back into Org-mode was the correct action. I ran into the problem when I tried to include in my reading notes an R graphic for some newly reported data. The R source block was immediately below the bibliographic subheading with the :FILE: property. Babel saw the :FILE: property for the bibliographic subheading and applied that to the R code block, as I now believe it is supposed to do. My confusion came from the fact that I didn't recognize at the time that Babel sees the :FILE: property for the bibliographic subheading the same way it sees the :FILE: property for any other heading. When I move the R code away from the bibliographic subheading it all works as expected, as you note. Again, sorry for my noise, and thanks for your fix for the ebib integration. All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] org-odt numbering (Applying custom templates)
Matt sort of hijacking this thread with a quick note: In order to remove numbering from the headings produced by org-odt, simply export a file, go to Tools - Outline Numbering in libreoffice/openoffice, and turn numbering off for levels 1-10 (probalby you only need about 4 levels anyway). Then save the resulting file somewhere safe, customize the variable org-export-odt-styles-file to the path to that file, and you're done. I only write this because I had a little trouble figuring out how outline numbering works in openoffice. It would be pretty cool if the org option num: had an effect here, but I think that would require some work to implement (you'd have to have org override settings in styles.xml, presumably introducing the possibility of various errors). I have fixed this issue a few minutes ago. If you set num:nil in OPTIONS line, outline numbering will be turned off. Could you please unapply the custom styles and try again. Thanks for reporting this. Jambunathan K.
Re: [O] Not merging org-lparse, org-xhtml org-odt to the core
Detlef Will you take care of org-odt working in orgmode for the foreseeable future or don`t you care about orgmode anymore? I pushed a commit just a few minutes ago. So things are back to normal. Jambunathan K.
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
András Major andras.g.ma...@gmail.com writes: Hi Bastien, I think that anything that works despite being designed and documented otherwise is confusing to the user and should be considered a bug. I'm happy that it no longer works and hope that it stays that way. I think tags are clearly documented as being properties of the headlines -- if there is places in the manual that we can improve in this respect, please suggest a patch. I'm not talking about the manual. In my opinion, if there is a function that works only on headlines according to the manual, then it *must not* work in any other place. Otherwise some users might try the function they once heard of in a sense not specified in the documentation (here: in a table) and see that it works, and be surprised when it no longer does (in a future version of org-mode, or on a different computer). Therefore such ghost features must actively be eliminated. To me, the documentation is the leading specification of a piece of software. Anything the software doesn't do that is in the docs is a bug, but likewise anything it does do which the docs don't cover is also a bug. Aloha Andras, As an avocational programmer who has had the pleasure of making small changes to the Org-mode manual and on-line documentation, this last bit seems to raise the bar impractically high. Part of Org-mode's appeal to me is that people frequently find new, and at least to me unexpected, ways to use it productively. I find it interesting to see how best to change the documentation to incorporate the new discovery. That said, the idea that the docs cover *everything* that Org-mode is capable of doing is wonderful and I'll be happy to chip in when I can to help you achieve that goal. All the best, Tom I don't think it's reasonable to document the fact that tags are not meant to be used in tables, blocks, lists, timestamps, etc. I fully agree. András -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Nick Dokos nicholas.do...@hp.com writes: András Major andras.g.ma...@gmail.com wrote: Hi Eric, Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. OK, in that case the example still doesn't work for me. Whether I use #+data or #+tblname, specifying the :noexport: tag in the section containing the table causes the HTML export to report the error reference 'table1' not found in this buffer. As Bastien pointed out earlier, I'm not talking about simple evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so far). Are you /sure/ that this doesn't work for you? On my system C-c C-e A in the following attached org-mode file (posted earlier in this thread) * top ** not to be exported :noexport: #+data: something | 0 | | 1 | | 1 | | 2 | | 3 | | 5 | | 8 | ** to be exported #+begin_src emacs-lisp :var fib=something :exports results (car (nth 4 fib)) #+end_src Does export and correctly resolves the variable in the :noexport:'d section resulting in the following output. , |noexport | | | Author: Eric Schulte | Date: 2011-08-23 17:37:28 MDT | | | Table of Contents | = | 1 top | 1.1 to be exported | | | 1 top | -- | | 1.1 to be exported | === | | | 3 | ` This is probably caused by org-export-preprocess-string: it does things in a certain order, and it probably kills the :noexport: stuff before it gets to the evaluation of the source block. It might be possible to change the order (ISTR a couple of cases, where behavior was changed by doing exactly this), but it's probably fraught with peril: approach with caution. The above analysis is correct. Babel has to deal with this when resolving header arguments, noweb references and variable expansions. It does this by resolving these things in the original org-mode buffer rather than in the temporary export buffer which is often missing portions which are not to be exported. See the definition of the `org-babel-exp-in-export-file' macro for details. Best -- Eric Nick PS. Warning: the above is a guess: it may have nothing to do with reality. -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [PATCH] Implement history facility for org-occur searches
Hi Bastien and everyone, I wanted to implement a history facility for sparse trees. Since sparse trees use org-occur and org-scan-tags any such facility would need to be aware of both functions. My lisp foo proved to be too weak to understand org-scan-tags, so I implemented this only for org-occur searches. With this patch one can traverse the sparse tree history for date, regular expression and TODO keyword searches with the org-occur-history-forward and org-occur-history-backward functions. One can also call the org-occur-history-next function interactively to jump to the nth history entry. This should also work for any other searches that uses org-occur as the backend. Please feel free to modify the patch if there are better ways to implement this facility. Thank you. -- Suvayu Open source is the future. It sets us free. From 11c36f42d1471629fd783aaf1db4aaf3d1d01ef6 Mon Sep 17 00:00:00 2001 From: Suvayu Ali fatkasuvayu+li...@gmail.com Date: Tue, 23 Aug 2011 14:25:08 +0200 Subject: [PATCH] Implement history facility for org-occur searches Changed function: * org.el (org-occur): Add history functionality and corresponding documentation New functions: * org.el (org-occur-history-next): Function for history traversal (org-occur-history-forward) and (org-occur-history-backward): User funtions for moving forward and backward in search history New variables: * org.el (org-occur-match-history): Search history variable (org-occur-match-history-len): Search history size --- lisp/org.el | 65 +- 1 files changed, 63 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index bbc6a75..d419a04 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -12294,6 +12294,15 @@ (defvar org-occur-parameters nil as well.) (make-variable-buffer-local 'org-occur-parameters) + Org occur history variables +(defvar org-occur-match-history nil + History list of `org-occur' searches.) +(make-variable-buffer-local 'org-occur-match-history) +(defcustom org-occur-match-history-len 10 + Length of `org-occur-match-history'. + :type 'integer + :group 'org) + (defun org-occur (regexp optional keep-previous callback) Make a compact tree which shows all matches of REGEXP. The tree will show the lines where the regexp matches, and all higher @@ -12303,7 +12312,15 @@ (defun org-occur (regexp optional keep-previous callback) call to `org-occur' will be kept, to allow stacking of calls to this command. If CALLBACK is non-nil, it is a function which is called to confirm -that the match should indeed be shown. +that the match should indeed be shown. + +The org-occur search history is stored in the variable +`org-occur-match-history'. The length of the history is determined by the +variable `org-occur-match-history-len'. The function +`org-occur-history-next' can be used to traverse the org-occur history. +Two user functions `org-occur-history-forward' and +`org-occur-history-backward' are provided to conveniently traverse the +org-occur history one step at a time. (interactive sRegexp: \nP) (when (equal regexp ) (error Regexp cannot be empty)) @@ -12322,7 +12339,17 @@ (defun org-occur (regexp optional keep-previous callback) (save-match-data (funcall callback))) (setq cnt (1+ cnt)) (when org-highlight-sparse-tree-matches - (org-highlight-new-match (match-beginning 0) (match-end 0))) + (org-highlight-new-match (match-beginning 0) (match-end 0)) + ;; remove duplicate element + (setq org-occur-match-history + (delete regexp org-occur-match-history)) + ;; add last search at the front + (add-to-list 'org-occur-match-history regexp) + ;; curtail history to max history length + (if (eq org-occur-match-history-len + (length org-occur-match-history)) + (setq org-occur-match-history + (butlast org-occur-match-history (org-show-context 'occur-tree (when org-remove-highlights-with-change (org-add-hook 'before-change-functions 'org-remove-occur-highlights @@ -12360,6 +12387,40 @@ (defun org-occur-next-match (optional n reset) (goto-char p1) (error No more matches +(defun org-occur-history-next (steps) +Traverse org occur history by STEPS steps in the forward direction +with respect to the current position. The search history is saved after +removing any duplicate searches. It is reordered to reflect the most +recent search. Before traversing the history the following transformation +is applied: STEPS MODULO `org-occur-match-history-len'. + +For negative STEPS, history traversal is done in the backward direction +starting at the end of the history list. When called interactively it +prompts for the number of steps. +(interactive NSteps: ) +(let (match) + (if ( steps 0) + (setq match + (car (last org-occur-match-history + (mod (- steps) org-occur-match-history-len + (setq match (nth (mod steps
Re: [O] Bug: typo in org-list - point-maker
Hello, Matt Lundin m...@imapmail.org writes: Commit 08ca5be491f5704cc0c6cb87013a5e8537218488 causes an error because of typo: i.e., point-maker instead of point-marker Fixed, thanks. -- Nicolas Goaziou
Re: [O] Bug: :noexport: tag prevents table functioning as babel code block input [7.7 (release_7.7.167.gfceb)]
Eric Schulte schulte.e...@gmail.com writes: Nick Dokos nicholas.do...@hp.com writes: András Major andras.g.ma...@gmail.com wrote: Hi Eric, Your file uses #+data: where I use #+tblname: -- which one is the official one? I have the impression that it's #+data:, but I haven't come across that in the manual or elsewhere before. If #+tblname: isn't supposed to be used as a target for a variable in the code block, then we should make sure that it *never* behaves as such. In the interest of backwards compatibility and convenience there are a number of equivalent options here, see the value of the `org-babel-data-names' variable for all possible names. OK, in that case the example still doesn't work for me. Whether I use #+data or #+tblname, specifying the :noexport: tag in the section containing the table causes the HTML export to report the error reference 'table1' not found in this buffer. As Bastien pointed out earlier, I'm not talking about simple evaluation (C-cC-c) but, specifically, export (HTML and PDF tried so far). Are you /sure/ that this doesn't work for you? On my system C-c C-e A in the following attached org-mode file (posted earlier in this thread) * top ** not to be exported :noexport: #+data: something | 0 | | 1 | | 1 | | 2 | | 3 | | 5 | | 8 | Hi Eric, Your example works here, too. It fails, however, if there is an empty line between #+data: something and the first row of the table. Then a listp, nil error is raised. Perhaps this is what Andras is seeing? I haven't gone back to take a specific look at the manual, but in the past I've thought that the documentation of table naming isn't as good as it might be. In fact, I often have a hard time finding it in the first place :) hth, Tom ** to be exported #+begin_src emacs-lisp :var fib=something :exports results (car (nth 4 fib)) #+end_src Does export and correctly resolves the variable in the :noexport:'d section resulting in the following output. , |noexport | | | Author: Eric Schulte | Date: 2011-08-23 17:37:28 MDT | | | Table of Contents | = | 1 top | 1.1 to be exported | | | 1 top | -- | | 1.1 to be exported | === | | | 3 | ` This is probably caused by org-export-preprocess-string: it does things in a certain order, and it probably kills the :noexport: stuff before it gets to the evaluation of the source block. It might be possible to change the order (ISTR a couple of cases, where behavior was changed by doing exactly this), but it's probably fraught with peril: approach with caution. The above analysis is correct. Babel has to deal with this when resolving header arguments, noweb references and variable expansions. It does this by resolving these things in the original org-mode buffer rather than in the temporary export buffer which is often missing portions which are not to be exported. See the definition of the `org-babel-exp-in-export-file' macro for details. Best -- Eric Nick PS. Warning: the above is a guess: it may have nothing to do with reality. -- Thomas S. Dye http://www.tsdye.com
Re: [O] Not merging org-lparse, org-xhtml org-odt to the core
I personally would really like to see important contribution such as yours become more and more integrated into the 'standard' Org ditribution - and not pushed further away. Precisely my point. Bastien's idea of merge is to make it into a long drawn affair. I disagree. Jambunathan K. --
Re: [O] how to add font-lock keywords
Le Wang l26w...@gmail.com writes: I wasn't able to google a clear examples of how to do this. For example, I'd like to highlight all text between double-quotes. Typically it looks something like this: (font-lock-add-keywords org-mode (list (list (concat \\(\[^\]+\\\)) 1 highlight-face t))) Where `highlight-face' is the face you'd like to use. The regexp doesn't handle cases where \ legitimately occurs in a string, either. The part between the \\(\\) is what gets colorized. John
Re: [O] Not merging org-lparse, org-xhtml org-odt to the core
Precisely my point. Bastien's idea of merge is to make it into a long drawn affair. I disagree. It would help if you or Bastien could explain what is going on. As is clear, everyone is hoping that the issues will be resolved and your valuable contributions will remain a part of org-mode. It does seem that you are, for now, letting them be within org-mode (your other mail). But it would still help if you express your apprehensions and discuss them openly on this list. Vikas
Re: [O] how to add font-lock keywords
John Wiegley jwieg...@gmail.com writes: Le Wang l26w...@gmail.com writes: I wasn't able to google a clear examples of how to do this. For example, I'd like to highlight all text between double-quotes. Typically it looks something like this: (font-lock-add-keywords org-mode [...] Sorry, that should be 'org-mode, to name the symbol, not attempt to use its value. John
Re: [O] how to add font-lock keywords
Thanks for the hint, I tried this, but all my beautiful salad bowl colours went away. (font-lock-add-keywords 'org-mode '((\\\(\\(?:.\\|\n\\)*?[^\\]\\)\ 0 font-lock-string-face))) Notice that I made a bad attempt to handle escaped quotation mark in the string. Does anyone know a better solution to handle escaped characters in font-lock? On Wed, Aug 24, 2011 at 9:17 AM, John Wiegley jwieg...@gmail.com wrote: John Wiegley jwieg...@gmail.com writes: Le Wang l26w...@gmail.com writes: I wasn't able to google a clear examples of how to do this. For example, I'd like to highlight all text between double-quotes. Typically it looks something like this: (font-lock-add-keywords org-mode [...] Sorry, that should be 'org-mode, to name the symbol, not attempt to use its value. John -- Le
