Subtree export problems

Subtree export problems

[Thomas S. Dye]

Aloha all,

The following ECM gives me two problems.

1) When I export the full file, all is well, I get this pertinent part:

,------------------------------------------
| \section{Top Level Headline}             
| \label{sec:orgheadline2}                 
| \setmarginnotefont{\itshape\footnotesize}
|                                          
| \subsection{Second Level Headline}       
| \label{sec:orgheadline1}                 
|                                          
| \setmarginnotefont{\itshape\footnotesize}
`------------------------------------------

However, when I attempt to export the Second Level Headline subtree, I
get this pertinent part:

,------------------------
| \setmarginnotefont{nil}
`------------------------

2) Subtree export doesn't work when the Second Level Headline is
followed on the next line by the #+header: line (with no empty line or
some text between them).  I'm left in the *Org Export Dispatcher*, where
I can get out with C-g.

Org-mode version 8.3.3 (release_8.3.3-449-gd85ff3 @
/Users/dk/.emacs.d/src/org-mode/lisp/)

Here is the ECM:

#+MARGIN-NOTE-FONT: \itshape\footnotesize
#+SELECT_TAGS: export
#+EXCLUDE_TAGS: noexport

* Top Level Headline
#+header: :var marginnote-font=(jk-org-kwd "MARGIN-NOTE-FONT")
#+header: :results raw :exports results
#+begin_src emacs-lisp
(format "\\setmarginnotefont{%s}" marginnote-font)
#+end_src

** Second Level Headline
#+header: :var marginnote-font=(jk-org-kwd "MARGIN-NOTE-FONT")
#+header: :results raw :exports results
#+begin_src emacs-lisp
(format "\\setmarginnotefont{%s}" marginnote-font)
#+end_src

* Access keyword values                                            :noexport:

#+name: jk-keywords
#+header: :results silent
#+begin_src emacs-lisp
(defun jk-org-kwds ()
  "parse the buffer and return a cons list of (property . value)
from lines like: #+PROPERTY: value"
  (org-element-map (org-element-parse-buffer 'element) '(keyword node-property)
                   (lambda (keyword) (cons (org-element-property :key keyword)
                                           (org-element-property :value keyword)))))

(defun jk-org-kwd (KEYWORD)
  "get the value of a KEYWORD in the form of #+KEYWORD: value"
  (cdr (assoc KEYWORD (jk-org-kwds))))
#+end_src



-- 
Thomas S. Dye
http://www.tsdye.com

Re: Subtree export problems

[Rasmus]

Hi Tom,

Thanks for your report.

Thomas S. Dye <tsd@tsdye.com> writes:

> The following ECM gives me two problems. 

Next time it would help the reading flow if you start with the 
example (IMO, so if you disagree please ignore).
 
> 1) When I export the full file, all is well, I get this 
> pertinent part: 
> 
> ,------------------------------------------ | \section{Top Level 
> Headline}              | \label{sec:orgheadline2} 
> | \setmarginnotefont{\itshape\footnotesize} | 
> | \subsection{Second Level Headline}        | 
> \label{sec:orgheadline1}                  | 
> | \setmarginnotefont{\itshape\footnotesize} 
> `------------------------------------------ 
> 
> However, when I attempt to export the Second Level Headline 
> subtree, I get this pertinent part: 
> 
> ,------------------------ | \setmarginnotefont{nil} 
> `------------------------ 

How could it do anything else?  Try to narrow to the subtree and 
run your code (see also org-export-as and how subtree export 
works; it narrows).  You will see that your code returns nil.

You are using a hack to use something that you think looks like a 
Org keyword, but which is not (in particular it’s unknown to ox 
backends).  I think you can check org-export-get-environment and 
org-export-define-backend to appreciate this.

 
> 2) Subtree export doesn't work when the Second Level Headline is 
> followed on the next line by the #+header: line (with no empty 
> line or some text between them).  I'm left in the *Org Export 
> Dispatcher*, where I can get out with C-g. 

Aside: I had a hard time understanding this, but I can reproduce 
the bug with this

    ** Second Level Headline #+header: :var 
    marginnote-font=(jk-org-kwd "MARGIN-NOTE-FONT") #+header: 
    :results raw :exports results #+begin_src emacs-lisp (format 
    "\\setmarginnotefont{%s}" marginnote-font) #+end_src 

I’m pretty sure you more well-versed in debugging than me Tom, but 
I will include the following for other people who might follow the 
thread: To see what it going on here it helps to do M-x 
toggle-debug-on-quit and hit C-g.  It will pop up a backtrace.

I am honestly not sure if this if there’s a bug here.  What seems 
to happen is that it keeps looking for a value for marginnote-font 
which is nil cf. above.  But it could also be that your jk-org-kwd 
function is simply malfunctioning cf. below.  Why does this not 
happen when you have plenty of newlines?  I don’t know.  Maybe 
Aaron will be able to tell us if it’s a bug.

In any case, you can fix the second case by redefining your 
function to never return nil.

 (defun jk-org-kwd (KEYWORD) 
   "get the value of a KEYWORD in the form of #+KEYWORD: value" 
   (or (cdr (assoc KEYWORD (jk-org-kwds))) "")) 

Hope it helps even if I’m unable to give an definite answer 
regarding your second observation.

Rasmus

-- 
Need more coffee. . .

Re: Subtree export problems

[Aaron Ecay]

Hi Thomas, hi Rasmus,

2016ko otsailak 6an, Rasmus-ek idatzi zuen:

[...]


> I am honestly not sure if this if there’s a bug here.  What seems 
> to happen is that it keeps looking for a value for marginnote-font 
> which is nil cf. above.  But it could also be that your jk-org-kwd 
> function is simply malfunctioning cf. below.  Why does this not 
> happen when you have plenty of newlines?  I don’t know.  Maybe 
> Aaron will be able to tell us if it’s a bug.

The issue was that org-babel-get-src-block-info would infloop when
#+header is the first line of the (narrowed) buffer.  That should be
fixed in 825ce04b on maint.

I’m a bit fuzzy on the development practices these days...should I now
merge maint to master in order to get the fix there as well?  Or is
there some other arrangement for that?

Aaron

PS Tom, the approach you are using to this looks rather convoluted.
Instead of a src block + keyword thing, why not just use #+latex (or
#+latex_header) to insert the code you need?

-- 
Aaron Ecay

Re: Subtree export problems

[Rasmus]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> I’m a bit fuzzy on the development practices these days...should 
> I now merge maint to master in order to get the fix there as 
> well?  Or is there some other arrangement for that? 

Thanks for fixing this!

Yeah, please merge maint back into master.  That's it.  Here’s a 
recent example:

      http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=aee808987da50fbf44fb762519914ae6bd458876

Cheers,
Rasmus

-- 
A clever person solves a problem. A wise person avoids it

Re: Subtree export problems

[Thomas S. Dye]

Aloha Rasmus,

Thanks for your help.

Rasmus <rasmus@gmx.us> writes:

>> However, when I attempt to export the Second Level Headline 
>> subtree, I get this pertinent part: 
>> 
>> ,------------------------ | \setmarginnotefont{nil} 
>> `------------------------ 
>
> How could it do anything else?  Try to narrow to the subtree and 
> run your code (see also org-export-as and how subtree export 
> works; it narrows).  You will see that your code returns nil.

Interesting, thanks, that makes sense.  So, IIUC narrowing puts the
"keywords" at the top of the buffer out of scope.  I fiddled around a
bit and came up with this, which seems to work:

,-----------------------------------------
| ** Second Level Headline                
| :PROPERTIES:                            
| :MARGIN-NOTE-FONT: \itshape\footnotesize
| :END:                                   
`-----------------------------------------

> You are using a hack to use something that you think looks like a 
> Org keyword, but which is not (in particular it’s unknown to ox 
> backends).  I think you can check org-export-get-environment and 
> org-export-define-backend to appreciate this.

Am I right that what John Kitchin's code (jk-org-kwd) refers to as
"keyword" should be called "property" instead?  This makes more sense to
me in light of the above.

Also, I don't understand what you mean by "hack".  Should I be wary of
using John's functions?  I find them handy to mark bits of information
that the user (usually me) might want to change.  They save the need to
rummage around a long document to find where the information is actually
used.  Should I use other functions instead?

> In any case, you can fix the second case by redefining your 
> function to never return nil.
>
>  (defun jk-org-kwd (KEYWORD) 
>    "get the value of a KEYWORD in the form of #+KEYWORD: value" 
>    (or (cdr (assoc KEYWORD (jk-org-kwds))) "")) 

This didn't work for me.  Subtree export of this one still fails:

,---------------------------------------------------------------
| ** Second Level Headline                                      
| #+header: :var marginnote-font=(jk-org-kwd "MARGIN-NOTE-FONT")
| #+header: :results raw :exports results                       
| #+begin_src emacs-lisp                                        
| (format "\\setmarginnotefont{%s}" marginnote-font)            
| #+end_src                                                     
`---------------------------------------------------------------

But subtree export of this one succeeds, albeit with an empty argument
to \setmarginnotefont{} because the MARGIN-NOTE-FONT property wasn't in
the scope of the subtree:

,---------------------------------------------------------------
| ** Second Level Headline                                      
|                                                               
| #+header: :var marginnote-font=(jk-org-kwd "MARGIN-NOTE-FONT")
| #+header: :results raw :exports results                       
| #+begin_src emacs-lisp                                        
| (format "\\setmarginnotefont{%s}" marginnote-font)            
| #+end_src                                                     
`---------------------------------------------------------------

I couldn't make sense of the backtrace triggered by
toggle-debug-on-quit, except to note that it reports org-babel
functions.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Subtree export problems

[Thomas S. Dye]

Aloha Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> PS Tom, the approach you are using to this looks rather convoluted.
> Instead of a src block + keyword thing, why not just use #+latex (or
> #+latex_header) to insert the code you need?

Agreed.  I'm trying to write to a general audience.  The convoluted
approach works well for bits of text that get typeset in the front
matter of a book, for instance.  I can direct the user to change a
keyword in plain view at the top of the buffer, rather than ask them to
change an argument to a function, or rummage through some LaTeX code to
find where a change should be made.

MARGIN-NOTE-FONT isn't a particularly good example of this because the
user is expected to know some LaTeX.  If I find time, I'll browse my
library to see if I can classify margin notes.  If so, then
MARGIN-NOTE-FONT can be set to a class name rather than LaTeX code.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Subtree export problems

[Rasmus]

Hi Tom,

Thomas S. Dye <tsd@tsdye.com> writes:

>> How could it do anything else?  Try to narrow to the subtree 
>> and  run your code (see also org-export-as and how subtree 
>> export  works; it narrows).  You will see that your code 
>> returns nil. 
> 
> Interesting, thanks, that makes sense.  So, IIUC narrowing puts 
> the "keywords" at the top of the buffer out of scope.

I agree.

> I fiddled around a bit and came up with this, which seems to 
> work: ... 

Cool!  Perhaps something like org-with-wide-buffer would allow you 
to recapture your keywords/properties.  Otherwise you might be 
able to add a λ to org-export-before-processing-hook to add your 
own known keywords/properties to each headline.

>> You are using a hack to use something that you think looks like 
>> a  Org keyword, but which is not (in particular it’s unknown to 
>> ox  backends).  I think you can check 
>> org-export-get-environment and  org-export-define-backend to 
>> appreciate this. 
> 
> Am I right that what John Kitchin's code (jk-org-kwd) refers to 
> as "keyword" should be called "property" instead?  This makes 
> more sense to me in light of the above. 

Probably.  But it was formatted as a keyword (i.e. #+KEYWORD:).
 
> Also, I don't understand what you mean by "hack".  Should I be 
> wary of using John's functions?  I find them handy to mark bits 
> of information that the user (usually me) might want to change. 
> They save the need to rummage around a long document to find 
> where the information is actually used.  Should I use other 
> functions instead? 

I’d say "no".  I rely on plenty of hacks in my own documents (13 
filters in my standard Makefile conf.el).  There's nothing wrong 
with that as long as you know that you are playing with the fire. 
In this case you need to worry about the scope.  Probably other 
pitfalls exist.

Rasmus

-- 
When in doubt, do it!