Re: [O] Function to return content of item
I don't know of a function. Something like this may be what you want. not all elements have :contents-begin though (let ((el (org-element-context))) (buffer-substring-no-properties (org-element-property :contents-begin el) (org-element-property :contents-end el))) It also a little tricky to figure out what to do about subheadings. Do they count as content or not? Richard Parsons writes: > Hi there > > Is there a function that will give me the content of the current item? I > mean simply the text of the whole item without its heading or properties > drawer. > > It seems to me likely that such a function would exist, but I haven't been > able to find it in the documentation. > > Many thanks > Richard -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
[O] Function to return content of item
Hi there Is there a function that will give me the content of the current item? I mean simply the text of the whole item without its heading or properties drawer. It seems to me likely that such a function would exist, but I haven't been able to find it in the documentation. Many thanks Richard
[O] Bug: org-babel-expand-src-block expands sh blocks independent of shell defined by src block [9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/)]
Hi When using =org-babel-expand-src-block= with a shell src block one always gets the same code expansion (in my case bash) independent of the shell that is used while the execution of the shell block uses the correct expansion. I define the following table to illustrate the problem: #+NAME: tbltest | col1 | col2 | col3 | | 11 | 12 | 13 | | 21 | 22 | 23 | | 31 | 32 | 33 | Now for the example source block where I read in the table #+BEGIN_SRC sh :results value :exports both :var tbl=tbltest :colnames yes echo $tbl #+END_SRC When expanding the sh source block above with =org-babel-expand-src-block= it is wrongly expanded to the bash expansion and not to the sh expansion that is used when the block is executed. So, instead of the sh expansion, tbl='111213 212223 313233' I see the following bash related expansion in the opened buffer: #+BEGIN_EXAMPLE unset tbl declare -A tbl tbl['11']='12 13' tbl['21']='22 23' tbl['31']='32 33' echo $tbl #+END_EXAMPLE Reason: The case distinction in =org-babel-variable-assignments:shell= is made based on the shell-file-name which is a standard emacs variable set by emacs in C code. This is pointing to "/bin/bash" for my installation. #+BEGIN_SRC elisp :exports source (defun org-babel-variable-assignments:shell (params) "Return list of shell statements assigning the block's variables." (let ((sep (cdr (assq :separator params))) (hline (when (string= "yes" (cdr (assq :hlines params))) (or (cdr (assq :hline-string params)) "hline" (mapcar (lambda (pair) (if (string-suffix-p "bash" shell-file-name) (org-babel--variable-assignments:bash (car pair) (cdr pair) sep hline) (org-babel--variable-assignments:sh-generic (car pair) (cdr pair) sep hline))) (org-babel--get-vars params #+END_SRC Looking at the calls stack for the case where we execute the source block and where we just expand it, we see the following call stack for execution #+BEGIN_EXAMPLE org-babel-variable-assignments:shell org-babel-execute:shell org-babel-execute:sh org-babel-execute-src-block #+END_EXAMPLE while in the case of just expanding the source block we have #+BEGIN_EXAMPLE org-babel-variable-assignments:sh org-babel-expand-src-block #+END_EXAMPLE Note that =org-babel-variable-assignments:sh= is an alias for =org-babel-variable-assignments:shell=. A bit of investigation shows that for all shell languages there are aliases defined that finally call =org-babel-execute:shell=. This is set up in the =org-babel-shell-initialize= function. And it is set up in a way that =shell-file-name= is overridden by the name of the particular shell, and this then leads to the correct case distinction using =shell-file-name= in =org-babel-variable-assignments:shell=. #+BEGIN_SRC elisp :exports source (defun org-babel-shell-initialize () "Define execution functions associated to shell names. This function has to be called whenever `org-babel-shell-names' is modified outside the Customize interface." (interactive) (dolist (name org-babel-shell-names) (eval `(defun ,(intern (concat "org-babel-execute:" name)) (body params) ,(format "Execute a block of %s commands with Babel." name) (let ((shell-file-name ,name)) (org-babel-execute:shell body params (eval `(defalias ',(intern (concat "org-babel-variable-assignments:" name)) 'org-babel-variable-assignments:shell ,(format "Return list of %s statements assigning to the block's \ variables." name) #+END_SRC The same kind of overriding would have to be in place when =org-babel-expand-src-block= calls =org-babel-variable-assignments:shell= in the simple code expansion case. But that would be a bit hacky since the generic =org-babel-expand-src-block= function should not override variables needed in just one subclass of backends. It would be cleaner to have different functions =org-babel-variable-assignments:XXX= for the different shells. Emacs : GNU Emacs 25.2.3 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2017-04-25 Package: Org mode version 9.0.5 (9.0.5-elpaplus @ ~/.emacs.d/elpa/org-plus-contrib-20170210/) -- Paul Scherrer Institut Dr. Derek Feichtinger Phone: +41 56 310 47 33 Section Head Science-IT Email: derek.feichtin...@psi.ch Building/Room No. WHGA/U126 CH-5232 Villigen PSI
Re: [O] About org-sort -> org-sort-list with custom sort function
Kyle Meyerwrites: > Nicolas Goaziou writes: > >> Kyle Meyer writes: >> >>> I'm a bit confused about why org-call-with-arg is necessary because I >>> think call-interactively already propagates the current prefix argument, >>> but perhaps I'm missing some subtlety here. Either way ... >> >> I thought the same. I think we can replace `org-call-with-arg' with >> `call-interactively' in master. > > OK, I'll have a closer look at which org-call-with-arg calls are > unnecessary. Grepping around, it looks like org-sort is the only place that uses org-call-with-arg to send the argument through untouched. Though, on second thought, using org-call-with-arg here rather than call-interactively means that * the byte-compiler doesn't warn about WITH-CASE being unused. (I think marking it with an underscore would be confusing because it is "used".) * WITH-CASE isn't ignored when passed by a Lisp caller. -- Kyle
Re: [O] Bug: Properties do not show up in clock table [9.0.6 (9.0.6-elpa @ /home/nick/.emacs.d/elpa/org-20170502/)]
Thank you Nicholas, when I get a chance I'll try that. On May 7, 2017 3:01 AM, "Nicolas Goaziou"wrote: > Hello, > > Nick Guiffrida writes: > > > Below is content which that can be used to reproduce my problem: > > > > * Job1 > >> :PROPERTIES: > >> :job-number: 123457 > >> :END: > >> :LOGBOOK: > >> CLOCK: [2017-05-06 Sat 18:59]--[2017-05-06 Sat 19:30] => 0:31 > >> :END: > >> #+BEGIN: clocktable :maxlevel 2 :scope file :properties ("job-number") > >> #+CAPTION: Clock summary at [2017-05-06 Sat 19:54] > >> | job-number | Headline | Time | | > >> |+--++-| > >> || *Total time* | *0:31* | 0.0 | > >> |+--++-| > >> || Job1 | 0:31 | 0.0 | > >> #+TBLFM: $4='(org-clock-time% @2$2 $2..$3);%.1f > >> #+END: > >> > > > > You can see that the 'job-number' property is not in the clock table. > > The bug doesn't appear in master (i.e., development branch). You may > want to test it or wait for Org 9.1 to be released. > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Bug: Infinite loop using macros [9.0.3 (9.0.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]
Hello, Bruno BEAUFILSwrites: > This simple file makes Emacs loops and freeze when trying to export it. > > #+MACRO: test {{{test}}} > {{{test}}} This was fixed some time ago. Exporting this document should raise an error. You may want to update Org. Regards, -- Nicolas Goaziou
[O] [PATCH] small bug in Babel GnuPlot on % character
Here is a patch for a small bug in Babel GnuPlot. When GnuPlot outputs a message containing a % character, Emacs mis-interprets it. This happens when using commands such as print or fit. Example showing the bug: #+BEGIN_SRC gnuplot :file x.svg :session none print "hello %s\n" plot x #+END_SRC [PATCH] ob-gnuplot: escape % character in output lisp/ob-gnuplot.el (org-babel-execute:gnuplot): escape % percent character in output messages coming from GnuPlot --- lisp/ob-gnuplot.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ob-gnuplot.el b/lisp/ob-gnuplot.el index a62303f..400823b 100644 --- a/lisp/ob-gnuplot.el +++ b/lisp/ob-gnuplot.el @@ -187,7 +187,7 @@ This function is called by `org-babel-execute-src-block'." script-file (if (member system-type '(cygwin windows-nt ms-dos)) t nil) -(message output)) +(message "%s" output)) (with-temp-buffer (insert (concat body "\n")) (gnuplot-mode) -- 2.1.4
Re: [O] About org-sort -> org-sort-list with custom sort function
Nicolas Goaziouwrites: > Kyle Meyer writes: > >> I'm a bit confused about why org-call-with-arg is necessary because I >> think call-interactively already propagates the current prefix argument, >> but perhaps I'm missing some subtlety here. Either way ... > > I thought the same. I think we can replace `org-call-with-arg' with > `call-interactively' in master. OK, I'll have a closer look at which org-call-with-arg calls are unnecessary. > Actually, there's some confusion in `org-sort-list' about how > getkey-func and compare-func are handled. For example, the question > asked to bind GETKEY-FUNC is "Sort using function: ", which should > really be asked for COMPARE-FUNC. > > IOW, we need to move this question to COMPARE-FUNC and ask a new one for > GETKEY-FUNC. True, at the very least, the prompt is confusingly phrased, but it's probably an indication that the intended interface wasn't fully implemented. >> And I think it's OK to not expose compare-func to the interactive >> caller. In cases where sort-subr's default behavior won't do and a user >> wants to supply a value for compare-func, they can create their own >> command that wraps a non-interactive org-sort-list call. > > I disagree. getkey-func and compare-func work hand in hand. You cannot > let users provide one but not the other without crippling functionality. The interactive caller is certainly losing functionality, but my guess was that sort-subr's default behavior is sufficient for handling the keys returned by most custom key functions. Probably a bad guess. -- Kyle
[O] Bug: Infinite loop using macros [9.0.3 (9.0.3-dist @ /usr/share/emacs24/site-lisp/org-mode/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. This simple file makes Emacs loops and freeze when trying to export it. #+MACRO: test {{{test}}} {{{test}}} I can concieve that no simple solution could be find. In pandoc a recursion limit will be implemented (see https://github.com/jgm/pandoc/issues/3401). At least, maybe a warning about such a behavior should be added to the manual. Emacs : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.7) of 2017-01-22 on trouble, modified by Debian Package: Org mode version 9.0.3 (9.0.3-dist @ /usr/share/emacs24/site-lisp/org-mode/) -- Bruno BEAUFILS signature.asc Description: PGP signature
Re: [O] More clocktable breakage
Nicolas Goaziou writes: > OK. I inserted it in a fresh Org buffer. Is there any command to call on > it now? Yes, put the cursor on the date or time of one of the timestamps and press S-Up or S-Down. It should increase or decrease the corresponding element of the timestamp, but instead you'll get an error message: org-clocktable-shift: Line needs a :block definition before this command works which appears because the timestamp wasn't recognized and the fallthrough of org-shift* then tries to apply another function that deals with the :block argument (which isn't present here and shouldn't be). >> Sometimes org-element-context recognizes the clocktable as a paragraph >> instead of dynamic-block > > FWIW, I get `dynamic-block'. OK, then that should get you the same error. >> (I've not yet figured out why and it isn't vary reproducible, but it >> must have something to do with the cache since it goes away when >> I reload the file) > > It is possible, indeed. You can also use M-x org-element-cache-reload to > check this. However, cache is disabled by default, so the problem > shouldn't appear in normal usage. I have not enabled any cache that I know of. All I can say is that sometimes the clocktable doesn't get recognized as dynamic-block but a paragraph instead. That re-enables the recognition of the timestamp incidentally (why exactly I don't really understand), which was why I couldn't reproduce the error at home for some time. > I start to think that there is no bug in clock tables (but certainly in > the cache mechanism, probably related to some `before-change-functions' > and `after-change-functions' misuse there). I'm not using any of those unless they already come with Emacs or Org. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] 9.0.6 and clock tables
Hello, Eric S Fragawrites: > Just a quick note: I upgraded to v9.0.6 and my clock table reports no > longer show %age time spend on each activity. I've not had a chance to > debug this yet but clock tables generated earlier today had percentages > where I wanted them. > > I'll debug tomorrow but I thought I'd bring this up now just in case > anybody else runs into this problem. Would you happen to have any news on it? BTW, you may need to remove any TBLFM: entry related to % since this is no longer necessary when using :formula %. Regards, -- Nicolas Goaziou
Re: [O] More clocktable breakage
Hello, Achim Gratzwrites: > I've told you from the beginning that it was a file at work and that it > would take some time to dig down to the problem since it did work at > home when I tried to create said ECM. I know, but I was hoping a few weeks would be enough, since the resolution of the issue was stalled. > After a few false starts (thinking that it was Windows vs. Linux and > the local configurations on each side) I've finally converged to this > (just insert a new clocktable, then replace the default parameters > with tstart/tend): > > #+BEGIN: clocktable :tstart "<2017-03-24 Fri 00:00>" :tend "<2017-04-23 Sat > 23:45>" > #+CAPTION: Clock summary at [2017-05-06 Sat 11:09] > | L | Headline | Time | | > |---+--++---| > | | *Total time* | *0:00* | | > #+END: OK. I inserted it in a fresh Org buffer. Is there any command to call on it now? > Sometimes org-element-context recognizes the clocktable as a paragraph > instead of dynamic-block FWIW, I get `dynamic-block'. > (I've not yet figured out why and it isn't vary reproducible, but it > must have something to do with the cache since it goes away when > I reload the file) It is possible, indeed. You can also use M-x org-element-cache-reload to check this. However, cache is disabled by default, so the problem shouldn't appear in normal usage. I start to think that there is no bug in clock tables (but certainly in the cache mechanism, probably related to some `before-change-functions' and `after-change-functions' misuse there). WDYT? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] ORG-NEWS: Update new features
Hello, Kyle Meyerwrites: > Sebastian Reuße writes: > >> --- >> etc/ORG-NEWS | 5 + >> 1 file changed, 5 insertions(+) > > Thanks. Applied. BTW, would you mind adding some tests about it in "test-org.el"? Or, at least, provide some simple test cases we can turn into proper tests? Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: Properties do not show up in clock table [9.0.6 (9.0.6-elpa @ /home/nick/.emacs.d/elpa/org-20170502/)]
Hello, Nick Guiffridawrites: > Below is content which that can be used to reproduce my problem: > > * Job1 >> :PROPERTIES: >> :job-number: 123457 >> :END: >> :LOGBOOK: >> CLOCK: [2017-05-06 Sat 18:59]--[2017-05-06 Sat 19:30] => 0:31 >> :END: >> #+BEGIN: clocktable :maxlevel 2 :scope file :properties ("job-number") >> #+CAPTION: Clock summary at [2017-05-06 Sat 19:54] >> | job-number | Headline | Time | | >> |+--++-| >> || *Total time* | *0:31* | 0.0 | >> |+--++-| >> || Job1 | 0:31 | 0.0 | >> #+TBLFM: $4='(org-clock-time% @2$2 $2..$3);%.1f >> #+END: >> > > You can see that the 'job-number' property is not in the clock table. The bug doesn't appear in master (i.e., development branch). You may want to test it or wait for Org 9.1 to be released. Regards, -- Nicolas Goaziou
Re: [O] About org-sort -> org-sort-list with custom sort function
Hello, Kyle Meyerwrites: > I'm a bit confused about why org-call-with-arg is necessary because I > think call-interactively already propagates the current prefix argument, > but perhaps I'm missing some subtlety here. Either way ... I thought the same. I think we can replace `org-call-with-arg' with `call-interactively' in master. >> The problem is that if you choose ?f (sorting with custom key function), >> then org-sort-list expects another argument, the compare-func, which is >> not passed to it. >> >> IMHO, there are two ways to solve this >> >> 1. Ask for the compare-func in org-sort-list, as it does for the >>getkey-func. A default value could be provided for compare-func, >>e.g., string<, <, etc. Or >> 2. Restrict the return type to a string (or integer) so that we could >>fix the compare-func I'd rather have 1. Actually, there's some confusion in `org-sort-list' about how getkey-func and compare-func are handled. For example, the question asked to bind GETKEY-FUNC is "Sort using function: ", which should really be asked for COMPARE-FUNC. IOW, we need to move this question to COMPARE-FUNC and ask a new one for GETKEY-FUNC. > And I think it's OK to not expose compare-func to the interactive > caller. In cases where sort-subr's default behavior won't do and a user > wants to supply a value for compare-func, they can create their own > command that wraps a non-interactive org-sort-list call. I disagree. getkey-func and compare-func work hand in hand. You cannot let users provide one but not the other without crippling functionality. Regards, -- Nicolas Goaziou