local variables and export processing in hooks

local variables and export processing in hooks

[Eric S Fraga]

Dear org mode users,

I have a small elisp function that I use to process my org file before
export to LaTeX or HTML, adding this function to
org-export-before-parsing-hook.  Briefly, the function exports the TBLFM
lines so that the org table calculations can be inspected.  This is for
pedagogical use.

This works just fine.  However, I don't want to do this generally so I
have a variable that controls whether the processing happens or not.  Is
there some way to make this variable local to an org file for use in the
export?  I have tried combinations of setq-local and #+BIND: but have
not yet managed to get this work successfully.

Thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f

Re: local variables and export processing in hooks

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Tue, Feb 09, 2021 at 10:13:01AM +0000, Eric S Fraga wrote:
> Dear org mode users,
> 
> I have a small elisp function that I use to process my org file before
> export to LaTeX or HTML, adding this function to
> org-export-before-parsing-hook.  Briefly, the function exports the TBLFM
> lines so that the org table calculations can be inspected.  This is for
> pedagogical use.
> 
> This works just fine.  However, I don't want to do this generally so I
> have a variable that controls whether the processing happens or not.  Is
> there some way to make this variable local to an org file for use in the
> export?  I have tried combinations of setq-local and #+BIND: but have
> not yet managed to get this work successfully.

Perhaps a file local variable?

Either in the first line:

  -*- mode: MODENAME; VAR: VALUE; ... -*-

or at the end of the file:

  # Local Variables:
  # mode: org
  # my-var: value
  # End:

(Indentation is for clarity, remove)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: local variables and export processing in hooks

[Eric S Fraga]

On Tuesday,  9 Feb 2021 at 12:30, tomas@tuxteam.de wrote:
> Perhaps a file local variable?

Thank you.

I tried but this doesn't seem to be propagated to the export as the
export works on a copy of the buffer, not the buffer itself.  That's
what #+BIND is for, supposedly...

I'll play some more.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f

Re: local variables and export processing in hooks

[Sébastien Miquel]

Eric S Fraga writes:
> I tried but this doesn't seem to be propagated to the export as the
> export works on a copy of the buffer, not the buffer itself.  That's
> what #+BIND is for, supposedly...

I think this buffer copy preserves local variables. I know I use a such 
a local variable and its value can be read during macro expansion.

It seems the org-export-before-parsing-hook functions are run before the 
#+BIND values are collected (see org-export-as in ox.el).


-- 
Sébastien Miquel

Re: local variables and export processing in hooks

[Eric S Fraga]

On Tuesday,  9 Feb 2021 at 14:21, Sébastien Miquel wrote:
> I think this buffer copy preserves local variables. I know I use a
> such a local variable and its value can be read during macro
> expansion.

It does.  <blush> Not sure what happened but I thought setting a file
local variable was the first thing I tried.  Hey hum.  Sorry for the
noise and thank you.  Works just fine now.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f

Re: local variables and export processing in hooks

[M. ‘quintus’ Gülker]

Am 09. Februar 2021 um 14:21 Uhr +0100 schrieb Sébastien Miquel:
> Eric S Fraga writes:
> > I tried but this doesn't seem to be propagated to the export as the
> > export works on a copy of the buffer, not the buffer itself.  That's
> > what #+BIND is for, supposedly...
> 
> I think this buffer copy preserves local variables. I know I use a such a
> local variable and its value can be read during macro expansion.
> 
> It seems the org-export-before-parsing-hook functions are run before the
> #+BIND values are collected (see org-export-as in ox.el).

Interesting. I did not know about #+BIND, but just today I came about
the issue where I needed file-local variables to be available both in
the org-export-before-parsing-hook and in macro expansion. I
circumvented the problem by picking the original buffer out of
`buffer-list' and temporaryly switching to that buffer with
`with-current-buffer'.

Now I wonder whether #+BIND is more elegant. But my macro expansion
function modifies a buffer-local variable. Does #+BIND allow for that,
so that the changed value is available in the original org buffer?

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu |    For security:
Passau, Germany      | kontakt@guelker.eu    | () Avoid HTML e-mail
European Union       | PGP: see homepage     | /\ http://asciiribbon.org

Re: local variables and export processing in hooks

[Sébastien Miquel]

M. ‘quintus’ Gülker writes:
> Now I wonder whether #+BIND is more elegant. But my macro expansion
> function modifies a buffer-local variable. Does #+BIND allow for that,
> so that the changed value is available in the original org buffer?

The purpose of #+BIND is to set some variables in the copied buffer.

Also, these variables are set after macro expansion (and 
org-export-before-parsing-hook).

I'm curious, could you explain why/how you use macros to set variables 
in the original buffer ?

-- 
Sébastien Miquel

Re: local variables and export processing in hooks

[M. ‘quintus’ Gülker]

Am 11. Februar 2021 um 21:12 Uhr +0100 schrieb Sébastien Miquel:
> The purpose of #+BIND is to set some variables in the copied buffer.
> 
> Also, these variables are set after macro expansion (and
> org-export-before-parsing-hook).

Thanks for the information. If they are set after macro expansion, it
will not help me (see below).

> 
> I'm curious, could you explain why/how you use macros to set variables in
> the original buffer ?

The how is easy enough. First I, define an automatically buffer-local
variable with

    (defvar-local the-buffer-local-variable nil)

In the org-before-processing-hook and in the macro expansion function
then I effectively do this:

    (with-current-buffer (car (buffer-list))
      (setq the-buffer-local-variable "thevalue"))

I agree that the heuristic on (buffer-list) may not be ideal, but for
the cases I had so far it works just fine and retrieves the original
.org buffer from which the system is currently exporting.

As for the why: I am working on a personal citation system for my
specific needs called zit.el (I am a German jurist, and we have quite
peculiar habits on citation, of which excessive use of footnotes and
not using LaTeX, instead having to submit in DOCX format are only
some). I use this functionality to implement a footnote crossreference
system. That is, the first time a citation appears it should appear in
the footnote as:

    /Doe/, Some Awesome Work, 3rd edition 2014, pp. 44 ff.

Then the next time this source is cited it should appear as:

    /Doe/ (Fn. 35), pp. 46.

If it was not clear from the above: my custom citation system relies
on org's macro system. In the org source I have something like this:

    [fn:35] {{{zit(doe2014awesomework[44 ff.])}}}.
    [fn:36] {{{zit(doe2014awesomework[46])}}}.

The `zit' macro is my custom macro which operates on a buffer-local
variable. If a citation is new, it adds an org target with a unique
name (<<target>>) to the macro expansion value and records it in said
variable. If the citation is not new, it retrieves the target value
from the variable and expands to a link to the target instead; org is
smart enough to resolve links to targets in footnotes to the footnote
number, which I make use of here. All this only works because it is
possible to implement a macro in an elisp function by using #+MACRO
with an `eval' statement. This certainly is a cool functionality I am
quite grateful for.

Now that I think about it: actually a normal variable would suffice. I
used a buffer-local one a) because my custom citation system has some
per-document settings, like the "Fn." in the parantheses above being a
customisable string, which are naturally implemented as
file-local/buffer-local variables and b) because one might have
multiple org documents open at the same time. But because the citation
collection variable is transient anyway (in fact, it is reset to nil
in the org-before-processing hook so that on a subsequent run it
starts from a clean sheet) and one can only export one document
simultaneously at a time, a normal variable would be enough. I will
probably change that.

If #+BIND statements are not available in macros, they will not work
for my per-document settings as described before, so I will leave them
as file-local/buffer-local variables as they are currently. I needed
to read up on how to mark my own variables as "safe" for that purpose,
but I have now found out how to do that.

Thanks for your answer!

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu |    For security:
Passau, Germany      | kontakt@guelker.eu    | () Avoid HTML e-mail
European Union       | PGP: see homepage     | /\ http://asciiribbon.org

Re: local variables and export processing in hooks

[Maxim Nikulin]

On 09/02/2021 19:06, Eric S Fraga wrote:
> On Tuesday,  9 Feb 2021 at 12:30, tomas@tuxteam.de wrote:
>> Perhaps a file local variable?
> 
> I tried but this doesn't seem to be propagated to the export as the
> export works on a copy of the buffer, not the buffer itself.  That's
> what #+BIND is for, supposedly...

I have seen that you have achieved your goal with local variables. 
Concerning BIND, there was a topic a month ago that bind has to be 
enabled explicitly. Unsure if it makes parameter available early enough 
however:

https://orgmode.org/list/87pn2iz3kr.fsf@posteo.net/
On 06/01/2021 18:51, Juan Manuel Macías wrote:
 > (setq org-export-allow-bind-keywords t)

Re: local variables and export processing in hooks

[Eric S Fraga]

On Wednesday, 10 Feb 2021 at 22:43, Maxim Nikulin wrote:
> Concerning BIND, there was a topic a month ago that bind
> has to be enabled explicitly. Unsure if it makes parameter available
> early enough however:

My understanding is that it makes it available, i.e. in the sense that
it's simply not available otherwise, but not early enough.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.4-213-g49364f