Re: [O] Function to return content of item

[John Kitchin]

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

[Richard Parsons]

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/)]

[Derek Feichtinger]

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 Meyer]

Kyle Meyer  writes:

> 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/)]

[Nick Guiffrida]

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/)]

[Nicolas Goaziou]

Hello,

Bruno BEAUFILS  writes:

> 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

[Thierry Banel]

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

[Kyle Meyer]

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.

> 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/)]

[Bruno BEAUFILS]

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

[Achim Gratz]

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

[Nicolas Goaziou]

Hello,

Eric S Fraga  writes:

> 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

[Nicolas Goaziou]

Hello,

Achim Gratz  writes:

> 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

[Nicolas Goaziou]

Hello,

Kyle Meyer  writes:

> 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/)]

[Nicolas Goaziou]

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] About org-sort -> org-sort-list with custom sort function

[Nicolas Goaziou]

Hello,

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.

>> 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