From: "M. ‘quintus’ Gülker" <post+orgmodeml@guelker.eu>
To: emacs-orgmode@gnu.org
Subject: Re: local variables and export processing in hooks
Date: Fri, 12 Feb 2021 08:28:41 +0100 [thread overview]
Message-ID: <20210212072841.GA3346@atlantis> (raw)
In-Reply-To: <81579f62-41a3-552c-7f2e-1885e591d1d5@posteo.eu>
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
next prev parent reply other threads:[~2021-02-12 7:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 10:13 local variables and export processing in hooks Eric S Fraga
2021-02-09 11:30 ` tomas
2021-02-09 12:06 ` Eric S Fraga
2021-02-09 13:21 ` Sébastien Miquel
2021-02-10 8:48 ` Eric S Fraga
2021-02-10 20:56 ` M. ‘quintus’ Gülker
2021-02-11 20:12 ` Sébastien Miquel
2021-02-12 7:28 ` M. ‘quintus’ Gülker [this message]
2021-02-10 15:43 ` Maxim Nikulin
2021-02-11 8:50 ` Eric S Fraga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210212072841.GA3346@atlantis \
--to=post+orgmodeml@guelker.eu \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).