* Subtree export problems
@ 2016-02-06 0:34 Thomas S. Dye
2016-02-06 14:17 ` Rasmus
0 siblings, 1 reply; 7+ messages in thread
From: Thomas S. Dye @ 2016-02-06 0:34 UTC (permalink / raw)
To: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Subtree export problems
2016-02-06 0:34 Subtree export problems Thomas S. Dye
@ 2016-02-06 14:17 ` Rasmus
2016-02-06 22:08 ` Aaron Ecay
2016-02-06 23:03 ` Thomas S. Dye
0 siblings, 2 replies; 7+ messages in thread
From: Rasmus @ 2016-02-06 14:17 UTC (permalink / raw)
To: emacs-orgmode; +Cc: aaronecay
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. . .
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Subtree export problems
2016-02-06 14:17 ` Rasmus
@ 2016-02-06 22:08 ` Aaron Ecay
2016-02-06 22:24 ` Rasmus
2016-02-06 23:39 ` Thomas S. Dye
2016-02-06 23:03 ` Thomas S. Dye
1 sibling, 2 replies; 7+ messages in thread
From: Aaron Ecay @ 2016-02-06 22:08 UTC (permalink / raw)
To: Rasmus; +Cc: orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Subtree export problems
2016-02-06 22:08 ` Aaron Ecay
@ 2016-02-06 22:24 ` Rasmus
2016-02-06 23:39 ` Thomas S. Dye
1 sibling, 0 replies; 7+ messages in thread
From: Rasmus @ 2016-02-06 22:24 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Subtree export problems
2016-02-06 22:08 ` Aaron Ecay
2016-02-06 22:24 ` Rasmus
@ 2016-02-06 23:39 ` Thomas S. Dye
1 sibling, 0 replies; 7+ messages in thread
From: Thomas S. Dye @ 2016-02-06 23:39 UTC (permalink / raw)
To: Aaron Ecay; +Cc: orgmode, Rasmus
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Subtree export problems
2016-02-06 14:17 ` Rasmus
2016-02-06 22:08 ` Aaron Ecay
@ 2016-02-06 23:03 ` Thomas S. Dye
2016-02-07 0:14 ` Rasmus
1 sibling, 1 reply; 7+ messages in thread
From: Thomas S. Dye @ 2016-02-06 23:03 UTC (permalink / raw)
To: Rasmus; +Cc: aaronecay, emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Subtree export problems
2016-02-06 23:03 ` Thomas S. Dye
@ 2016-02-07 0:14 ` Rasmus
0 siblings, 0 replies; 7+ messages in thread
From: Rasmus @ 2016-02-07 0:14 UTC (permalink / raw)
To: emacs-orgmode
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!
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-02-07 0:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-06 0:34 Subtree export problems Thomas S. Dye
2016-02-06 14:17 ` Rasmus
2016-02-06 22:08 ` Aaron Ecay
2016-02-06 22:24 ` Rasmus
2016-02-06 23:39 ` Thomas S. Dye
2016-02-06 23:03 ` Thomas S. Dye
2016-02-07 0:14 ` Rasmus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).