Re: Hiding citations

[M . ‘quintus’ Gülker]

Am Samstag, dem 25. Februar 2023 schrieb Bruce D'Arcus:
> Not exactly what you're asking for, but have you seen this activate processor?
>
> https://github.com/andras-simonyi/org-cite-csl-activate

Not yet, and it certainly looks nice, but the CSL style I use uses
footnotes, and those are quite verbose. Rendering them (or rather, their
content) into the text would expand it even more.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Hiding citations

[M . ‘quintus’ Gülker]

Dear list,

is there a way to visually hide citations in the org buffer, much like
links are hidden? I ask because if a text passage contains a number of
citations, it quickly becomes hard to read if they are all displayed in
raw format. Here is a paragraph from one of my recently published papers[1]
in its original org markup (language is German):

> Der Begriff „Überwachungsgesamtrechnung“ wurde von
> {{{name(Roßnagel)}}} im Anschluss an die Entscheidung des
> {{{court(BVerfG)}}} zur Vorratsdatenspeicherung geprägt.
> [cite:@roßnagel2010überwgesrech p. 1242,] Er sieht in der Passage, in
> der das {{{court(BVerfG)}}} den Gesetzgeber „in Blick auf die
> Gesamtheit der verschiedenen schon vorhandenen Datensammlungen zu
> größerer Zurückhaltung“ [cite:@bverfg2010vds p. 324,] anhält, den
> Ausgangspunkt für eine doppelte Verhältnismäßigkeitsprüfung, die
> einmal individuell und einmal gesamtgesellschaftlich anhand aller
> bestehenden Überwachungsmaßnahmen in Gesamtschau ausgeführt werden
> müsse. [cite: @roßnagel2010überwgesrech p. 1240,;dem folgend
> @braun-albrecht2017freih_gasse p. 152,;kritisch dazu
> @hornung-schnabel2010bverfgvds p. 827,] Eine solche doppelte
> Verhältnismäßigkeitsprüfung hat das {{{court(BVerfG)}}} aber weder in
> dieser noch in einer anderen Entscheidung durchgeführt. Anderes folgt
> auch nicht aus dem gelegentlichen Rekurs des Gerichts auf eine „große
> Streubreite“. Soweit das {{{court(BVerfG)}}} hierauf zurückgreift,
> wird der Begriff ausschließlich zur Begründung einer hohen
> Eingriffsintensität genutzt, [cite:Vgl. @bverfg2005vorbeug_telek p.
> 383,;@bverfg2010vds p. 318,;@bverfg2018kfz_kennz_ii note 98,] d. h.
> die „große Streubreite“ erhöht die Anforderungen an die später zu
> prüfende Angemessenheit. Eine doppelte Verhältnismäßigkeitsprüfung ist
> damit nicht verbunden.

I use visual-line-mode, so imagine this actually as a single long line.
It contains both macros (which can nicely be condensed with
`org-hide-macro-markers' to improve readability), but some of those
citation constructs are awkwardly long and hinder reading the paragraph
as a whole in the editor, most notably the one with the three citations
right in the middle. I would prefer it it looked like this:

> Der Begriff „Überwachungsgesamtrechnung“ wurde von name(Roßnagel) im
> Anschluss an die Entscheidung des court(BVerfG) zur
> Vorratsdatenspeicherung geprägt. [cite:…] Er sieht in der Passage, in
> der das court(BVerfG) den Gesetzgeber „in Blick auf die Gesamtheit der
> verschiedenen schon vorhandenen Datensammlungen zu größerer
> Zurückhaltung“ [cite:…] anhält, den Ausgangspunkt für eine doppelte
> Verhältnismäßigkeitsprüfung, die einmal individuell und einmal
> gesamtgesellschaftlich anhand aller bestehenden Überwachungsmaßnahmen
> in Gesamtschau ausgeführt werden müsse. [cite:…] Eine solche doppelte
> Verhältnismäßigkeitsprüfung hat das court(BVerfG) aber weder in dieser
> noch in einer anderen Entscheidung durchgeführt. Anderes folgt auch
> nicht aus dem gelegentlichen Rekurs des Gerichts auf eine „große
> Streubreite“. Soweit das court(BVerfG) hierauf zurückgreift, wird der
> Begriff ausschließlich zur Begründung einer hohen Eingriffsintensität
> genutzt, [cite:…] d. h. die „große Streubreite“ erhöht die
> Anforderungen an die später zu prüfende Angemessenheit. Eine doppelte
> Verhältnismäßigkeitsprüfung ist damit nicht verbunden.

This is much more easier to look at and uses the spare screen space in a
much more economic way. Editing citations could follow the same rules as
editing links, that is, if the terminal bracket is removed, everything
becomes visible again (or one just uses special citation-editing
commands).

Does such a feature already exist? If not, I would like to request it. I
however do think that it should be optional, because there is some
useful information inside the citation constructs that might help
reading (and not everyone needs so many and long citation constructs as
my discipline).

  -quintus

[1]: Contained in this open-access conference proceedings volume:
 https://cloud.weizenbaum-institut.de/s/kEyydT72PSSpjSo

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [PATCH][oc-csl] Improve reference parsing

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> hopefully somebody more knowledgeable than me can comment on how
> viable this is, but would a @@csl like export snippet construct help
> with the problem?
> In that case your macro could be along the lines of
>
> #+MACRO: name @@csl:$1@@

It is an interesting approach, but it has a drawback. I use this macro
also in the ordinary text when I refer to persons without an explicit
citation. That is, the macro has to work both in a citation and in
normal text. Even if a @@csl: construct would be ignored in normal text,
I cannot see how to write the macro then, because something like

#+MACRO: name @@csl:$1latex:\textsc{$1}html:$1@@

would still transfer the @@latex: and @@html: constructs into the
footnote. They would have to be expressly ignored by the citation
processor.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [PATCH][oc-csl] Improve reference parsing

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 19. Januar 2023 schrieb András Simonyi:
> apologies for replying that late. If I understand the situation
> correctly, we could handle the question of allowing macros in
> citations independently of the handling of other constructs, because
> macros are resolved before processing citations, so they have no
> effect on the input of Citeproc-el.  In light of this, maybe there
> could be a separate patch for just allowing macros?

I am not sure this targets the usecase I am pursuing, which is to use
macros to produce @@latex: escape constructs in order to have small-caps
markup in the citation footnotes:

#+MACRO: name @@latex:\textsc{$1}html:$1@@

If the macro resolves, but the @@latex construct does not, that would be
problematic. That being said, I /found/ an alternative that works,
albeit it is a bit ugly. I can create an explicit footnote, use a
[cite/default/bare:] construct (to suppress the terminal period) within
it and terminate the citation before the macro begins. That way, the
macro is outside of the citation construct. This construction is however
unfortunate when I want to cite multiple sources and have the macro used
on an earlier one, e.g.:

[fn:1] [cite/default/bare:@foo p. 5], countering {{{name(Doe’s)}}} 
argument; [cite/default/bare:@bar p. 37].

It would be nicer if I could just write into the main text

[cite:@foo p. 5, countering {{{name(Doe’s)}}} argument;@bar p. 37]

I can however live with the more elaborate construction, if nothing
else.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Beamer export: Executing LaTeX between two frames

[M . ‘quintus’ Gülker]

Dear Ihor,

please apologise the slow reply.

Am Sonntag, dem 26. Juni 2022 schrieb Ihor Radchenko:
> This is too hacky as for my taste.
>
> I'd rather use :ignore: tag from ox-extra:

This works decently. I did not know about “ox-extra” before. For
reference, it is here: 


What I then did was:

(require 'ox-extra)
(ox-extras-activate '(ignore-headlines))

And then export to latex-beamer as usual. Just like Ihor described, the
two headings tagged “:ignore:” are suppressed from the output and the
“\usebackgroundtemplate” macro is properly wrapped around the
non-ignored heading.

Thank you Ihor.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Filter for HTML (cite) footnotes?

[M . ‘quintus’ Gülker]

Dear all,

I ought to drive this thread to its completion. What I intend to do is
better covered by the new callback functions provided by citeproc-el:
<https://github.com/andras-simonyi/citeproc-el/issues/111>

  -quintus

Am Dienstag, dem 08. März 2022 schrieb Juan Manuel Macías:
> M. ‘quintus’ Gülker writes:
>
>> That is, what I am after effectively, is post-processing the results
>> generated by org-cite resp. citeproc.el. I have names in my
>> bibliographic database like “Axel von Hellfeld”, which contain the
>> German name particle “von”. Some (not all) citation customs require
>> “von” to be abbreviated to “v.” so that the cited name becomes
>> “v. Hellfeld”. This is not possible with CSL, so I look for another
>> way to automate this during the export process.
>
> I see. Have you tried using `org-export-filter-final-output-functions'?
> You can try a find/replace function for the footnotes of final
> output. The drawback is that the scope here is broader and
> care should be taken with false positives...
>
> Best regards,
>
> Juan Manuel 


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [PATCH][oc-csl] Improve reference parsing

[M . ‘quintus’ Gülker]

Dear all,

I probably have not much to contribute to this rather technical thread,
but Ihor has redirected me here two times for my citation formatting
questions[1][2]. So I would like to ask if there is something I can do to
accelerate its inclusion into org so that I can start using macros in
citations?

  -quintus

[1]: https://list.orgmode.org/orgmode/87o7tb8pc1.fsf@localhost/

[2]: https://list.orgmode.org/orgmode/87zgcw8gtd.fsf@localhost/

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [RFC PATCH] Re: [bug] Macro in citation not expanded

[M . ‘quintus’ Gülker]

Dear Ihor,

thank for the WIP patch. I have applied it to current main
(f83e45526b5ec4627d601673be3680e2dece1b33), but when I now export the
document described in the OP to LaTeX, the macro is erased entirely. I
receive:

1 Doe, Nothing important, 2. Aufl. (2022), 55, zum vorgenannten Argument 
aaO.

The same for HTML export.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Formatting in citation locator

[M . ‘quintus’ Gülker]

Dear all,

apologies for my slow reply. It is currently hard for me to find some
time for these issues, but eventually I do manage it.

Am Mittwoch, dem 26. Oktober 2022 schrieb András Simonyi:
> I've ended up making the necessary changes in citeproc and also posted
> a patch here which should enable formatting in locators. Marvin, I'd
> appreciate it if you could test it.

I have updated citeproc-el to 69536c8776dea383951538fd197333bee766d7c7
and org-mode to Org mode version 9.6-pre (release_9.5-1271-gf83e45 @
/home/quintus/.emacs.d/org-mode/lisp/). However, using the material
provided in the OP, I still do not get a formatted footnote, even with
the zero-width space. The outcome still is

  BVerfGE 125, 260 (373 [Sondervotum /Schluckebier/​])

both in HTML and LaTeX.

GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.31, cairo 
version 1.16.0).

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Formatting in citation locator

[M . ‘quintus’ Gülker]

Am Mittwoch, dem 19. Oktober 2022 schrieb Ihor Radchenko:
> It is expected because we do not allow "]" right after markup. You'd
> need to insert an escape character (zero-width space) to force the
> italics markup in [Sondervotum /Schluckebier/].
> See https://orgmode.org/manual/Escape-Character.html.

Thanks for the hint, but it does not work still even if I change the
line to contain the said zero-width space:

Abweichende Meinung. [cite:@bverfg2010vds p. 373 [Sondervotum 
/Schluckebier/​],]

The buffer is now fontified as expected, but it does not work when
exported to HTML:

1 BVerfGE 125, 260 (373 [Sondervotum /Schluckebier/​])

This however I think comes down to the same problem which is described
at .

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [bug] Macro in citation not expanded

[M . ‘quintus’ Gülker]

Am Sonntag, dem 16. Oktober 2022 schrieb Ihor Radchenko:
> Only bold, code, entity, italic, latex-fragment, strike-through,
> subscript, superscript, underline, and verbatim objects are allowed
> inside citations.
> This is hard-coded inside `org-element-object-restrictions'.

This is a bit unfortunate, because I like to use macros for inserting
semantic formatting which is not part of org’s syntax. In the example
given in my OP, I use it to mark up names with small caps. The exact
example given includes a short note by me talking about the cited author
a little further. Another example where I need this is when I cite some
statement made in an interview, which may come out as something like:

[cite:{{{name(Interviewee)}}} in @interviewer p. 5]

Indirect statements by persons mentioned in news articles are another
example where I would use such a construct.

I define the `name' macro in such a way that it will format
`Interviewee` in the same way as the citation style formats the author
name for @interviewer, ensuring uniformness in the created footnote.

I also use the very same `name' macro inside the actual article text, so
that uniform formatting is guaranteed there as well.

> It sounds reasonable to allow macros inside citation references.
> Maybe we also want to allow other things. Maybe simply allow all objects
> but other citations, line-breaks, and table-cells?

I have no strong opinion on this. I certainly do not need tables inside
citations. If it is easy to just permit everything except what you
named, I would say just allow it. Maybe someone has use for it. Maybe
footnotes inside [cite:] construct should also not be allowed, at least
for footnote-based styles.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

[bug] Macro in citation not expanded

[M . ‘quintus’ Gülker]

Dear list,

it turns out that macros in citation commands are not expanded. Minimal
working example:

/tmp/mwe.org:

#+TITLE: Test
#+LANGUAGE: de
#+bibliography: /tmp/mwe.bib
#+cite_export: csl /tmp/juristische-schulung.csl
#+MACRO: name @@latex:\textsc{$1}@@

Dies {{{name(Foo)}}}  ist ein Test. [cite:@doe2022nothing p. 55,, zum 
vorgenannten Argument {{{name(Doe)}}} aaO.]

/tmp/mwe.bib is:

@Book{doe2022nothing,
author   = {John Doe},
title= {Nothing Important},
year  = {2022},
edition   = {2},
publisher = {Some Publisher},
location  = {Nowhere},
langid= {english}}

/tmp/juristische-schulung.csl is 
.

Exporting this to LaTeX yields:

Dies \textsc{Foo}  ist ein Test.\footnote{\textit{Doe}, Nothing important, 
2. Aufl. (2022), 55, zum vorgenannten Argument \{\{\{name(Doe)\}\}\} aaO.}

This replaces the first call to the `name' macro properly, but it does
not replace the call to the `name' macro inside the `cite:' construct.
Instead, it copies the macro construct verbatim into the LaTeX footnote.
The correct output should have been:

Dies \textsc{Foo}  ist ein Test.\footnote{\textit{Doe}, Nothing important, 
2. Aufl. (2022), 55, zum vorgenannten Argument \textsc{Doe} aaO.}

Version information:

Org mode version 9.6-pre (release_9.5-1162-g15b3aa @ 
/home/quintus/.emacs.d/org-mode/lisp/)
citeproc.el @ ba49516265fa24b138346c4918d39d19b4de8a62
GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 3.24.31, cairo 
version 1.16.0)

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Beamer export: Executing LaTeX between two frames

[M . ‘quintus’ Gülker]

Dear list,

I am working on a presentation for a conference (using org-mode and its
beamer export) and want to exchange the entire background for a specific
frame with an image. This is possible with Beamer, see
. It works by issueing
\usebackgroundtemplate /between/ the frame environments. The frame
environment needs to be placed inside an extra group of {}, resulting in
a LaTeX construct like this (example taken from the StackExchange link):

% Local background must be enclosed by curly braces for grouping.
{
\usebackgroundtemplate{\includegraphics[width=\paperwidth]{kitten.jpg}}%
\begin{frame}{Kitten}
\begin{itemize}
\item 1
\item 2
\item 3
\end{itemize}
\end{frame}
}

I tried to use a #+begin_export beamer construct to achieve this from
within org:

* Normal Frame

#+begin_export beamer
{\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,height=\paperheight]{test.jpg}}
\begin{frame}[t]\frametitle{This frame should have another background}
% ...frame content...
\end{frame}
}
#+end_export

* Normal frame again

But that results in a LaTeX compilation error, because the command is
not issued between to frames, but within the frame created for the
"Normal Frame" heading. Breaking the construct up in two #+begin_export
beamer constructs like this therefore also does not work, because the
second heading causes an \end{frame} to be inserted after the
\usebackgroundtemplate group has been opened:

* Normal Frame

#+begin_export beamer
{\usebackgroundtemplate{%
\includegraphics[width=\paperwidth,height=\paperheight]{test.jpg}}
#+end_export

* This frame should have another background

#+begin_export beamer
}
#+end_export

* Normal frame again

So, how do I wrap the \begin{frame}...\end{frame} construct within the
\usebackgroundtemplate group?

  -quintus

--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Filter for HTML (cite) footnotes?

[M . ‘quintus’ Gülker]

Hi,

Am Sonntag, dem 06. März 2022 schrieb Juan Manuel Macías:
> I think a function for `org-export-filter-parse-tree-functions' would
> work better here. For example, this function replaces "lorem ipsum" with
> "foo" in all footnote definitions:

I have tried this suggestion, but it does not appear to work with
org-cite’s automatically generated footnotes. Text is only changed in
ordinary footnotes already present in the org file. When I use org-cite
with citeproc.el with a CSL style demanding footnotes, these citational
footnotes are generated from the [cite:] constructs somewhere inside
org-cite and/or citeproc.el during the export process. These footnotes
are apparantly not subject to “org-export-filter-parse-tree-functions”,
probably because they are inserted after parsing has completed.

That is, what I am after effectively, is post-processing the results
generated by org-cite resp. citeproc.el. I have names in my
bibliographic database like “Axel von Hellfeld”, which contain the
German name particle “von”. Some (not all) citation customs require
“von” to be abbreviated to “v.” so that the cited name becomes
“v. Hellfeld”. This is not possible with CSL, so I look for another
way to automate this during the export process.

  -quintus

--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Filter for HTML footnotes?

[M . ‘quintus’ Gülker]

Dear list,

I recently discovered export filters and found some useful applications
for them. For instance, the scientific domain I work in (law) uses
footnote citations, and in these footnotes we abbreviate some words
which would otherwise be written out in ordinary text, like name
particles. Since I use org-cite these footnotes are automatically
generated. So what I did was to write a filter which abbreviates these
words on export in footnotes. I added the filter function to both
org-export-filter-footnote-definition-functions and
org-export-filter-footnote-reference-functions and indeed, when I export
to LaTeX or ODT it does its job just fine. However, when I export to
HTML instead, it does not. When I looked at the text passed to the
filter when exporting as HTML, it turned out what the function receives
is not the content of the footnote, but only the markup for the footnote
number. That came a bit by surprise.

So, what is the correct way to target the content of a footnote in a
filter across backends?

Org mode version 9.5 (release_9.5-484-g98588e @ 
/home/quintus/.emacs.d/org-mode/lisp/)

  -quintus

--
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal

[M . ‘quintus’ Gülker]

Am Montag, dem 06. Dezember 2021 schrieb Tom Gillespie:
> [On not excluding discussions about org markup from the mailing list]

Thank you for writing this up. I agree with it. This discussion has
taken routes which I would never have expected. We started with an
interoperability topic and now we are discussing whether the intent is
to take away software freedom from Emacs org users. I cannot help but to
find this connection far-fetched. Nobody is suggesting to hamper
org-mode-in-emacs' further development. All that was asked was if there
is interest in someone outside of org-mode-in-emacs writing up
“compatibility levels” for the org markup. Whether or not that is a
daunting task is up to those who want to pick it up, and it certainly is
not "owed" by the org developers to cater for them. If there are
synergies -- there appear to be some, since the org formalising efforts
do predate Karl Voit's proposal apparently -- they should be taken
advantage of and not be banned from discussion on this mailing list.

I do not expect the permissal of such discussions to turn this mailing
list into a hub for help requests for non-org, or, heaven forbid,
non-free software implementing org markup.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)

[M . ‘quintus’ Gülker]

Am Dienstag, dem 30. November 2021 schrieb Karl Voit:
> One of the next things I do have on my list is to try out crdt as
> I've learned at EmacsConf21 that it is mature enough to be used in
> practice. 
>
> If that holds true, we can start dreaming of having a Etherpad-like
> session from our GNU/Emacs while peers are connected to the same
> session via some web-based tool/service.

I never heard of crdt, but distributed editing sounds useful. There is
Git, of course, but unless you are a programmer, using Git is pretty
much arcane. I was not yet successful to explain Git to MS Word users,
who are actually happy with the change tracking tooling Word has built
in. Though that might be more of a topic for the emacs-humanities
mailing list rather than this list.

> The dominant feedback of
> https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/
> was negative comments on the name and nothing else. Even here,
> although due to a much more civilized style, the name choice was the
> dominant topic and not the idea. I have to take this as a strong
> signal here and I'm very close in giving up on Orgdown as a project.

The civility of this list is one of the reasons why I like to read it. I
find it incredible how people behave on these so-called social media.
That alone indicates that something is wrong with them.

You should not give up on the project. As I have learned from reading
this thread, there appear to be people who already work on formalising
org’s grammar. You ought to talk to them and see if it is possible to
unite efforts. Tom Gillespie in a message further down this thread has
mentioned that formalising org is a huge effort. I agree with that, but
your novel concept of “compatibility levels” is something I could see as
an intermediate step. It could help to accelerate the formalising
efforts and non-Emacs tools could start targetting them quickly. But I
might be wrong on seeing this as an advantage; I have never written
formal specifications.

It is certainly your success to have generated this discussion thread; I
was not aware of any similar formalisation efforts. I hope that if
nothing else, it contributes to this efforts.

> People do not seem to realize what it took to get there - which is
> partly understandingly because I had to learn by doing what it takes
> to get the idea into a coherent and consistent form.

I do not think anybody wanted to feel you bad. Most are trying to
provide constructive criticism to you in order to improve your
suggestions. There are very few people who are fundamentally opposed to
your effort, because they firmly believe there can be no org outside of
Emacs. My suggestion is to ignore them and continue on your path,
because your idea has no impact on them and they can by definition not
help you to improve it.

Naming is one of the hard things in Computer Science. Just leave the
naming issue aside and work with the people here to formalise the
compatibility levels.

> Bastien told me that he would be interested to see hard numbers on
> my assumption that Org-mode syntax is easier to learn and type in
> comparison to other LWM. And he is right: some research work in
> order to get numbers would be awesome to shed some light on the
> forest of assumptions. Maybe somebody in a position to realize such
> a case study gets motivated now? ;-)

Entirely subjectively, typing:

#+begin_src python
#+end_src

manually without help of the editor feels more difficult than typing:

 python


Any non-Emacs org(down) editor should ensure to ease typing that.

For the purposes of refining your proposal conducting the “case study”
simply by inquiry on this mailing list might suffice. Many people around
here know Markdown and I guess there is no value in applying rigorous
scientific standards here.

> Does "assuming too much on other people's world because on my own
> small world" have a scientific name? I might be in danger of having
> this disease? *g*

I have fallen to this earlier. My computer is full of things to solve
problems many people simply do not even have. I need citation software
that interacts with my Biblatex files, for instance. Since my e.g. my
work collegues do not even use Biblatex, they do not have such a need.
Typing citations out by hand is rather popular in my area; if it is not
done manually, people appear to use Citavi. I certainly know not a
single person in my area who uses Biblatex. Another example is that I
have a rather longish ~/.xinitrc file for automatic starting of several
applications, like the PulseAudio sound server. Somehow, this is a
problem others appearently do not have; it exists because I inflict to
myself the pain of using Linux with i3 and Emacs, which I perceive as
productive rather than painful, not to mention the privacy advantages.
There was a time when I tried to convince people from my setup as
the correct one for everyone, but today I know it is not.

As an aside, 

Re: "Orgdown", the new name for the syntax of Org-mode

[M . ‘quintus’ Gülker]

Am Montag, dem 29. November 2021 schrieb Karl Voit:
> It seems to be the case that the name "Orgdown" is the reason why
> the Org-mode community does not support the idea of an
> implementation-agnostic definition of the syntax. Which is ... kinda
> funny if you think about it.
>
> Well if the project is not working out, at least I made my point and
> we continue to have all those misunderstandings and lack of Orgdown
> support in 3rd party tools (because Org-mode is way too big).

I think the project has value; better tooling outside of Emacs is
something org can only profit from in my opinion. One point that has not
been raised yet are scenarios of collaborative work; I would enjoy it
quite a bit if I could work on documents together with people who do not
like Emacs as an editor for whatever reason. Currently, org as a file
format is pretty much excluded if collaboration is intended with someone
who does not use Emacs. The natural choice in these cases is Markdown.

I agree that the name is kind of odd as it seems as if it is necessary
to invoke some association to Markdown. Other markup languages also do
not need that -- Textile, Asciidoc, etc. Perhaps it is best to simply
ignore the naming issue and focus on the actual work instead. It is far
more important to get the compatibility levels defined. After that you
can still reconsider the naming.

> Oh, there is a very large danger here of getting something that is
> not compatible with Org-mode any more. I don't think that this would
> be a good thing. At least the different flavors killed the fun of
> Markdown for me.

The astonishing thing is that most people manage to get along despite of
the incompatibilities of the different Markdown flavours. Otherwise
Markdown would not be such a success. Why is this? What can be learned
from this for creating org tools outside of Emacs? Actually surveying
this might be of interest.

Maybe most documents are very simple files. README files for FLOSS
projects, forum posts, blog posts. For such content the features where
the Markdown implementations differ are usually not required. It
suffices to use unstyled text, headings, code blocks, quotes, emphasis.
That is it basically. org shines on documents where more is required --
documentation, books, since recently scientific articles. Markdown’s
common subset is not expressive enough for these documents, whereas for
simple documents there is not much benefit in trading in Markdown for
org. Thus, maybe it is more fruitful to try to market org(down) as a
markup for complex documents, with the added benefit that it does
incidentally also cover simple documents nicely on par with Markdown.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [PATCH] c-csl : accept relative CSL filenames

[M . ‘quintus’ Gülker]

Am Freitag, dem 19. November 2021 schrieb Nicolas Goaziou:
> I think a better order for a relative file name would be:
>
>  1. relatively to `org-cite-csl-styles-dir',
>  2. relatively to buffer's default directory,
>  3. failure.
>
> WDYT?

I would be fine with it.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [BUG] Citations: Locator treated as prefix [9.5 (release_9.5-225-g494c20 @ /home/quintus/.emacs.d/org-mode/lisp/)]

[M . ‘quintus’ Gülker]

Am Freitag, dem 12. November 2021 schrieb Nicolas Goaziou:
> Indeed. I forgot to say you also need to re-evaluate
> ‘org-cite-csl--label-regexp’ definition (in "oc-csl.el"), in order to
> refresh the locator regexp matched against.

Ah, I see. Indeed, re-evaluating that definition after amending
`org-cite-csl--label-alist' results in the desired result on export.

Thanks!

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [BUG] Citations: Locator treated as prefix [9.5 (release_9.5-225-g494c20 @ /home/quintus/.emacs.d/org-mode/lisp/)]

[M . ‘quintus’ Gülker]

Am Freitag, dem 12. November 2021 schrieb Nicolas Goaziou:
> This is because "Kap." is not known as a locator identifier. See
> ‘org-cite-csl--label-alist’ for the full list of such identifiers.

You are right, sir. “Kap.” is German for “chapter” and CSL does have a
localisable chapter locator. Using

Das ist ein Test [cite:@redeker2020itr chapter A Rn. 72, Suffixtext hier]

results indeed in the desired

1 Redeker, IT-Recht, 7. Aufl. (2020), Kap. A Rn. 72 Suffixtext hier

. Thanks for pointing it out.

> I don’t think it is reasonable to expect this variable to contain every
> identifier in every language. It may be a good idea to turn the variable
> above into a defcustom, thus.

Probably, but I will leave this to you. Just using the standard
“chapter” selector resolves my problem here.

> Meanwhile, you can test again after evaluating:
>
>   (push '("Kap." . "chapter") org-cite-csl--label-alist)

Interestingly, doing this does not make it work for me, the “Kap.” still
is displays at the beginning.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

[BUG] Citations: Locator treated as prefix [9.5 (release_9.5-225-g494c20 @ /home/quintus/.emacs.d/org-mode/lisp/)]

[M . ‘quintus’ Gülker]

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

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Dear all,

I originally reported this at
https://github.com/andras-simonyi/citeproc-el/issues/68, but was
directed here.

take this org file `mwe.org':

#+TITLE: Test
#+AUTHOR: Testauthor
#+LANGUAGE: de
#+bibliography: /tmp/mwe/mwe.bib
#+cite_export: csl /tmp/mwe/juristische-schulung.csl

Das ist ein Test [cite:@redeker2020itr Kap. A Rn. 72, Suffixtext hier]

with this `mwe.bib' Biblatex file:

@Book{redeker2020itr,
author   = {Helmut Redeker},
title= {IT-Recht},
year  = {2020},
edition   = {7},
publisher = {C.H. Beck},
location  = {München},
langid= {ngerman}}

`juristische-schulung.el' is 
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl

When this is exported to HTML, the locator `Kap. A Rn. 72' is split and
partly taken as the prefix. It exports to this:

1 Kap. A Rn.  Redeker, IT-Recht, 7. Aufl. (2020), 72 Suffixtext hier

This is incorrect; it should export to:

1 Redeker, IT-Recht, 7. Aufl. (2020), Kap. A Rn. 72 Suffixtext hier

Org mode version 9.5 (release_9.5-225-g494c20 @ 
/home/quintus/.emacs.d/org-mode/lisp/)
citeproc.el at e6b3f160dbe87d035cbee6c61bcfdd063f56b1cb

  -quintus

Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, 
cairo version 1.16.0)
 of 2021-03-28, modified by Debian
Package: Org mode version 9.5 (release_9.5-225-g494c20 @ 
/home/quintus/.emacs.d/org-mode/lisp/)

current state:
==
(setq
 org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-mode-hook '((closure
  (org-agenda-skip-regexp org-table1-hline-regexp 
org-table-tab-recognizes-table\.el
   org-table-dataline-regexp org-table-any-border-regexp
   org-agenda-restriction-lock-overlay 
org-agenda-overriding-restriction
   org-agenda-diary-file org-complex-heading-regexp t)
  nil (setq imenu-create-index-function 'org-imenu-get-tree))
 (closure
  (org--rds reftex-docstruct-symbol org-element-greater-elements
   visual-fill-column-width org-clock-history 
org-agenda-current-date org-with-time
   org-defdecode org-def org-read-date-inactive org-ans2 
org-ans1
   org-columns-current-fmt-compiled org-clock-current-task 
org-clock-effort
   org-agenda-skip-function org-agenda-skip-comment-trees 
org-agenda-archives-mode
   org-end-time-was-given org-time-was-given org-log-note-extra 
org-log-note-purpose
   org-log-post-message org-last-inserted-timestamp 
org-last-changed-timestamp
   org-entry-property-inherited-from org-blocked-by-checkboxes 
org-state
   org-agenda-headline-snapshot-before-repeat 
org-agenda-buffer-name
   org-agenda-start-on-weekday org-agenda-buffer-tmp-name 
org-priority-regexp
   org-mode-abbrev-table org-mode-syntax-table 
org-element-use-cache
   org-element-cache-persistent buffer-face-mode-face 
org-tbl-menu org-org-menu
   org-struct-menu org-entities org-last-state 
org-id-track-globally
   org-clock-start-time texmathp-why remember-data-file
   org-agenda-tags-todo-honor-ignore-options 
iswitchb-temp-buflist
   calc-embedded-open-mode calc-embedded-open-formula 
calc-embedded-close-formula
   align-mode-rules-list org-emphasis-alist 
org-emphasis-regexp-components
   org-export-registered-backends org-modules crm-separator 
org-babel-load-languages
   org-id-overriding-file-name org-indent-indentation-per-level
   org-element-paragraph-separate org-agenda-buffer-name 
org-inlinetask-min-level t)
  nil (add-hook 'change-major-mode-hook 'org-show-all 'append 
'local))
 (closure
  (org-src-window-setup *this* 
org-babel-confirm-evaluate-answer-no
   org-babel-tangle-uncomment-comments 
org-src-preserve-indentation
   org-src-lang-modes 

Re: [BUG] Elisp error when exporting citation [9.5 (release_9.5-104-g2b1fc6 @ /home/quintus/.emacs.d/org-mode/lisp/)]

[M . ‘quintus’ Gülker]

Am Samstag, dem 06. November 2021 schrieb András Simonyi:
> I've pushed a change to citeproc-el which should solve that problem --
> thanks for reporting it.

Thank you again! It works now properly.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [PATCH] c-csl : accept relative CSL filenames

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 04. November 2021 schrieb Nicolas Goaziou:
> I think there are two ways forward when a relative file name is used:
>
> 1. First check `org-cite-csl-styles-dir' and, if it is nil, expand
>against `default-directory';
>
> 2. Drop `org-cite-csl-styles-dir' and always expand against
>`default-directory'.
>
>  What do oc-csl users think about it?

On the risk that I do not entirely understand the dispute: I would like
to specify relative CSL files. Currently I work on a commentary which
has its own, specific citation guide lines, that is, I need a custom
specific CSL style just for this project. Naturally I store this CSL
file along the .org file in the same directory. I can specify its file
name as an absolute file name (which is what I do currently), but it
would be easier and immune to moving the folder around on my PC if it
could be a relative name. It would also help in creating minimal working
examples for bug reports, which currently require org maintainers to
adapt the path to the CSL file specified.

That would probably mean option 1. Option 2 seems extreme; while I have
not yet accumulated a reasonable collection of CSL files for the German
law journals, I suppose it will happen at some point, in which case it
will come in handy. Still, for the sake of archiving the .org files in a
working state, I may still want to be able to store the CSL file along
with the .org file. After all, the CSL file may be modified later on and
then it may not be possible to re-export the .org file. Having both the
CSL file and the .org file together (in one repository, for instance)
may seem preferable to me. It however is all too new to me to make a
final judgment on this question.

What about a third option: If `org-cite-csl-styles-dir' is not nil,
check if it resolves to an existing file; if no such file exists, expand
against `default-directory'. If `org-cite-csl-styles-dir' is nil, expand
against `default-directory'.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [BUG] Elisp error when exporting citation [9.5 (release_9.5-104-g2b1fc6 @ /home/quintus/.emacs.d/org-mode/lisp/)]

[M . ‘quintus’ Gülker]

Dear all,

Am Donnerstag, dem 04. November 2021 schrieb Nicolas Goaziou:
> Great! Hopefully, OP's problem is completely solved, then.

I can confirm that the original example I gave (the one with the missing
@ sign) does not error anymore now. The improper formatting on LaTeX
export I mentioned in the other e-mail[1] however is still persisting,
both with the @ and without it.

Org mode version 9.5 (release_9.5-214-gced2b3 @ 
/home/quintus/.emacs.d/org-mode/lisp/)
Citeproc.el at e93b45fe125d2ed61c60136638b3836ec770f879

  -quintus

[1]: 
https://list.orgmode.org/87pmrgs2la@nicolasgoaziou.fr/T/#m04c52902b1b2cb813269cac8088b4de94f0fcf2b

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Citations: position="first" match not properly evaluated

[M . ‘quintus’ Gülker]

Dear all,

the CSL style I use has footnotes. When a book is cited, it is once
cited with the full bibliographic information, and later footnotes then
reference the footnote in which this information first appeared,
shortening the later footnotes to the format "Author, (o. Fn. ),
...". (the spurious comma I will look into later, it's probably an error
in the CSL file). Now take this org file:

#+TITLE: Test
#+AUTHOR: testauthor
#+LANGUAGE: de
#+cite_export: csl  /tmp/mwe/juristische-schulung.csl
#+bibliography: /tmp/mwe/mwe.bib

Das ist ein Test mit dem ersten Zitat [cite:@knuth1997tacp1 p. 55].
Dasselbe Zitat mit einer anderen Seite [cite:@knuth1997tacp1 p. 70].

mwe.bib:

@Book{knuth1997tacp1,
author   = {Donald E. Knuth},
maintitle= {The Art of Computer Programming},
title = {Fundamental Algorithms},
year  = {1997},
edition   = {3},
publisher = {Addison-Wesley},
location  = {Reading, Harlow, Menlo Park, Berkeley, Don Mills, Sydney, 
Bonn, Amsterdam, Tokyo, Mexico City},
langid= {english},
volume= {1}}

juristische-schulung.csl is 
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl

Exporting this gives these two footnotes:

1 Knuth, The Art of Computer Programming, 3. Aufl. (1997), 55
2 Knuth, , 70

The second footnote is incomplete. It lacks the "o. Fn." mark and the
footnote referenced. If I export the equivalent pandoc-markdown document
with pandoc:

---
title: Test
author: Testauthor
lang: de
---

Das ist ein Test mit dem ersten Zitat [@knuth1997tacp1, p. 55].
Dasselbe Zitat mit einer anderen Seite [@knuth1997tacp1, p. 70].

Then both footnotes are proper:

1. Knuth, The Art of Computer Programming, 3. Aufl. (1997), p. 55
2. Knuth, (o. Fn. 1), p. 70

So it’s not an error in the CSL file. The CSL file uses this construct
to differenciate the two cases:



  

  
  

  
  


  


This is probably a bug.

Org mode version 9.5 (release_9.5-104-g2b1fc6 @ 
/home/quintus/.emacs.d/org-mode/lisp/)
citeproc.el at 34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Ox-pandoc and Org-cite

[M . ‘quintus’ Gülker]

Am Donnerstag, dem 14. Oktober 2021 schrieb Alex Fenton:
> The arrival of citation support in Org is fantastic, but it is a bit
> tricky for ox-pandoc, b/c pandoc itself has csl-based cite processing
> ability. I'd appreciate any pointers on a couple of points:

Maybe it will get easier when pandoc supports org's new citation syntax?
There's a ticket for this open: https://github.com/jgm/pandoc/issues/7329

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Manual suggestion and experience report from a new user (citation processors, 9.5)

[M . ‘quintus’ Gülker]

Am Mittwoch, dem 13. Oktober 2021 schrieb Leszek Wroński:
> Ideally I'd like a click on a citation to open the PDF whose location
> is stored in the 'file' field of the .bib entry: is there an easy way
> to achieve this? [I've tried various ways of doing this in the last
> 10+ years, including org-ref, RefTex etc., but am I correct in
> assuming that currently the idea is that one should only use the
> Org-mode for such things?]

Maybe it helps you: I use ebib for managing my .bib files. While I have
not yet tried directly to jump from a citation key in an .org file to
the corresponding ebib entry, I suppose there is a way. In ebib then it
is as easy as pressing “f” to open the PDF referenced in the “file”
field.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Dienstag, dem 12. Oktober 2021 schrieb András Simonyi:
> No, it's citeproc-el which is supposed to determine whether the passed
> locator string represents single vs multiple references, using § vs §§
> shouldn't make a difference, because they simply signal that the label
> is "section".

I see. This explains why it makes no difference whether I use "section"
or "§". Trying to find this out from the subsequent text alone sounds
ambitious to me, though. There could be difficult edge cases I imagine.

> Apparently, citeproc-el's classifier algorithm doesn't
> handle some of your examples correctly -- could you open an issue
> about this on the project page? Thanks in advance!

Done: https://github.com/andras-simonyi/citeproc-el/issues/58

  -quintus


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Dienstag, dem 12. Oktober 2021 schrieb Nicolas Goaziou:
> I mapped both § and §§ to "section". Hopefully, the issue is now
> completely fixed.

Nearly :-). Thank you so much for your hard work so far! It is
incredible to see how this develops.

With »Org mode version 9.5 (release_9.5-104-g2b1fc6 @ 
/home/quintus/.emacs.d/org-mode/lisp/)«
now

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

gives:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), §§ 12 Rn. 488

Positioning and choice of locator label is correct. The one thing left
is that it uses double §§ instead of a single §, that is, it treats the
citation as a plural one whereas it should be a singular one. The same
happens with

Das ist ein Test [cite:@saenger2013gsr section 12 Rn. 488].

Interestingly, the input

Das ist ein Test [cite:@saenger2013gsr § 12].

(which has no suffix) does export to

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12

with only one § sign. Then, a real multi-section citation like this:

Das ist ein Test [cite:@saenger2013gsr §§ 12 ff.].

instead yields a single §:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 ff.

This one however:

Das ist ein Test [cite:@saenger2013gsr §§ 12-14].

is correct again:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), §§ 12-14

This is a little confusing. Maybe an error on my part? Do I need to
signal singular and plural use more explicitely?

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Montag, dem 11. Oktober 2021 schrieb Bruce D'Arcus:
> Looks like § is currently mapped to the same as ¶: "paragraph", which
> is indeed incorrect.
>
> https://github.com/citation-style-language/locales/blob/0cc3885f6100e26ac6c6d103efa6f3d7195fd21b/locales-de-DE.xml#L210

This is interesting. Pandoc -- which I thought relies on these files? --
outputs the expected § sign. For

Das ist ein Test [@saenger2013gsr, § 12 Rn. 488].

it yields

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488↩

which is what I would have expected. The issue appears to be in the way
§ is interpreted in the text input.

After reading the locales-de-DE.xml file, I suspect a case of lost in
translation. In German, when read out aloud, we spell the “§” character
as “paragraph”. This is evidently different from the English speaker,
who, as I have been told, would read it out as “section”. However, in
fact the German word “Paragraph” translates to “section” in English. The
unit below it is called “Absatz” in German -- in English, it would be
“paragraph”. That is:

| English   | German| German Short form |
|---+---+---|
| Section   | Paragraph | § |
| Paragraph | Absatz| Abs.  |

At least, when it comes to legal contexts. As it always is the case with
language, meaning can vary be context. If I talk about sections of a
novel, in German it would be “Abschnitt” rather than “Paragraph”. But
that’s not something one would cite. If I really would need to cite a
novel, I would cite it either by chapter or by page number (with line
number, if necessary).

There is no symbolic sign to my knowledge to denote the unit below § in
German. The locales-de-DE.xml files suggests ¶. That might actually be
valid in some discipline, but we do not use that in jurisprudence. I do
not see a problem with it; it can be left in. What needs to change is
the part of org that maps § to CSL's "paragraph". § needs to be mapped
to "section" instead.

Long story short: I do not think that it is a bug in locales-de-DE.xml,
and I guess Pandoc proves my point here. Please map § to "section"
instead of "paragraph" in org-cite, i.e., do it the way Pandoc does it.

  -quintus


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Montag, dem 11. Oktober 2021 schrieb Nicolas Goaziou:
> Indeed. The "fix" I introduced was a mistake. I pushed a new fix.
> I think the initial issue is solved now. Could you confirm it?

Thank you so far -- we are getting closer. Now at »Org mode version 9.5
(release_9.5-102-gd0b557 @ /home/quintus/.emacs.d/org-mode/lisp/)«, the
/positioning/ is correct. What is still not correct is the character
used for the locator label. For me,

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

now (regardless of a NSBP or normal space) exports to:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), ¶¶ 12 Rn. 488

As explained, the positioning is now correct. However, instead of the
section § sign it now has two pilcrow signs ¶¶. It should be just one
sign, and it should be a section sign rather than a pilcrow one.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Sonntag, dem 10. Oktober 2021 schrieb András Simonyi:
> looks like an Org (oc-csl) side locator parsing problem to me, because
> using the alternative [cite:@saenger2013gsr para. 12 Rn. 488] form I
> seem to get the correct result. Can it be a regex matching problem
> with the paragraph symbols?

Now it’s getting wild. If I use

Das ist ein Test [cite:@saenger2013gsr para. 12 Rn. 488].

Then it exports to this:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), ¶¶ 12 Rn. 488

The locator’s position is correct, but it now has two pilcrow signs ¶
instead of one section sign §. I have never seen that in citations, but
maybe it is actually correct for other disciplines than mine.

FWIW, if I use

Das ist ein Test [cite:@saenger2013gsr line 12 Rn. 488].

it yields the correct

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), Z. 12 Rn. 488

(with "Z." being short for "Zeile", i.e. "line" in German).

So this appears to be a problem specifically with the § sign?

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Sonntag, dem 10. Oktober 2021 schrieb Nicolas Goaziou:
> Then, this may be a bug in Citeproc library itself. I suggest to report
> it upstream.

Done: https://github.com/andras-simonyi/citeproc-el/issues/57

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Sonntag, dem 10. Oktober 2021 schrieb Nicolas Goaziou:
> On the contrary, feedback on citations is very much welcome. This is
> a new features, and as such, has some rough edges.

Thanks for bearing with me.

> It is a bug. You use a non-breaking space between the locator and the
> number. I hadn't anticipated this (duh!). I fixed it. Could you confirm
> it?

Actually, I have remapped the § key to automatically always insert an
NBSP following it -- I need the § sign all the time and in normal text
line-breaking after the § violates typographic rules. Thus I did not
notice I had an NSBP there. Apologies for not mentioning this.

I however do not think the problem is related to the NBSP. I just
retried without it, and the § sign is still pulled towards the front.
I also retried with current Git (Org mode version 9.5
(release_9.5-93-gd87250 @ /home/quintus/.emacs.d/org-mode/lisp/)), but
that does not change anything. Either with the NBSP or with a normal
space, the § sign is pulled toward the front. That is,

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

Still yields:

§  Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488

Without the NBSP, that is,

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

it yields:

§ Saenger, Gesellschaftsrecht, 2. Aufl. 2013, 12 Rn. 488

Neither is correct; the § should go after the "2013, ".

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Dear all,

apologies for my frequent e-mails. It’s just that I am evaluating the
citations facility for me.

This time it’s about non-page locators. Take the following document:

#+TITLE: Test
#+AUTHOR: testauthor
#+LANGUAGE: de
#+bibliography: /tmp/mwe/mwe.bib
#+cite_export: csl /tmp/mwe/juristische-schulung.csl

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

juristische-schulung.csl is
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-schulung.csl.

This is mwe.bib:

@Book{saenger2013gsr,
  author   = {Ingo Saenger},
  title= {Gesellschaftsrecht},
  year  = {2013},
  edition   = {2},
  publisher = {Franz Vahlen},
  location  = {München},
  langid= {ngerman}}

Note how this work is not cited by page, but instead (which is common
among German judicial literature) by section number (§) plus margin number
(Rn.). Exporting this e.g. to HTML yields in Footnote 1:

§  Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 12 Rn. 488

That is rather unexpected. It has pulled the § sign in front of the
citation. The citation should have looked like this:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488

If I replace the citation in the document with

Das ist ein Test [cite:@saenger2013gsr p. 245].

then it produces the expected

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), 245

(the page locator label, "S." in German, is intentionally suppressed by
the CSL style, so this is not a bug. However, the § locator has to
appear and is not suppressed by the CSL style).

If I export with the default "bare" processor, the citation comes out
fine as "(Ingo Saenger, 2013 § 12 Rn. 488)".

I conclude from this that org somehow mistreats the locator if it is not
a page number. I used org 9.5 from MELPA and Citeproc.el from commit
34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab.

Is it a bug or (again) my error?

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: Locale specific adaptions?

[M . ‘quintus’ Gülker]

Am Freitag, dem 08. Oktober 2021 schrieb Nicolas Goaziou:
> Meanwhile, the `csl' processor is copiously documented in the
> "Commentary" section of the "oc-csl.el" file.

Thanks for the heads-up. Next time I will take a look there as well.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Citations: Locale specific adaptions?

[M . ‘quintus’ Gülker]

Am Freitag, dem 08. Oktober 2021 schrieb Nicolas Goaziou:
> I think you need to provide locales in addition to the style file, see
> `org-cite-csl-locales-dir'.

That resolved the problem! Thank you (and Bruce). I cloned
https://github.com/citation-style-language/locales and set
`org-cite-csl-locales-dir' to the repository's directory.

I agree with Bruce that this should be mentioned in the manual,
including a pointer to the aforementioned Git repository, because I
needed to find that one on my own.

Thanks again!

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Citations: Locale specific adaptions?

[M . ‘quintus’ Gülker]

Dear list,

CSL has a concept of locales, where things like specific terms or the
date format are drawn from locale files (see
https://docs.citationstyles.org/en/1.0.1/specification.html#locale). I
am not entirely sure if this is supported yet by the new citations
functionality. Take this test document test.org:

#+TITLE: Test
#+LANGUAGE: de
#+AUTHOR: Testauthor
#+bibliography: /tmp/test/test.bib
#+cite_export: csl /tmp/test/juristische-zitierweise.csl

Das ist ein Test. [cite: @boehme-neßler2017unscharfes-recht-digital p. 
3033] Zweiter Satz.
Noch ein Test. [cite: @akbarian2020oeffentliche-raeume]

#+print_bibliography:

Where /tmp/test/test.bib looks like this:

@Article{boehme-neßler2017unscharfes-recht-digital,
author = {Volker Boehme-Neßler},
title = {Die Macht der Algorithmen und die Ohnmacht des Rechts},
shortjournal = {NJW},
journaltitle = {Neue Juristische Wochenschrift},
year = {2017},
pages = {3031-3037},
langid = {ngerman}
}

@online{akbarian2020oeffentliche-raeume,
author = "Samira Akbarian",
title = "An einen, der vorüberfuhr",
language = "de",
date = "2020-12-14",
url = "https://verfassungsblog.de/an-einen-der-voruberfuhr/;,
urldate = "2021-01-02"
}

juristische-zitierweise.csl is a style for longer judicial works and
available from the CSL repository at 
https://github.com/citation-style-language/styles/blob/e22b8a566bad9b4c7f52720f60dd875057a5d210/juristische-zitierweise.csl.

Given that test.org spefies “#+LANGUAGE: de”, I would expect that
exporting uses the German terms and date format. However, exporting e.g.
to HTML gives this in the bibliography:

Akbarian, Samira, An einen, der vorüberfuhr, Stand: December 14,
2020, https://verfassungsblog.de/an-einen-der-voruberfuhr/
(accessed 01/02/2021).

The correctly German word “Stand” is hardcoded in
juristische-zitierweise.el, so ignore that one for a moment. Other than
that, you will notice that the date format is US English. This should
not be the case. For comparison, here is the same document in Pandoc
Markdown:

---
title: Test
author: Testauthor
lang: de
---

Das ist ein Test. [@boehme-neßler2017unscharfes-recht-digital, p. 3033] 
Zweiter Satz.
Noch ein Test. [@akbarian2020oeffentliche-raeume]

If this is exported with

pandoc -o test-pandoc.html -s --toc -C --csl=juristische-zitierweise.csl 
--bibliography=test.bib test.md

then the cited entry in the bibliography correctly reads

  Akbarian, Samira, An einen, der vorüberfuhr, Stand: 14.
  Dezember 2020, https://verfassungsblog.de/an-einen-der-voruberfuhr/
  (besucht am 02.01.2021).

You see how the date format changed for both the long and the numeric
format and how the translated string "besucht am" is used.

I am not entirely sure if this is a bug, a missing feature (if so, I
would like to request it), or a user error on my side. Please enlighten
me.

I used org 9.5 from MELPA with citeproc.el from the Git repository at
34e66583d95a8d80fb5b9f2960f3382ca0e6d3ab.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[M . ‘quintus’ Gülker]

Am Montag, dem 04. Oktober 2021 schrieb Nicolas Goaziou:
> It looks like the issue is in the Citeproc library, not in the Org
> wrapper. You may want to report it upstream.

Ah, I see. Thank you for the pointer. I created an issue ticket with a
copy of the OP here:


  -quintus


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Help requested: Support for basic Org mode support in tools outside of Emacs

[M . ‘quintus’ Gülker]

Am 04. August 2021 um 12:57 Uhr +0200 schrieb Karl Voit:
> My focus is on Emacs-independent tools, emphasizing the argument
> that Org mode is not Emacs-only and its syntax does have
> applications outside of Emacs as well because it is a well-defined
> syntax in the sense of
> https://karl-voit.at/2017/09/23/orgmode-as-markup-only/

It is an interesting post, thank you for sharing. Indeed, a list of
non-Emacs org tools would benefit org's popularity as a markup
language. Good luck with building one!

The problem with the approach you describe in this article is that the
org markup is not really separatable from org as a part of Emacs. By
setting some variables, the user is able to change the org syntax
itself and tailor it to his personal taste. The org manual even gives
a simple example for adding new TODO states at § 5.2.1:
https://orgmode.org/manual/Workflow-states.html

While this might not fall under the restriction to basic facilities,
it is perfectly possible to redefine variables that define the basic
syntax as well. If one does not like stars for heading prefixes,
it is possible change `org-heading-regexp' to whatever taste is at
hand. A more practical example (which I use myself) is adding new link
types as explained in § A.3 of the manual:
https://orgmode.org/manual/Adding-Hyperlink-Types.html

I recall from a discussion on this mailing list which I cannot seem to
find at the moment that the inseparability of org syntax and org Emacs
tooling is official position of the org developers. I think it was in
the context of registering a MIME type for org. In any case, org as a
syntax is a moving target, as the recent additions in form of
citations have shown (see 
https://blog.tecosaur.com/tmio/2021-07-31-citations.html).

Note I am not at all opposed to your quest. In fact, I would love to
have more widespread support for org so that it is easier for me to
collaborate with non-Emacs users on plain text documents. I just
wanted to point out difficulties of spreading org in the world outside
Emacs, which may be hard hard to imagine, but does exist. As an aside,
I hope that pandoc will receive support for org's new citation syntax
soon.

  -quintus

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

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 05. Mai 2021 um 14:27 Uhr -0400 schrieb Bruce D'Arcus:
> Hope that explains.

Sure, thank you! I just wanted to provide some possibly useful input.
I am not to critise these exciting efforts.

  -quintus

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

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 05. Mai 2021 um 09:46 Uhr -0400 schrieb Bruce D'Arcus:
> We found three rules:
> 
> 1. what Chicago calls "American"
> 2. what it calls "British"
> 3. French (though Denis is still confirming how these work in actual books)
> 
> The output in each, when formatting as a note:
> 
> 1. A sentence ending in a "cited quote."[1]
> 2. A sentence ending in a "cited quote".[1]
> 3. A sentence ending in a "cited quote[1]."

While I have never seen it stated authoritatively somewhere, in German
it appears to be common to use 1) if the terminal period is in the
cited source, and 2) if it is not, that is, just being exact in
quoting. As a result, both variants can occur in the same document,
because it depends on the cited source.

3) is doubtful in German. It would mean that there is a footnote 1 in
the cited source, but there is not reference for the cited source.
Correct it would have to be

4) A sentence ending in a "cited quote¹"³.

or

5) A sentence ending in a "cited quote¹".³

If the cited quote referenced by footnote 3 indeed does have a
footnote 1 in that position. That being said, I never saw such a
construction.

At least, that are the rules I recall from my school time and which I
used ever since with nobody complaining.

I wonder, can the placement of the footnote not just be left to the
author...? I have the impression that something is being
over-engineered here with the attempt to automate this, but maybe this
is just me.

  -quintus

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

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 23. April 2021 um 09:24 Uhr -0400 schrieb Bruce D'Arcus:
> It can be that not only does the space get removed, but the note mark
> is moved outside the period.
> 
> So if you have ...
> 
> Some sentence with a concluding citation [cite:@key].
> 
> ... that should end up like this:
> 
> Some sentence with a concluding citation.[1]
> 
> Aside: looking through the CSL spec, it doesn't seem this is
> documented. It obviously should be.
> 
> And I don't remember if that convention is locale-specific; e.g. if
> while that's the standard in English, it could be different in
> France.

As for German, the semantics are different. In Law discipline, in some
journals (not all) both styles can be used within the very same
document and have different meanings. That is,

> This is an example sentence, with a half-sentence following.¹

means that the citation ¹ references the entire sentence, whereas

> This is an example sentence, with a half-sentence following¹.

means that it references only the part following the comma ("with a
half-sentence following"). Normalising this into one uniform style
would be a semantic error. Not all journals handle it like that,
though. Some do prefer uniform look and glance over the semantic
difference.

  -quintus

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

Re: (Not so) Short note about citations in Org

[M . ‘quintus’ Gülker]

Hi,

Am 22. April 2021 um 01:34 Uhr +0200 schrieb Nicolas Goaziou:
> A noteworthy difference with the last merge is that I removed the
> opportunity to add some Org syntax (emphasis, sub/superscript…) in
> prefixes or suffixes. It makes the code a bit simpler. Of course, I'm
> open to discussion about this change.

I sometimes use emphasis around citations, but since my citation
styles all use footnotes, I think there should be no problem with
this. For example, I would write something like this (I hope I got the
syntax right):

This is a test sentence[fn:1].

* Footnotes

[fn:1] See e.g. [cite:@doe1993 pp. 32-35], who explicitely argues
/against/ the suggestion made by [cite:@someone1990 p. 50].

Since the emphasis markers on the word "against" are outside the two
citations, I would expect no problem here.

> WDYT?

Thank you so much for the hard work on this feature.

  -quintus

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

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Hi,

Am 12. April 2021 um 15:19 Uhr +0200 schrieb Nicolas Goaziou:
> The syntax is complete in "wip-cite-new" branch. For the record, in its
> full glory, it can look like this:
> 
>   [cite/style: global prefix; prefix -@key suffix ; ... ; global suffix]
> 
> [...]
>   - "exporting" action is trickier, because there are multiple ways to
> do the integration, and, since I'm not an implementor for citation
> processors, I don't have an accurate view about what is the best
> design. [...]
> The second mandatory function is obviously responsible for rendering
> citations. It is called with a citation object, the desired style,
> if any, and the export back-end, the full list of citations objets
> in the document, and the list of bibliography files. It should also
> return a string. Org provides a helper function to determine the
> footnote containing a citation (and its label, or number) from
> a citation object.
> 
> In the functions described above, I don't know if the arguments are
> sufficient.

The citation object will provide access to all elements of the new
cite syntax I assume, including things like key, prefix and suffix?

Several styles I am normally confronted with require crossreferencing
in citation footnotes (example: “Doe (see above Fn. 24), pp. 35-37”).
Formatting this requires access to the place where an @key first
occured in a footnote. The full list of citation objects probably
suffices for that information; on a first thought I would either use
the first citation object from that list with the @key at hand unequal
to the active citation object (if the list is in the order in which
the citations appear in the exported document, which might not match
the order in the org source) or use the citation object whose footnote
label has the lowest number and is unequal to the active citation
object (if the list is not guaranteed to be in said order). I would
prefer the former approach, because sometimes I deal with footnotes
with numbers like “4a” (a footnote inserted at a late stage in the
authoring process between footnotes 4 and 5), which defeats the
lowest-number approach.

For non-footnote-based citations, the “helper function to determine
the footnote containing a citation” should probably return nil.

  -quintus

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

Re: wip-cite status question and feedback

[M . ‘quintus’ Gülker]

Am 24. März 2021 um 09:22 Uhr -0400 schrieb Bruce D'Arcus:
> Anyone know anything else?

Not really. I would just like to say that I am eagerly watching this
thread and am earnestly curious about what will happen to wip-cite. A
proper cite system for org would be such a useful feature.

  -quintus

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

Re: Org as a book publisher

[M . ‘quintus’ Gülker]

Am 06. März 2021 um 20:34 Uhr +0100 schrieb Juan Manuel Macías:
> I would like to share here two samples of one of the most intense
> uses that I give Org Mode: for typesetting, layout and editorial
> design. [...] The samples are from a book on classical philology,
> recently published here in Spain [...]. Naturally, what acts in the
> background here is TeX and LaTeX (specifically Lua(La)TeX), so what
> I really do is use Org and Org-Publish as a sort of high-level
> interface for LaTeX. But I don't mean to avoid LaTeX: in fact, I've
> been working with LaTeX for a long time. I like LaTeX and behind
> these jobs there is a lot of LaTeX code. But Org gives me a much
> more light and productive workflow, allowing me to work at two
> levels.

Thank you very much for sharing. This is an interesting insight. Many
people seem to use org rather than direct LaTeX because they dislike
LaTeX's syntax or find LaTeX too complex, which I never really
understood. But you make some great points for why this combination is
useful other than for that reason.

> 2. Control of the composition process at various points. One of the
>qualities of LuaTeX is the possibility to control TeX primitives
>through scripts in Lua, and to act at various points in the pre- or
>post-process. But I have realized that with the happy fusion of Elisp
>and Org we can be much more precise and "surgical" ;-). Here,
>Org/LaTeX is much more powerful than LuaLaTeX.

For those who still use pdfLaTeX rather than LuaLaTeX (probably due to
Microtype) there is not even an equivalent available.

> 4. An unique origin. The book can be produced on paper from a single
>source, but you can also export, from that source consistently, to
>other formats (HTML or Epub).

This is actually a strong argument. Even though I enjoy writing LaTeX
code, this one is a tough nut to crack with pure LaTeX, where I
achieved the best results with LaTeXML, but it was still lots of work.
May I ask what tooling you use to go from org to Epub?

  -quintus

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

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 (<>) 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  | kont...@guelker.eu| () Avoid HTML e-mail
European Union   | PGP: see homepage | /\ http://asciiribbon.org

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  | kont...@guelker.eu| () Avoid HTML e-mail
European Union   | PGP: see homepage | /\ http://asciiribbon.org