Re: Org-cite (oc-csl) tip: Filtering bibliography for language

[Denis Maier]

Am 19.12.2022 um 23:20 schrieb András Simonyi:

... I've forgotten to add that another (probably more user friendly)
option would be to design and implement some kind of  filtering DSL.

András

On Mon, 19 Dec 2022 at 23:05, András Simonyi  wrote:


Dear All,

On Mon, 19 Dec 2022 at 15:49, Christian Moe  wrote:


Refinements welcome. I'm especially wondering what would be an elegant
way to generalize this for more languages without defining a predicate
for each language (given that we cannot pass the language as an
additional argument in the print_bibliography line).


Thanks for describing this usage! As for the problem of generalizing
to more languages, one relatively simple solution would be to allow
arbitrary sexps as filters. Then one could write something like

#+print_bibliography: :filter (lambda (item) (bibitem-has-language item "en")))

Would this type of extension be helpful? One (not necessarily
important)  consequence would be that filters of this type would be
obviously unusable with the biblatex exporter.

best wishes,
András


I'd say both options are certainly useful. A filtering DSL is surely the 
more user friendly option, but allowing lambda expressions would 
probably be quicker to implement, and it would also allow for predicates 
not anticipated by DSL designers.


Best,
Denis

Re: Include LaTeX source and compiled result

[Denis Maier]

Am 09.06.2022 um 09:47 schrieb Fraga, Eric:

On Wednesday,  8 Jun 2022 at 21:01, Denis Maier wrote:

:exports code works. But the problem with the other options is that the
compilation fails. But I cannot tell why. It just tells me "Code block
produced no output".

This is not surprising as the LaTeX src blocks are expected to be LaTeX
body only, not preamble etc.  I.e. in your case, just the line that says
"This is a test".  You may wish to look at org-format-latex-header,
org-babel-latex-preamble, org-babel-latex-end-env, ...


Exactly, I've found that out by looking at the file in temp. Testing 
with body only failed as well! I can however manually compile the 
temporary file.


Anyway: This means you cannot switch to using complete files? I was 
hoping for something like

:fragment nil
or
:complete-doc t




How can you diagnose such an issue?

You can sometimes find the org babel files created in /tmp.


Anything else? I've found those files, but I was wondering whether Emacs 
could give me some more useful debug infos? (Especially since compiling 
the temporary files works...)


Denis

Re: Include LaTeX source and compiled result

[Denis Maier]

Am 08.06.2022 um 10:28 schrieb Fraga, Eric:

On Wednesday,  8 Jun 2022 at 09:43, Denis Maier wrote:

However, I cannot manage to get this to work:

If you want to show the LaTeX, you need to add ":exports code" to the
src block, or ":exports both :results file" if you want to show both
code and the resulting PDF.



:exports code works. But the problem with the other options is that the 
compilation fails. But I cannot tell why. It just tells me "Code block 
produced no output".


How can you diagnose such an issue?

Re: Include LaTeX source and compiled result

[Denis Maier]

Hmmm, even this tells me "Code block produced no output"

#+begin_example
Test

#+begin_src latex :file asdf.pdf
Blabla
#+end_src

#+RESULTS:
#+begin_export latex
#+end_export

Test
#+begin_example

But I can compile the temporary tex file without problems.
I'm probably missing something fundamental...

Best,
Denis

Am 08.06.2022 um 09:43 schrieb Denis Maier:

Hi everyone,

for the documentation of my LaTeX courses I use examples that show the 
output next to the source code. I'm contemplating whether I should 
convert the documentation and examples to org, and use org-babel to 
include the examples. I think this should be possible with org-babel.


However, I cannot manage to get this to work:

#+begin_example

Blabla

#+begin_src latex :file test.pdf
\documentclass{article}
\begin{document}
This is a test
\end{document}
#+end_src

Blabla

#+end_example

Looking at the temporary latex file (see below) the reason is clear: 
Org babel exports this as a complete latex file although the example 
itself is already complete. Can I tell org somehow that this is not a 
fragment and should be compiled as is?


Best,
Denis

\documentclass{article}
\usepackage[usenames]{color}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\setlength{\textwidth}{\paperwidth}
\addtolength{\textwidth}{-3cm}
\setlength{\oddsidemargin}{1.5cm}
\addtolength{\oddsidemargin}{-2.54cm}
\setlength{\evensidemargin}{\oddsidemargin}
\setlength{\textheight}{\paperheight}
\addtolength{\textheight}{-\headheight}
\addtolength{\textheight}{-\headsep}
\addtolength{\textheight}{-\footskip}
\addtolength{\textheight}{-3cm}
\setlength{\topmargin}{1.5cm}
\addtolength{\topmargin}{-2.54cm}
\begin{document}
\documentclass{article}
\begin{document}
This is a test
\end{document}
\end{document}

Include LaTeX source and compiled result

[Denis Maier]

Hi everyone,

for the documentation of my LaTeX courses I use examples that show the 
output next to the source code. I'm contemplating whether I should 
convert the documentation and examples to org, and use org-babel to 
include the examples. I think this should be possible with org-babel.


However, I cannot manage to get this to work:

#+begin_example

Blabla

#+begin_src latex :file test.pdf
\documentclass{article}
\begin{document}
This is a test
\end{document}
#+end_src

Blabla

#+end_example

Looking at the temporary latex file (see below) the reason is clear: Org 
babel exports this as a complete latex file although the example itself 
is already complete. Can I tell org somehow that this is not a fragment 
and should be compiled as is?


Best,
Denis

\documentclass{article}
\usepackage[usenames]{color}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\pagestyle{empty} % do not remove
% The settings below are copied from fullpage.sty
\setlength{\textwidth}{\paperwidth}
\addtolength{\textwidth}{-3cm}
\setlength{\oddsidemargin}{1.5cm}
\addtolength{\oddsidemargin}{-2.54cm}
\setlength{\evensidemargin}{\oddsidemargin}
\setlength{\textheight}{\paperheight}
\addtolength{\textheight}{-\headheight}
\addtolength{\textheight}{-\headsep}
\addtolength{\textheight}{-\footskip}
\addtolength{\textheight}{-3cm}
\setlength{\topmargin}{1.5cm}
\addtolength{\topmargin}{-2.54cm}
\begin{document}
\documentclass{article}
\begin{document}
This is a test
\end{document}
\end{document}

Re: Abbreviations support

[Denis Maier]

Hi Timothy,
thanks for looking into this. A package "org-abbreviations" or so would 
be truly awesome. Have you had a chance to look into a MVP? Let me know 
if I can help somehow.

Best,
Denis

Am 04.06.2022 um 12:09 schrieb Timothy:

Hi Denis,


Is there support for abbreviations in org-mode? Something like what the acro
package provides for latex, i.e., assemble a list of all used abbreviations, use
a full form when an abbreviation is used for the first time, the abbreviated
form afterwards. If that does not exist: What would be a good way to approach
that?

Not directly, but I think you could do something like this as a halfway-house:

┌
│ Blah blah text ABBR
│
│ * Abbreviations
│
│ - <<>> :: Some abbreviation
│ ...
└

I’d think there’s scope for a package say “org-abbreviations” which provides
acro-like support. Perhaps even support for a central abbreviations file. Hmm, I
may think of trying a small MVP for that this weekend.

All the best,
Timothy

Re: Abbreviations support

[Denis Maier]

Thanks for the hint!
Denis

Am 04.06.2022 um 18:11 schrieb John Kitchin:

Org-ref supports this for glossaries and acronyms. See
https://youtu.be/sebs2vSIEk4 For an overview.


On Sat, Jun 4, 2022 at 6:13 AM Timothy  wrote:

Hi Denis,

> Is there support for abbreviations in org-mode? Something like
what the acro
> package provides for latex, i.e., assemble a list of all used
abbreviations, use
> a full form when an abbreviation is used for the first time, the
abbreviated
> form afterwards. If that does not exist: What would be a good
way to approach
> that?

Not directly, but I think you could do something like this as a
halfway-house:

┌
│ Blah blah text ABBR
│
│ * Abbreviations
│
│ - <<>> :: Some abbreviation
│ ...
└

I’d think there’s scope for a package say “org-abbreviations”
which provides
acro-like support. Perhaps even support for a central
abbreviations file. Hmm, I
may think of trying a small MVP for that this weekend.

All the best,
Timothy

--
John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Abbreviations support

[Denis Maier]

Hi everyone,
is there support for abbreviations in org-mode? Something like what the 
acro package provides for latex, i.e., assemble a list of all used 
abbreviations, use a full form when an abbreviation is used for the 
first time, the abbreviated form afterwards. If that does not exist: 
What would be a good way to approach that?

Best,
Denis

Re: citations: org-cite vs org-ref 3.0

[Denis Maier]

Am 29.03.2022 um 18:14 schrieb Bruce D'Arcus:

On Tue, Mar 29, 2022 at 11:23 AM Max Nikulin  wrote:
...


You even have managed to convince me that, besides adding missing style
names, some existing ones should be adjusted. noauthor/bare for citeyear
example makes for me much more sense ...


This does need some attention, but there are wrinkles here.

Citeyear is specific to author-date styles, while noauthor is intended
to be more general.


Anyway citation style is rather specific for a particular CSL style. I
tried some styles:
https://github.com/citation-style-language/styles/blob/master/ieee.csl
https://github.com/citation-style-language/styles/blob/master/american-physics-society.csl
nature.csl science.csl and for all these styles even "author" is
meaningless since they are numeric styles.


Yes. I think it's more relevant in author-date to note styles. I
believe biblatex has a command relevant here, but Denis knows biblatex
better than I.


I'm not sure I understand the question here. What command should be in 
biblatex? There's \citeauthor if that's what you've meant.





So it is not more general. Switching CSL style means necessity to update
styles in each citations (unless it is possible to specify global or
per-cite mapping).


Not really. Arguably the most important style is "text", which applies
to any output style; author-date, note-based, numeric.

When you start getting into some of the others, the range of styles a
given style may apply to shrinks.

But you might say author-date styles are pretty dependent on such
local citation modification. If those are output to a style that has
no such notions (like a numeric one), then a processor can just ignore
it.


Just to add to this: When Bruce and I have worked on that list of styles 
we found that portability can only be ensured when using high-level 
commands (such as biblatex's autocite), but once you start using 
low-level commands like citeyear etc. you really lose that portability 
to a certain degree.





It seems modifiers are set of boolean flags (positive "year" or negative
"suppress-author") in citeproc.el, set of values in natbib, and a kind
of hierarchy in org-cite. From my point of view, set of constrains
(flags) is the most general variant in this list.


I think that's right, and is how it's represented in a GUI app like
Zotero. But that's not so convenient in a plain text format.

But it's a good way to explain the differences.


I think it's probably a good idea to add "year" to the latex processors too.


I agree. Negations are more confusing when an author needs just year.


Well, negations have the advantage of being more portable. Say you have 
this:


Doe argues X and Y [cite/noauthor:@doe].

It's perfectly clear what this should mean in a author-year, 
author-title or note-based styles, i.e., print the citation without the 
author element. (That's obviously a simplification since some citations 
might not have an author element, but let's just go with it for the moment.)


In a numeric style you can just ignore the noauthor modifier and fall 
back to the default numeric citation.


Now, consider this instead:

Doe argues X and Y [cite/year:@doe].

This might work in author-year styles, but not in author-title, not in 
note-based styles, and not in numeric styles.


Considering the problem that some citations don't have an author element 
I even considered using style names like



[cite/head:@doe]
[cite/tail:@doe]
or
[cite/car:@doe]
[cite/cdr:@doe]
or
[cite/first:@doe]
[cite/rest:@doe]

But that obviously a bit esoteric.

Denis

Re: Configuring ox-context

[Denis Maier]

What do you think about using context's structurelevels instead? That 
would allow users to define their own mappings.


Denis

Am 23.12.2021 um 08:24 schrieb juh:

Am Mittwoch, dem 22.12.2021 um 10:37 -0800 schrieb Jason Ross:


Thank you for bringing this up. I'd like to discuss this a bit with
you
before implementing such a feature.

I'm not sure how an implementation of this would look to the end
user.
ConTeXt has the following system:
https://wiki.contextgarden.net/Command/_section

\part   highest level of sectioning
\chapterlevel 2
\sectionlevel 3
\subsection level 4
\subsubsection  level 5
\subsubsubsection   level 6
\subsubsubsubsectionlevel 7
\title  level 2, unnumbered
\subjectlevel 3, unnumbered
\subsubject level 4, unnumbered
\subsubsubject  level 5, unnumbered
\subsubsubsubject   level 6, unnumbered
\subsubsubsubsubjectlevel 7, unnumbered


So there are a couple of questions that need to be answered:

1. There's no "level 1, unnumbered" sectioning command in ConTeXt.
     How should this be handled?
2. How does the user specify which sectioning scheme to use?

Question (1) implies that the user may need to choose their highest
level to be either a part or a chapter in order to have unnumbered
level 1 sections. Things start to get complicated if we do that.


I think that the scheme is conventional, and grown up with books and
LaTeX we are accustomed to it. The chapter-title scheme seems to be
from ConTeXt and I don't know the real reason behind this.

For me the part-chapter-section line is the book oriented sectioning
(with or without numbering) as books can have parts, often have
chapters and sometimes sections.

The title-subject line is the magazine oriented line, because articles
in  a magazine or essays in a collection only have titles and subjects,
and they are complete units which could be published elsewhere.

(Sometimes I use titles to mark special chapters that don't appear in
the table of contents.)

I don't think that what we do is always logical and consistent in
itself. But it might be a good memory hook to organize different items
such as books with chapters, articles and independent essays collected
in a book.

To get a broader view on this, we should discuss it in the ConTeXt
mailinglist.

I am deploying a production chain with Markdown-Pandoc-ConTeXt in my
organization. AFAIK Pandoc only produces the part-chapter-section line
while the highest level is configurable. So if we ever need a title-
subject scheme we will have to use filters.


To avoid these questions, I went with the simplest implementation
possible and just concatenated "sub"*n with either "section" or
"subject" to create a sectioning command of depth n.

My understanding is that the sectioning commands are flexible enough
that any desired result in the output pdf can be produced by
modifying
the sectioning commands in the preamble. However, if you are using
existing environments that rely on those specific names you are out
of
luck.



Yes I think they are flexible enough and I can customize my styles, but
I would prefer to have a solution which can be used with the usual
sectioning of ConTeXt.

My proposal would be

1.) to have a switch for using
(a) the part-chapter-section line or
(b) the title-subject-line on export.

2.) to have a customization for (a) similiar to pandocs "top-level-
division"




For your purposes, if you need a fix _right now_, consider overriding
the definition of `org-context--get-headline-command` to something
like this:

#+begin_src elisp
(defun org-context--get-headline-command (headline info)
    "Create a headline name with the correct depth.
HEADLINE is the headline object. INFO is a plist containing
contextual information."
    (let* ((level (org-export-get-relative-level headline info))
   (numberedp (org-export-numbered-headline-p headline info))
   (hname
    (cond
     ((and (= 1 level) numberedp) "chapter")
     ((= 1 level) "title")
     (t (let ((prefix (apply 'concat (make-list (+ level (-
2))
"sub")))
  (suffix (if numberedp "section" "subject")))
  (concat prefix suffix)
   (notoc (org-export-excluded-from-toc-p headline info)))
  (if notoc
  (format "%sNoToc" hname)
    hname)))
#+end_src



Thanks a lot. I will try this the next days.




This is fixed on the "develop" branch as of today. I missed a
comma...


Great.

juh

Re: Org-syntax: Intra-word markup

[Denis Maier]

Hi Tom

Am 04.12.2021 um 18:53 schrieb Tom Gillespie:

Hi all,
 After a bunch of rambling (see below if interested), I think I have
a solution that should work for everyone. The key realization is that
what we really want is the ability to have a "parse me separately"
type of syntax. This meets the intra-word syntax needs and might
meet some other needs as well.

The solution is to make @@org:...@@ "parse me separately"
block! It nearly works that way already too! To minimize typing
we could have @@:...@@ the empty type default to org.

This seems like a winner to me. The syntax for it already exists
and won't conflict. It requires relatively minimal additional typing
the implication is clear, and there are other places where such
behavior could be useful.

This syntax seems like a winner to me
@@org:/hello/@@world
@@:/hello/@@world

You can also do things like
#+begin_src org
I want a number in this number@@org:src_elisp{(+ 1 2)}@@word!
#+end_src

Which would render to
#+begin_src org
I want a number in this number3word!
#+end_src

Thoughts?

Best!
Tom



Thanks for the suggestion. I think that sounds like a good idea. Of 
course not as terse as the asciidoc inspired suggestion, but entirely 
appropriate for a case like this one! I also like that there might be 
other cases where case might be handy.


Best,
Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 03.12.2021 um 15:24 schrieb Max Nikulin:

On 03/12/2021 02:03, Nicolas Goaziou wrote:

Denis Maier writes:


As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?


I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous situations.


I suppose, some more general solution is required.


I do think the marker + zero-width space is one way to go. We could, as
an improvement, consider zero-width spaces around emphasis markers to be
part of the markup, and replace them along during export.


Zero-space characters adjacent to emphasis markers is a better idea than 
replacing any zero space. However I agree with Juan Manuel that white 
space characters, especially completely invisible (I am not Eli who sees 
such special characters by moving cursor through them) should not be 
overloaded. From my point of view, it is acceptable to use zero width 
spaces as a workaround but they should not become official part of Org 
syntax.



Another solution is to introduce a less-subtle, but less prone to
ambiguity, syntax, e.g.,

   /{bold}/markup   or   /|bold|/markup

where /{ }/  or /|  |/ become "extended" markers.


More explicit markup leaves less room for ambiguities, and I like the 
idea due to this reason. On the other hand it diverges from principle of 
lightweight markup. The almost only special character in TeX is "\", 
HTML has three ones "&<>" with simple escape rules. Org uses many 
special characters to avoid verbosity and requires some tricks to escape 
them. Markers like "\{" make Org more verbose but do not make it more 
strict, a lot of things still rely on heuristics.


I have an idea what can be done when some special markup is required 
that is not fit into current syntax. Unfortunately some new constructs 
should be introduced anyway: inline objects and multiline elements that 
represent simplified result of parsed Org structures:


     ((italic "intra") "word")

wrapped with some markup. It should satisfy any special needs (and even 
should allow to create invalid impossible constructs). Maybe idea of 
combination of lightweight markup and low-level blocks better suits for 
some other project with more expressive internal representation. In Org 
it may become the most hated feature.


I have to admit I like this idea. That brings a lot of flexibility to 
accomodate even the most obscure needs, yet it makes the discussion 
about escape characters or new symbols much less pressing. After all, 
most markup languages face the same problem, i.e., special characters 
are limited, and beyond the usual /*_ the meaning of characters becomes 
much less obvious.


This idea reminds me a bit of Scribble/Racket where every document is 
just inverted code, which makes it possible to insert arbitrary Racket 
code in your prose...


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 19:11 schrieb Tom Gillespie:

I don't mean to be a wet blanket, but the edge cases for
the current markup syntax are already hard enough to
implement correctly, to the point where different parts of
Org mode are inconsistent. Intra-word markup isn't viable
because there simply isn't any sane way to parse something
like *hello world*/hrm/oh no*. The other issue is that this will
degrade parsing performance because almost every
character could precede the start of a markup section.

I recommend anyone suggesting solutions try to implement
something that can parse the markup unambiguously with
lots of nasty test cases. You will likely find that it is impossible
to consistently tokenize markup, and that you have to hand
write a whole bunch of heuristics, making Org syntax even
harder to implement correctly.

Any solution that suggests extending how =/*~+_  can be
used gets a hard no from me. I could see teaching other
exporters how to interpret \emph{hello}world, but trying for
to have any sane behavior for something like
why *hello*world oh no a wild askterisk*
is not worth it.


As I've said before, I could well live with \emph{what}ever or something 
similar.


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 14:14 schrieb Juan Manuel Macías:

Ihor Radchenko writes:


Denis Maier  writes:


Can you create an example of such scenario and post it as a bug?
Probably, we just need to strip all zero-width spaces at the basic ox.el
level.

To be clear: That's not an org bug. It's just that latex won't be able
such a word. If | is a zero width space, the word "hyphen|ation" is not
the same as "hyphenation".
1. hyphenation
2. hyphen|ation

You are right for your example, but if we force the user to put
*hyphen*|ation to create bold emphasis, it should not be any different
compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the*hyphen*|ation
gets exported as \textbf{hyphen}|ation keeping the zero width space.
-- I would say that they are very random cases, and therefore 
difficult to reproduce. In the 'hyphenation' example, if we load the 
package showhypehns, you see that: /hyphen/​ation (with zero width sp) 
and \emph{hyphen}ation they are cut in the same way. But differently 
from hyphenation (without emphasis) (compiled with LuaTeX). Anyway, I 
have come across some curious cases. For example, a long time ago I 
had defined a macro for text in other languages: #+MACRO: lg (eval (if 
(org-export-derived-backend-p org-export-current-backend 'latex) 
(concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 
"\u200B" "@@latex:}@@") $2)) I needed to add before and after a zero 
width space, but doing so, the shape of the text was altered. That can 
be reproduced with this example: #+LaTeX_Header: 
\usepackage{showhyphens} #+LaTeX_Header:\usepackage{lipsum,multicol} 
#+LaTeX_Header:\usepackage[spanish]{babel} #+LaTeX_Header: 
\def\example{\lipsum[1]} #+LaTeX_Header: \def\zwsp{\char"200B{}} 
#+OPTIONS: toc:nil @@latex:\begin{multicols}{2}@@ 
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@ 
@@latex:\foreignlanguage{italian}​{\example}@@ 
@@latex:\end{multicols}@@ Best regards, Juan Manuel


Thanks Juan Manuel. I should have tried that first. Hyphenation is the 
same for both /hyphen/​ation (with zero width sp) and 
\emph{hyphen}ation. (Maybe I can nudge Hans Hagen to add some low level 
trickery in context that removes the groups before doing the 
hyphenation... but that's a different story.) Anyway, as Juan Manuel 
shows there can be cases where zero width spaces cause problems.


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:10 schrieb Ihor Radchenko:

Denis Maier  writes:


Just a furter remark: while zero-width-spaces can be used as a
workaround, they may create problems in some export formats. E.g., they
will mess up hyphenation in latex. I think if read somewhere that those
can be removed with hooks or filters, but I think that shouldn't be
necessary.

Can you create an example of such scenario and post it as a bug?
Probably, we just need to strip all zero-width spaces at the basic ox.el
level.
To be clear: That's not an org bug. It's just that latex won't be able 
such a word. If | is a zero width space, the word "hyphen|ation" is not 
the same as "hyphenation".

1. hyphenation
2. hyphen|ation


Best,
Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:00 schrieb Ihor Radchenko:

Juan Manuel Macías  writes:


intra-*word* works just fine for me.


I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

I see. We had a discussion about emphasis issues in
https://orgmode.org/list/8735nnq73n.fsf@localhost

The conclusion from there is that supporting such scenarios will
introduce various edge cases. We would need to make the emaphsis parser
more and more complex inevitably introducing errors.

Thanks, I'll try to read that thread in due time.


An alternative may be some kind of "forced" emphasis syntax where Org
does not have to guess about the emphasis using non-transparent rules.
But it's what zero width space is for and it is what we recommend in the
Org manual.

As for the forced syntax. What do you think about the asciidoc solution?

Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:08 schrieb Eric S Fraga:

My solution, in these case, is to fall back to LaTeX using @@latex:...@@
(and equivalent for HTML, if desired).  Not pretty but I need this so
seldom that I am happy with the org emphasis support generally.


Hi Eric,

Am 02.12.2021 um 13:08 schrieb Eric S Fraga:

My solution, in these case, is to fall back to LaTeX using @@latex:...@@
(and equivalent for HTML, if desired).  Not pretty but I need this so
seldom that I am happy with the org emphasis support generally.

This works if your target is just latex, but not if you have multiple 
targets, right?


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Hi Timothy,

Am 02.12.2021 um 12:58 schrieb Timothy:

Hi Denis,


Currently, org syntax doesn’t officially seem to support intra-word emphasis. Am
I missing something?

I’d describe it as supported via-zero width spaces.

You may be interested in 
.

Thank's that's helpful.



If the assessment is correct: Is there a reason for this? And, shouldn’t that
be officially added?

Do you happen to have any ideas on how this could be achieved? I’d rather not
resort to having to do things like `\ast{}' and `\tilde{}' too much.


Well, not really. I just don't understand why /intra/word shouldn't mean 
\emph{intra}word. Pandoc's markdown supports *intra*word, asciidoc 
supports it via unconstrained formatting pairs: 
https://docs.asciidoctor.org/asciidoc/latest/text/#unconstrained; so 
__intra__word.
And, as org syntax is said to be the superior markup language, I thought 
that must be possible ;-)


I understand zero width spaces are the official workaround, but I don't 
really like having invisible characters in my documents. Automatically 
removing all of them on export might also introduce problems. Perhaps 
some have been added on purpose, and not just to help org?


As for suggestions: If just using /intra/word creates ambiguities, what 
about the asciidoc solution? So //intra//word?
In fact, I'd even use raw latex for this things. It's true, they are 
rare enough. So I wouldn't mind an occassional `\emph{}`.


Best,
Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 12:42 schrieb Marco Wahl:

Hi!


Currently, org syntax doesn't officially seem to support intra-word
emphasis. Am I missing something?


intra-*word* works just fine for me.

Best,
Ihor


I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.


Is there a recommended way to insert a zero with space?

BTW occasionally I use

(defun mw-insert-zero-width-whitespace ()
  "Insert a space with zero width."
  (interactive)
  (insert ?\x200B))


Thanks and ciao,


Just a furter remark: while zero-width-spaces can be used as a 
workaround, they may create problems in some export formats. E.g., they 
will mess up hyphenation in latex. I think if read somewhere that those 
can be removed with hooks or filters, but I think that shouldn't be 
necessary.


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Yes, Juan Manuel. That's it.

See for reference: 
https://stackoverflow.com/questions/1218238/how-to-make-part-of-a-word-bold-in-org-mode


Best,
Denis

Am 02.12.2021 um 12:30 schrieb Juan Manuel Macías:

Hi Denis and Ihor,

Ihor Radchenko writes:


Denis Maier  writes:


Currently, org syntax doesn't officially seem to support intra-word
emphasis. Am I missing something?

intra-*word* works just fine for me.

Best,
Ihor

I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

Best regards,

Juan Manuel

Org-syntax: Intra-word markup

[Denis Maier]

Hi everyone,

while we're at discussing org syntax anyway, I thought it's time to 
bring up another syntax question:
Currently, org syntax doesn't officially seem to support intra-word 
emphasis. Am I missing something?
If the assessment is correct: Is there a reason for this? And, shouldn't 
that be officially added?


Best,
Denis

Re: [ANN] ox-pandoc, revived

[Denis Maier]

Am 30.11.2021 um 09:40 schrieb Alex Fenton:

Hello,

ox-pandoc is an exporter for Org Mode that uses pandoc 
(https://pandoc.org/) to export to a very wide variety of text markup 
(e.g. markdown variants), document (ODT, docx) and presentation (e.g. 
html, .pdf) formats. It is available via MELPA and at: 
https://github.com/emacsorphanage/ox-pandoc


pandoc handles almost all org text-markup features and offers many 
options for controlling output. With ox-pandoc, it can also be used with 
Org Mode's code evaluation.


ox-pandoc was originally created by kawabata, but had fallen out of step 
over the past few years with recent pandoc and Org Mode versions. As a 
result, it had a number of serious bugs. Current releases roll up a 
dozen or so fixes and enhancements and with the kind help of the MELPA 
team, the package is now distributed from a maintained repo.


The current version includes initial support for org citations in Org 
9.5. This feature is experimental and I welcome feedback and reports on 
this or any other aspect of the package.


best

alex



That's great. Thank you.


Regarding citations and 
https://github.com/emacsorphanage/ox-pandoc#alternative-using-pandoc-citation-syntax: 
There are also plans to support the new org cite citation syntax on the 
pandoc side of things. This might make some things easier in the future.


Denis

Re: [org-cite] autoload oc processors?

[Denis Maier]

Am 29.11.2021 um 23:48 schrieb Nicolas Goaziou:

Hello,

Timothy  writes:


A more sophisticated solution probably exists, but my thought was that if a cite
export keyword like this is seen:
┌
│ #+cite_export: FORMAT ...
└

and there is no known cite backend `FORMAT', then we could just try running
┌
│ (require 'oc-FORMAT nil t)
└

before complaining that there’s no cite backend FORMAT loaded.

This relies on consistent naming, but since that seems to hold pretty well so
far and failure to load just results in the current behaviour, I’m inclined to
think this would be a good change in terms of user experience.


OK. I implemented this on main branch. We'll see how it goes.



Thanks, that sounds like a good change!
Best,
Denis

Re: Bibliographies on export with ox-context and ox-epub

[Denis Maier]

Am 24.11.2021 um 10:32 schrieb juh:

[...]



Thanks a lot but I get:

Unknown processor csl

What happens after this?

M-: (require 'oc-csl)

Will this evaluate or do you get an error message?

Denis

Re: Bibliographies on export with ox-context and ox-epub

[Denis Maier]

Am 24.11.2021 um 10:59 schrieb Colin Baxter :

Denis Maier  writes:

 > Are you already on org 9.5? Looks like your still using the "old"
 > org-ref links.

 > The following mwe might get you started:

 > %%

 > #+title: Citation tests #+cite_export: csl

 > #+bibliography: test.bib

 > [cite: @doe 45]

 > [cite/text: @doe 45]

 > #+print_bibliography:
 > %%

 > This will use the new citation export framework. citeproc-el needs
 > to be installed for this to be working.

Where is citeproc.el? I'm using Org mode version 9.5.1
(release_9.5.1-194-gd82936) and I don't see it.

Best wishes,


You'll need to install it. It's an independent package.

Denis

Re: Bibliographies on export with ox-context and ox-epub

[Denis Maier]

Are you already on org 9.5? Looks like your still using the "old" 
org-ref links.


The following mwe might get you started:

%%
#+title: Citation tests
#+cite_export: csl
#+bibliography: test.bib

[cite: @doe 45]

[cite/text: @doe 45]

#+print_bibliography:
%%

This will use the new citation export framework. citeproc-el needs to be 
installed for this to be working.


Anyway, I can export this to plain text, html, and latex without 
problems. I have not yet tried out the context exporter, but I don't see 
why it should not work there as well.


In case you haven't seen it already: 
https://blog.tecosaur.com/tmio/2021-07-31-citations.html


Best,
Denis

Am 24.11.2021 um 08:22 schrieb juh:

Hi all,

I am kind of lost with references and ox-context and ox-epub.

Is there a tutorial how to integrate a bibliography in ConTeXt and
epub-Export?


What I want to achieve is to use a bibtex bibliographies with org-roam and
export them to epub and ConTeXt to generate bibliographies in the output.

The first wish kind of works as I can insert entries from the bibtex file with 
C-].

They look like this:

Nam a sapien.[[cite:@horkheimer_dialektik_1984]]

This is the org-ref entry in settings.org.

   (straight-use-package 'org-ref)
   (with-eval-after-load "org-ref"
   (setq reftex-default-bibliography '("~/org/bibliography.bib")))

   (setq bibtex-completion-bibliography '("~/org/bibliography.bib")
 bibtex-completion-library-path '("~/org/bibtex-pdfs/")
 bibtex-completion-notes-path "~/org/notes/"
 bibtex-completion-pdf-open-function
 (lambda (fpath)
   (call-process "open" nil 0 nil fpath)))

   (define-key org-mode-map (kbd "C-c ]") 'org-ref-insert-link)


What puzzles me is that I could not find a hint to create a bibliography
for epub export and context export. Maybe there isn't. But as some
things with references does not work in my setup I fear that my
configuration is not working. I take snippets from the documentations of
the packages.

I miss an overall example or tutorial for note taking via org-roam and
exporting to epub and ConTeXt.

So for now my current publishing workflow is split into two.

1. Zettelkasten via org-roam

2. PDF and epub creation via pandoc and cite-proc.

As you can see there is a break of tools, so I would like to avoid this.

TIA
juh

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Am 01.10.2021 um 10:42 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


So, you're suggesting that locator parsing algorithm should be ported
to oc-biblatex instead?

That's a possibility. It can be factored out from oc-csl.el and become
a generic tool living in oc.el, if deemed useful. The algorithm can trip
over locators involving letters, tho (e.g., "chap. xiv, xv and xvi").
I don't know if that's common.
Not so much for chapters, but it happens quite a lot for page numbers in 
prefaces and introductions.


Moreover this is but one side of the problem. Naively, I thought that
BibLaTeX would take care of parsing the locator. Since that's not the
case, oc-biblatex needs additional code to properly deal with it.
Yes, that's the issue. In biblatex you will want to enclose the locator 
with \pnfmt{}. (Or use either the \pno or the \ppno command as a prefix.)


Best,
Denis

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Am 30.09.2021 um 09:23 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Well, there are even cases like this one:

[cite:@doe especially 4, 12, and 15]

[cite:@doe e.g. 4, 12, and 15]

[cite:@doe among others 4, 12, and 15]

[cite:@doe 4, but also 12 and 15]

AFAIU, all these cases are already handled by the locator parsing
algorithm used in oc-csl.el. If that is correct, my point is still the
same: there are very few cases where an explicit locator delimiter would
be necessary.


So, you're suggesting that locator parsing algorithm should be ported to 
oc-biblatex instead? That would obviously be a neat solution.

If so, I can provide a couple of examples so we can see if that could work.

Denis

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Am 25.09.2021 um 16:48 schrieb Bastien:

Hi Denis,

Denis Maier  writes:


Bump.

Can you propose a patch for this?

I would have already done if I knew how to do this.
That's maybe a nice elisp exercise so I'll have look, but I fear that's 
way beyond my capabilities, and probably something Nicolas might want to 
have a look at.




Also see
https://orgmode.org/worg/org-mailing-list.html#i-didnt-receive-an-answer
where we ask contributors to wait at least one month before bumping a
thread (thanks!)
Oh, didn't know that. Sorry. (Other lists have a "wait one week before 
bumping"-policy, and I assumed that to be the case here as well...)


Denis

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Am 29.09.2021 um 08:30 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


That won't work if you have more than one reference in a citation?

[cite:@doe 4, with some more text; @jones]

No, that won't work with more than one reference in a citation. But
this, coupled with the simple locator parsing done in oc-csl.el should
be enough in the vast majority of the cases, shouldn't it?

Well, there are even cases like this one:

[cite:@doe especially 4, 12, and 15]

[cite:@doe e.g. 4, 12, and 15]

[cite:@doe among others 4, 12, and 15]

[cite:@doe 4, but also 12 and 15]

Best,
Denis

Re: Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Bump

Am 08.09.2021 um 15:37 schrieb Denis Maier:

Hi,

I think the suffix parsing in oc-biblatex could be improved. Consider 
this example:



#+cite_export: biblatex authoryear

[cite:@doe 4]

[cite:@doe 4, with some more text]
=

This gives us
=
\autocite[4]{doe}

\autocite[4, with some more text]{doe}
=

The problem is  that biblatex will add a label if the suffix consists 
only of a number, a range of numbers, or a list of numbers. So 
\autocite[4]{doe} will result (Doe 2021, p. 4). However, \autocite[4, 
with some more text]{doe} results in (Doe 2021, 4, with some more text). 
In this special case you'd have to help biblatex:

\autocite[\pnfmt{4}, with some more text]{doe}
=> (Doe 2021, p. 4, with some more text)

FWIW, pandoc's citeproc already has some support for this. There you can 
use braces to specify a locator in a complex suffix. Like so:

[cite:@doe {4}, with some more text]

I don't know how complex that is, but that would be a great addition.

Denis

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Bump.


Am 08.09.2021 um 16:36 schrieb Denis Maier:

Update 2:
This also happens with
#+cite_export: csl

Maybe this is useful for tracking this down.

Denis


Am 08.09.2021 um 16:30 schrieb Denis Maier:

Ok, it looks like this also happens with:

.[cite:@doe]
=> . \autocite{doe}

Is that on purpose?

Denis

Am 08.09.2021 um 15:25 schrieb Denis Maier:

Hi,
Elias and I have run into an potential bug in oc-biblatex:

==
#+cite_export: biblatex authoryear

[cite:@doe] => ok

([cite:@doe]) => this generates a space between the opening 
parentheses and the citation.

==

Result:


\autocite{doe}

( \autocite{doe}) => this generates a space between the opening 
parentheses and the citation.

=

Best,
Denis

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Update 2:
This also happens with
#+cite_export: csl

Maybe this is useful for tracking this down.

Denis


Am 08.09.2021 um 16:30 schrieb Denis Maier:

Ok, it looks like this also happens with:

.[cite:@doe]
=> . \autocite{doe}

Is that on purpose?

Denis

Am 08.09.2021 um 15:25 schrieb Denis Maier:

Hi,
Elias and I have run into an potential bug in oc-biblatex:

==
#+cite_export: biblatex authoryear

[cite:@doe] => ok

([cite:@doe]) => this generates a space between the opening 
parentheses and the citation.

==

Result:


\autocite{doe}

( \autocite{doe}) => this generates a space between the opening 
parentheses and the citation.

=

Best,
Denis

Re: Spurious spaces with oc-biblatex

[Denis Maier]

Ok, it looks like this also happens with:

.[cite:@doe]
=> . \autocite{doe}

Is that on purpose?

Denis

Am 08.09.2021 um 15:25 schrieb Denis Maier:

Hi,
Elias and I have run into an potential bug in oc-biblatex:

==
#+cite_export: biblatex authoryear

[cite:@doe] => ok

([cite:@doe]) => this generates a space between the opening parentheses 
and the citation.

==

Result:


\autocite{doe}

( \autocite{doe}) => this generates a space between the opening 
parentheses and the citation.

=

Best,
Denis

Suggestions for improved suffix parsing in oc-biblatex

[Denis Maier]

Hi,

I think the suffix parsing in oc-biblatex could be improved. Consider 
this example:



#+cite_export: biblatex authoryear

[cite:@doe 4]

[cite:@doe 4, with some more text]
=

This gives us
=
\autocite[4]{doe}

\autocite[4, with some more text]{doe}
=

The problem is  that biblatex will add a label if the suffix consists 
only of a number, a range of numbers, or a list of numbers. So 
\autocite[4]{doe} will result (Doe 2021, p. 4). However, \autocite[4, 
with some more text]{doe} results in (Doe 2021, 4, with some more text). 
In this special case you'd have to help biblatex:

\autocite[\pnfmt{4}, with some more text]{doe}
=> (Doe 2021, p. 4, with some more text)

FWIW, pandoc's citeproc already has some support for this. There you can 
use braces to specify a locator in a complex suffix. Like so:

[cite:@doe {4}, with some more text]

I don't know how complex that is, but that would be a great addition.

Denis

Spurious spaces with oc-biblatex

[Denis Maier]

Hi,
Elias and I have run into an potential bug in oc-biblatex:

==
#+cite_export: biblatex authoryear

[cite:@doe] => ok

([cite:@doe]) => this generates a space between the opening parentheses 
and the citation.

==

Result:


\autocite{doe}

( \autocite{doe}) => this generates a space between the opening 
parentheses and the citation.

=

Best,
Denis

Re: ConTeXt exporter for Org Mode

[Denis Maier]

Am 04.08.2021 um 18:01 schrieb Jason Ross:

Hello,

I have developed a ConTeXt exporter for Org Mode. It is available at
https://github.com/Jason-S-Ross/ox-context

The exporter provides custom environments for each document element
in an effort to make customization easier, in contrast to the Pandoc
exporter which uses built-in environments for document elements.

I welcome any feedback.

Thanks,
Jason




Thanks, Jason. That's really awesome.

Denis

Update Schedule for orgmode

[Denis Maier]

Hi,
I'm helping a scholar at my institution with his emacs/org-mode 
installation. As he'll would like to have automatic citations I 
suggested he should try the new org-cite features, but he does not 
really want to run the dev version. Is it already predictable when 9.5 
will be released? IIUC, the new citation features will be part of 9.5, 
right?

Best,
Denis

Re: org-cite: how to include a cite with no key?

[Denis Maier]

Am 20.07.2021 um 15:50 schrieb Bruce D'Arcus:

On Tue, Jul 20, 2021 at 8:50 AM Denis Maier  wrote:


This leads to problems with automatic citations, especially when you also use
"ibid." and such...

Bla [cite:@doe].
Blabla (Gen 1).
Bla [cite:@doe].

=>
Bla (Doe 2020).
Blabla (Gen 1).
Bla (ibid.).


With biblatex you can use \mancite to reset the citation trackers.

Can one workaround this now?
Nothing official I'm afraid. With pandoc there's this simple lua filter: 
https://github.com/denismaier/pandoc-lua-mancite

Or if not, by adding a "nobib" style per above at some point?

Yes, that could work.

Denis

Re: org-cite: how to include a cite with no key?

[Denis Maier]

Am 20.07.2021 um 13:41 schrieb Bruce D'Arcus:

On Mon, Jul 19, 2021 at 8:48 PM John Kitchin  wrote:


On Mon, Jul 19, 2021 at 7:28 PM Emmanuel Charpentier  
wrote:



In natbib there is \citetext{priv.\ comm.} which is used to add a
textual citation to the bibliography that doesn't have a key
associated with it.


Oh, I didn't know about that one in natbib.



Hmmm... why should you bother to reference a personal communication ?
Such private communications may be mentionned in the text (possibly by
a footnote) but can't be properly referenced (since there is nothing to
refer to). If you feel that this communication must be referred to, you
should give it some (written) support and (properly) reference this
support.



Who is to say why someone would bother. It is a command on page two of
http://tug.ctan.org/macros/latex/contrib/natbib/natnotes.pdf that one can use.

It is also possible to use  \nocite{*} as a cite, which includes all
references from a bibliography, and yet contains no key. Even funnier in a way 
is \nocite{key} which just adds entries to the bibliography, but does not cite 
them in the body of a document.

Footnotes are not always allowed in publications, and for various reasons not 
worth defending, in proposals one might want to put this in the references 
because of space limitations.


If not a footnote, a parenthetical note?

What's the value of a citation and bibliography processor handling
formatting here?

Certainly in the CSL world, this has never been supported, and I don't
ever recall it ever coming up (though I'm sure someone on the Zotero
forum raised it at some point)


I'm pretty sure I've brought that up at some point :-)
FWIW, Biblatex knows a similar command \mancite.

Use cases:
Beyond personal communication, which I personally have never used, there 
are disciplines (classics, theology, religious studies) that refer to 
some classical works (Bible, Quran, etc.) with certain well-known 
abbrevations. Usually those works don't appear in the bibliography. This 
leads to problems with automatic citations, especially when you also use 
"ibid." and such...


Bla [cite:@doe].
Blabla (Gen 1).
Bla [cite:@doe].

=>
Bla (Doe 2020).
Blabla (Gen 1).
Bla (ibid.).


With biblatex you can use \mancite to reset the citation trackers.

Bla [cite:@doe].
Blabla (Gen 1)\mancite.
Bla [cite:@doe].

=>
Bla (Doe 2020).
Blabla (Gen 1).
Bla (Doe 2020).

Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 21.06.2021 um 10:45 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Using a space for this is perhaps too subtle as you say. Also, the
question is which one should be the default. I'd actually suggest to
turn it around:

"A quotation ending without punctuation"[cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

Reason for this: People who don't care for this distinction---either
because they use en-us only, or because they never switch from in-text
to notes styles---will probably prefer to have a space between
quotation and citation (in input and output).


People who don't care for this distinction can write

"A quotation ending without punctuation" [cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

So I guess the default doesn't matter in this case?


That's probably correct.




What about some sort of escaping for punctuation that should stay
outside the quotation marks?
"A quotation ending without punctuation" [cite: @hoel-71-whole]\.

But, of course, that's imperfect as well. Don't know which option is
less odd.


Actual usage may tell. I implemented the spacing-tweak in
"wip-cite-new". You (and others) may want to try it out on real
documents and see if it feels somewhat natural.


Ok, let's see if others have comments. I can for now at least confirm 
that the mechanism seems to work as intended.


Thanks for all your work on this!

Best,
Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Hi,

Am 21.06.2021 um 10:45 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Using a space for this is perhaps too subtle as you say. Also, the
question is which one should be the default. I'd actually suggest to
turn it around:

"A quotation ending without punctuation"[cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

Reason for this: People who don't care for this distinction---either
because they use en-us only, or because they never switch from in-text
to notes styles---will probably prefer to have a space between
quotation and citation (in input and output).


People who don't care for this distinction can write

"A quotation ending without punctuation" [cite: @hoel-71-whole].
"A quotation ending with a period" [cite: @hoel-71-whole].

So I guess the default doesn't matter in this case?


That's probably correct.




What about some sort of escaping for punctuation that should stay
outside the quotation marks?
"A quotation ending without punctuation" [cite: @hoel-71-whole]\.

But, of course, that's imperfect as well. Don't know which option is
less odd.


Actual usage may tell. I implemented the spacing-tweak in
"wip-cite-new". You (and others) may want to try it out on real
documents and see if it feels somewhat natural.


Ok, let's see if others have comments. I can for now at least confirm 
that this works as intended.


Thanks again for all your work!

Best,
Denis



Regards,

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 20.06.2021 um 09:41 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On Mon, Jun 14, 2021 at 7:45 AM Denis Maier  wrote:



* Note style input (=semantically strict input)

"A quotation ending with a period." [cite: @hoel-71-whole]

"A quotation ending without punctuation". [cite: @hoel-71-whole]

As the input preserves the location of punctuation in the original
material, I'd say it should be much easier to deal with this. We
don't have to add information which isn't in the input, but rather
we'll just have to move any punctuation to after the citation
object. Maybe I'm missing something, but to me this looks like
a much simpler operation than going in the opposite direction.


This cannot be. [...]




As another, imperfect, workaround, I submit the following idea for
consideration:

   "A quotation ending without punctuation" [cite: @hoel-71-whole].
   "A quotation ending with a period"[cite: @hoel-71-whole].

IOW, the presence or absence of a space before the citation determines,
according to a note rule, if the punctuation should go inside or outside
the quotation. When processing non-note citations, we just need to
ensure there is at least a space after the previous element, which is
less "dangerous" than removing punctuation.


Yes, I guess we should be safe here. I can't think of a case where you 
wouldn't want a space before a citation.


I find it a bit too subtle, and so error-prone, but so is punctuation
anyway. >
WDYT?



Not a bad approach.

Using a space for this is perhaps too subtle as you say. Also, the 
question is which one should be the default. I'd actually suggest to 
turn it around:


   "A quotation ending without punctuation"[cite: @hoel-71-whole].
   "A quotation ending with a period" [cite: @hoel-71-whole].

Reason for this: People who don't care for this distinction---either 
because they use en-us only, or because they never switch from in-text 
to notes styles---will probably prefer to have a space between quotation 
and citation (in input and output). On the other hand, this here feels 
also a bit odd:

   "A quotation ending without punctuation"[cite: @hoel-71-whole].

In your example the rule would simply be that punctuation cannot jump 
across spaces.


What about some sort of escaping for punctuation that should stay 
outside the quotation marks?

   "A quotation ending without punctuation" [cite: @hoel-71-whole]\.

But, of course, that's imperfect as well. Don't know which option is 
less odd.


Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Just one addition: I think it will be perfectly fine if the current 
suggestion is added now. I guess adding additional features later will 
be always possible, right? I don't know what the plans are for the next 
org release, and I don't want this question here to stand in the way.


Denis

Am 14.06.2021 um 13:45 schrieb Denis Maier:

Below a few examples of what I mean.

WDYT? Am I missing something?

Denis
===
#+cite_export: csl
#+cite_export: csl 
"C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"

#+bibliography: test.bib

* Original source

"A quotation ending with a period."

"A quotation ending without punctuation"

* Author-date style input (= semantically non-strict input)

"A quotation ending with a period" [cite: @hoel-71-whole].

"A quotation ending without punctuation" [cite: @hoel-71-whole].

** author-date output with language: en-us
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** author-date output with language: de
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** note style output with language: en-us
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period."[1]

Expected: "A quotation ending without punctuation."[1]
Actual:   "A quotation ending without punctuation."[1]

=> ok

** note style output with language: en-gb or de
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period".[1]

Expected: "A quotation ending without punctuation".[1]
Actual:   "A quotation ending without punctuation".[1]

=> Here, we cannot distinguish between the two cases as we don't know 
whether punctuation appears in the original source.


* Note style input (=semantically strict input)

"A quotation ending with a period." [cite: @hoel-71-whole]

"A quotation ending without punctuation". [cite: @hoel-71-whole]

As the input preserves the location of punctuation in the original 
material, I'd say it should be much easier to deal with this. We don't 
have to add information which isn't in the input, but rather we'll just 
have to move any punctuation to after the citation object. Maybe I'm 
missing something, but to me this looks like a much simpler operation 
than going in the opposite direction.


Maybe we should stop talking about author date vs note style input, but 
rather about strict vs. non-strict input. And, I think that's the whole 
issue: going from strict to non-strict is easy while the other way is 
more complicated; at least, it would require some more efforts to 
support the last case (going from non-strict input to note style output 
with a language that requires strict output.

=

Am 14.06.2021 um 00:47 schrieb Bruce D'Arcus:

I'll let you two sort it out; I don't have a position.

On Sun, Jun 13, 2021, 3:23 PM Denis Maier <mailto:denisma...@mailbox.org>> wrote:




Bruce D'Arcus mailto:bdar...@gmail.com>> hat
am 14.06.2021 00:04 geschrieben:


Nicolas explained the reverse is out of scope,

IIRC, it was out of scope ATM.

and gave a reasonable explanation why (because much harder to
reconstruct missing information IIRC).

That's where I disagree. I think the opposite is true.


On Sun, Jun 13, 2021, 2:54 PM Denis Maier mailto:denisma...@mailbox.org>> wrote:

Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> Hello,
>
> Denis Maier mailto:denisma...@mailbox.org>> writes:
>
>> Yes, good this is coming.
>
> As a step forward, I rebased wip-cite-new branch with more
support for
> note numbers handling.
>
> I added three customizable variables:
>
> - org-cite-adjust-note-numbers, which simply allows the
user to toggle
>    punctuation and note number moving (on by default).
>
> - org-cite-note-rules, which defines what rules to apply
according to
>    locale, expressed as a language tag, as in RFC 4646.
>
> - org-cite-punctuation-marks, which lists strings
recognized as
>    punctuation in the process.
>
> `csl' and `bas

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Below a few examples of what I mean.

WDYT? Am I missing something?

Denis
===
#+cite_export: csl
#+cite_export: csl 
"C:/Users/denis/Zotero/styles/chicago-note-bibliography.csl"

#+bibliography: test.bib

* Original source

"A quotation ending with a period."

"A quotation ending without punctuation"

* Author-date style input (= semantically non-strict input)

"A quotation ending with a period" [cite: @hoel-71-whole].

"A quotation ending without punctuation" [cite: @hoel-71-whole].

** author-date output with language: en-us
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** author-date output with language: de
Expected: "A quotation ending with a period" (Hoel 1971).
Actual:   "A quotation ending with a period" (Hoel 1971).

Expected: "A quotation ending without punctuation" (Hoel 1971).
Actual:   "A quotation ending without punctuation" (Hoel 1971).

=> ok

** note style output with language: en-us
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period."[1]

Expected: "A quotation ending without punctuation."[1]
Actual:   "A quotation ending without punctuation."[1]

=> ok

** note style output with language: en-gb or de
Expected: "A quotation ending with a period."[1]
Actual:   "A quotation ending with a period".[1]

Expected: "A quotation ending without punctuation".[1]
Actual:   "A quotation ending without punctuation".[1]

=> Here, we cannot distinguish between the two cases as we don't know 
whether punctuation appears in the original source.


* Note style input (=semantically strict input)

"A quotation ending with a period." [cite: @hoel-71-whole]

"A quotation ending without punctuation". [cite: @hoel-71-whole]

As the input preserves the location of punctuation in the original 
material, I'd say it should be much easier to deal with this. We don't 
have to add information which isn't in the input, but rather we'll just 
have to move any punctuation to after the citation object. Maybe I'm 
missing something, but to me this looks like a much simpler operation 
than going in the opposite direction.


Maybe we should stop talking about author date vs note style input, but 
rather about strict vs. non-strict input. And, I think that's the whole 
issue: going from strict to non-strict is easy while the other way is 
more complicated; at least, it would require some more efforts to 
support the last case (going from non-strict input to note style output 
with a language that requires strict output.

=

Am 14.06.2021 um 00:47 schrieb Bruce D'Arcus:

I'll let you two sort it out; I don't have a position.

On Sun, Jun 13, 2021, 3:23 PM Denis Maier <mailto:denisma...@mailbox.org>> wrote:




Bruce D'Arcus mailto:bdar...@gmail.com>> hat
am 14.06.2021 00:04 geschrieben:


Nicolas explained the reverse is out of scope,

IIRC, it was out of scope ATM.

and gave a reasonable explanation why (because much harder to
reconstruct missing information IIRC).

That's where I disagree. I think the opposite is true.


On Sun, Jun 13, 2021, 2:54 PM Denis Maier mailto:denisma...@mailbox.org>> wrote:

Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
> Hello,
>
> Denis Maier mailto:denisma...@mailbox.org>> writes:
>
>> Yes, good this is coming.
>
> As a step forward, I rebased wip-cite-new branch with more
support for
> note numbers handling.
>
> I added three customizable variables:
>
> - org-cite-adjust-note-numbers, which simply allows the
user to toggle
>    punctuation and note number moving (on by default).
>
> - org-cite-note-rules, which defines what rules to apply
according to
>    locale, expressed as a language tag, as in RFC 4646.
>
> - org-cite-punctuation-marks, which lists strings
recognized as
>    punctuation in the process.
>
> `csl' and `basic' processors now both make use of this.
>
> I'd appreciate some feedback, in particular about the
docstrings of the
> variables above. I focused on the "note numbers" topic
instead of
> "punctuation" since I found the latter too generic.
>

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

 
 
  
   
  
  
   
Bruce D'Arcus  hat am 14.06.2021 00:04 geschrieben:
   
   

   
   

   
   
Nicolas explained the reverse is out of scope,
   
  
  
   IIRC, it was out of scope ATM.
   
  
  
   
 and gave a reasonable explanation why (because much harder to reconstruct missing information IIRC).
   
  
  
   That's where I disagree. I think the opposite is true.
   
  
  
   
  
  
   

 On Sun, Jun 13, 2021, 2:54 PM Denis Maier <denisma...@mailbox.org> wrote:
 


 Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:
 > Hello,
 > 
 > Denis Maier <denisma...@mailbox.org> writes:
 > 
 >> Yes, good this is coming.
 > 
 > As a step forward, I rebased wip-cite-new branch with more support for
 > note numbers handling.
 > 
 > I added three customizable variables:
 > 
 > - org-cite-adjust-note-numbers, which simply allows the user to toggle
 >    punctuation and note number moving (on by default).
 > 
 > - org-cite-note-rules, which defines what rules to apply according to
 >    locale, expressed as a language tag, as in RFC 4646.
 > 
 > - org-cite-punctuation-marks, which lists strings recognized as
 >    punctuation in the process.
 > 
 > `csl' and `basic' processors now both make use of this.
 > 
 > I'd appreciate some feedback, in particular about the docstrings of the
 > variables above. I focused on the "note numbers" topic instead of
 > "punctuation" since I found the latter too generic.
 > 
 > Also, there are some points that may need to be discussed:
 > 
 > - I'm not sure about the `org-cite-punctuation-marks' variable being
 >    global, i.e., not locale-specific.
 > 
 > - There is no support for this in LaTeX-derived back-ends, because
 >    I don't know when a citation is going to become a footnote. As
 >    a reminder, there is no "\footcite" command in `biblatex' processor.
 >    OTOH, users might prefer using a more advanced mechanism, e.g.,
 >    csquotes.
 > 
 > - It doesn't do anything special in quote blocks, because I'm still not
 >    sure there is something to do. AFAIU, special casing there only
 >    applies to author-date location, which out of the scope of this code.
 > 
 > WDYT?
 
 Ok, I've managed to test this a bit, and I think this looks pretty good 
 so far.
 
 The only question I'd still have is if this could somehow also cover the 
 reverse situation (going from a note style to author-date). I've noticed 
 that simply adding a new language rule doesn't work anymore---as opposed 
 to my initial tests with earlier iterations of that mechanism. Seems 
 like this mechanism is now only triggered when using a note based style.
 
 Best,
 Denis
 
 > 
 > Regards,
 > 
 
 

   
  
 

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 12.06.2021 um 11:39 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


Yes, good this is coming.


As a step forward, I rebased wip-cite-new branch with more support for
note numbers handling.

I added three customizable variables:

- org-cite-adjust-note-numbers, which simply allows the user to toggle
   punctuation and note number moving (on by default).

- org-cite-note-rules, which defines what rules to apply according to
   locale, expressed as a language tag, as in RFC 4646.

- org-cite-punctuation-marks, which lists strings recognized as
   punctuation in the process.

`csl' and `basic' processors now both make use of this.

I'd appreciate some feedback, in particular about the docstrings of the
variables above. I focused on the "note numbers" topic instead of
"punctuation" since I found the latter too generic.

Also, there are some points that may need to be discussed:

- I'm not sure about the `org-cite-punctuation-marks' variable being
   global, i.e., not locale-specific.

- There is no support for this in LaTeX-derived back-ends, because
   I don't know when a citation is going to become a footnote. As
   a reminder, there is no "\footcite" command in `biblatex' processor.
   OTOH, users might prefer using a more advanced mechanism, e.g.,
   csquotes.

- It doesn't do anything special in quote blocks, because I'm still not
   sure there is something to do. AFAIU, special casing there only
   applies to author-date location, which out of the scope of this code.

WDYT?


Ok, I've managed to test this a bit, and I think this looks pretty good 
so far.


The only question I'd still have is if this could somehow also cover the 
reverse situation (going from a note style to author-date). I've noticed 
that simply adding a new language rule doesn't work anymore---as opposed 
to my initial tests with earlier iterations of that mechanism. Seems 
like this mechanism is now only triggered when using a note based style.


Best,
Denis



Regards,

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

 
 
  
   Hi Nicolas,
   
  
  
   thanks for all your work on this. I've been busy lately, but I'll try to test ASAP. (Might take a few though, just to list you know.)
  
  
   Denis
   
  
  
   
Nicolas Goaziou  hat am 13.06.2021 00:04 geschrieben:
   
   

   
   

   
   
Hello,
   
   

   
   
"Bruce D'Arcus"  writes:
   
   

   
   
>> - I'm not sure about the `org-cite-punctuation-marks' variable being
   
   
>> global, i.e., not locale-specific.
   
   
>
   
   

 One of the things I've wondered about, but cannot offer any expertise


 on (really, I have no clue), is how this might work for languages like


 Arabic or Mandarin.

   
   
Of course, different punctuation marks exist, so characters are at least
   
   
locale-dependant. But I don't know if the set is entirely determined by
   
   
the locale or if it also depends on the "style" of the document.
   
   

   
   
>> - There is no support for this in LaTeX-derived back-ends, because
   
   
>> I don't know when a citation is going to become a footnote. As
   
   
>> a reminder, there is no "\footcite" command in `biblatex' processor.
   
   
>> OTOH, users might prefer using a more advanced mechanism, e.g.,
   
   
>> csquotes.
   
   
>
   
   

 So the upshot is if users want this functionality for LaTeX/PDF, they


 should use oc-biblatex for that export target?

   
   
Actually, that's the opposite. I don't know if it is possible, or even
   
   
appropriate, to port that feature to `biblatex' and `natbib' processors.
   
   
So, ATM, if you want it, and target LaTeX/PDF, your only option is
   
   
`csl'.
   
   

   
   
>> - It doesn't do anything special in quote blocks, because I'm still not
   
   
>> sure there is something to do. AFAIU, special casing there only
   
   
>> applies to author-date location, which out of the scope of this code.
   
   
>
   
   

 Here's the scenario I believe Denis was concerned about:

   
   

 #+begin_quote


 ... block with citation at end. [cite:@doe]


 #+end_quote

   
   

 I think in standard author-year styles, we'd want:

   
   

 ... block with citation at end. (Doe, 2020)

   
   

 ... while in note-based and "US" (space removed):

   
   

 ... block with citation at end.[1]

   
   

 Not sure if that has any practical import, but just to clarify.

   
   
I understand this, but, AFAICT, this is the output we get already. So
   
   
I don't think there is anything to do.
   
   

   
   
Thank you for the feedback.
   
   

   
   
Regards,
   
   
--
   
   
Nicolas Goaziou
   
  
 

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Hi,

Am 05.06.2021 um 23:45 schrieb Bruce D'Arcus:

On Sat, Jun 5, 2021 at 5:35 PM Nicolas Goaziou  wrote:


Getting back to this thread… I'd like to see it moving forward.

Yes. This is the last missing piece I see!

Yes, good this is coming.



You lost me here. Punctuation moving was implemented with notes cites in
mind (much like Pandoc, I think).

Correct. And also biblatex.


More exactly, punctuation shuffling
may happen whenever a cite turns into a footnote. For any other case,
the author is expected to place the cite object manually. So, the
automation does not apply to blockquotes, in the sense that inline
quotes or blockquotes use the same location for footnotes.

I guess to bottomline it, see the link that Denis provided, including
to the end with footnotes.

https://writingcenter.uagc.edu/block-quotations

I haven't tested the punctuation moving for this specifically, but it
would suggest a user would place this in a blockquote:

... end of sentence. [cite:@doe]

... and the result should remove the space for a footnote.

... end of sentence.[1]

I don't know how quotes work here, but perhaps there's no difference. Denis?
As as English and German are concerned, I think there is no difference 
between the two, yes. OTOH, French may be again different as the 
footnote marker may appear before the final punctuation.


... end of sentence[1].


Denis

Re: [org-cite, oc-csl] setting no-link parameter within document?

[Denis Maier]

Am 04.06.2021 um 14:24 schrieb Bruce D'Arcus:

On Fri, Jun 4, 2021 at 8:18 AM Eric S Fraga  wrote:


On Friday,  4 Jun 2021 at 14:01, Denis Maier wrote:

Ok, I first thought you can just add the configuration to the
LATEX_HEADER keywords, but that won't work since everything in there
is loaded before hyperref.


I am not sure what is loaded before but most of my documents have
something along the lines of

#+latex_header: 
\hypersetup{colorlinks=true,citecolor=red!80!black,urlcolor=blue!60!black}

adjusted for individual documents; this works just fine for me.


Good to know; thanks!

I still think it would be valuable to have the option to do something
like this, so it works across export backends.

#+print_bibliography: :links nil


Turns out, such an option already exists, at least for biblatex:
\usepackage[hyperref=false]{biblatex}

IIRC, it is possible to pass options to the biblatex package, right? As 
this is mostly relevant for biblatex I assume this here does the job.


Denis

Re: [org-cite, oc-csl] setting no-link parameter within document?

[Denis Maier]

Am 04.06.2021 um 14:18 schrieb Eric S Fraga:

On Friday,  4 Jun 2021 at 14:01, Denis Maier wrote:

Ok, I first thought you can just add the configuration to the
LATEX_HEADER keywords, but that won't work since everything in there
is loaded before hyperref.

I am not sure what is loaded before but most of my documents have
something along the lines of

#+latex_header: 
\hypersetup{colorlinks=true,citecolor=red!80!black,urlcolor=blue!60!black}

adjusted for individual documents; this works just fine for me.

Ok, that would mean you can load \hypersetup before having 
\usepackage{hyperref}. Good if it works.


Denis

Re: [org-cite, oc-csl] setting no-link parameter within document?

[Denis Maier]

Am 04.06.2021 um 13:50 schrieb Bruce D'Arcus:

I see the processor has a org-cite-csl-link-cites defcustom to set
this globally, but can one set it at the document level?

Further explanation:

The default hyperref settings in latex export in general are too much,
with boxes everywhere and garish colors.

When coupled with a note style with bibliography, like
chicago-note-bibliography-16th-edition.csl, it's overwhelming, Notably
each footnoted text becomes linked. And in that case, the linked data
is redundant. Example and screenshots here:

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

So I can imagine a user generally leaving the defcustom set to true,
but on individual documents (like with the chicago example) wanting to
turn it off.

Note that one can, per the thread I link to above, turn off links, or
modify their colors, using hyperref. But that's specific to the latex
export, and I don't think (?) there's an easy way to set that at the
document level.


Ok, I first thought you can just add the configuration to the 
LATEX_HEADER keywords, but that won't work since everything in there is 
loaded before hyperref.


So, I guess a LATEX_HYPERSETUP could make sense?

In the meantime users can just use a hyperref.cfg file to store their 
settings.


Denis



Bruce

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Hi,

Am 26.05.2021 um 22:33 schrieb Nicolas Goaziou:

thanks for this!

I've just tried to test this, but I can't get it to work.

I've done
git pull
make

And I'm getting:
In toplevel form:
oc-csl.el:93:1:Error: Cannot open load file: No such file or directory, 
citeproc


Do you have an idea what's going wrong here?

Best,
Denis


Hello,

I just pushed a Citeproc-based citation processor. As such, Citeproc
library must be available in the load path. For a better experience,
your also need to download styles, and possibly locales definitions, as
pointed in the commentary section pasted below.

I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
is shorter, and "org-cite-csl" prefix sounds less redudant than
"org-cite-citeproc...". Also, I don't expect a different CSL-based
citation processor any time soon, so it should be fine. But I know this
is a weak argument, so if you think "citeproc" is still more
appropriate, I can revisit this.

As pointed out in the commentary section, this is, for a large part,
a port of András Simonyi's Citeproc Org library. Thanks!

There are some differences between the two libraries, however. For
example, Org Cite CSL does not support Org Ref links. It also provides
less customization options. OTOH, it supports ".bib", ".bibtex" and
".json" bibliography files. It also handles author suppression and
global affixes in citations.

This patch adds two files in a new "etc/csl/" directory. They are both
licensed under CC BY-SA 3.0 terms. So I assume this is fine to
distribute them with Org.

Here is the full commentary. Feedback welcome!

--8<---cut here---start->8---
This library registers the `csl' citation processor, which provides
the "export" capability for citations.  You may activate it globally with

(setq org-cite-export-processor '(csl))

or at the document level, with

#+cite_export: csl

The processor relies on the external Citeproc Emacs library, which must be
available prior to loading this library.

By default, citations are rendered in Chicago author-date CSL style.  You can
use another style file by specifying it in `org-cite-export-processor'

(setq org-cite-export-processor '(csl "/path/to/style-file.csl")

or from within the document by adding the file name to "cite_export" keyword

#+cite_export: csl /path/to/style-file.csl
#+cite_export: csl "/path/to/style-file.csl"

Styles can be downloaded, for instance, from the Zotero Style Repository
().  Dependent styles (which are not "unique"
in the Zotero Style Repository terminology) are not supported.

The processor uses the "en-US" CSL locale file shipped with Org for rendering
localized dates and terms in the references, independently of the language
settings of the Org document.  Additional CSL locales can be made available
by setting `org-cite-csl-locales-dir' to a directory containing the locale
files in question (see 
for such files).  The directory must contain at least the "en-US" CSL locale.

Bibliography is defined with the "bibliography" keyword.  It supports files
with ".bib", ".bibtex", and ".json" extensions.  References are exported using
the "print_bibliography" keyword.

The library supports the following citation styles:

- noauthor (na), including bare (b) variant,
- default style, including bare (b) variant.

CSL styles recognize "locator" in citation references' suffix.  For example,
in the citation

 [cite:see @Tarski-1965 chapter 1, for an example]

"chapter 1" is the locator.  The whole citation is rendered as

 (see Tarski 1965, chap. 1 for an example)

in the default CSL style.

The locator starts with a locator term, among "bk.", "bks.", "book", "chap.",
"chaps.", "chapter", "col.", "cols.", "column", "figure", "fig.", "figs.",
"folio", "fol.", "fols.", "number", "no.", "nos.", "line", "l.", "ll.",
"note", "n.", "nn.", "opus", "op.", "opp.", "page", "p.", "pp.", "paragraph",
"para.", "paras.", "¶", "¶¶", "§", "§§", "part", "pt.", "pts.", "section",
"sec.", "secs.", "sub verbo", "s.v.", "s.vv.", "verse", "v.", "vv.",
"volume", "vol.", and "vols.".  It ends with the last comma or digit in the
suffix, whichever comes last, or runs till the end of the suffix.

The part of the suffix before the locator is appended to reference's prefix.
If no locator term is used, but a number is present, then "page" is assumed.

This library was heavily inspired by and borrows from András Simonyi's
Citeproc Org () library.
Many thanks to him!
--8<---cut here---end--->8---

Regards,

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Denis Maier]

Am 27.05.2021 um 03:58 schrieb Bruce D'Arcus:

On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus  wrote:


BTW, I did get it all setup, and do seem to have run into a bug.

Input:

[cite/noauthor:@latexcompanion p23]

Output (not position of the locator label):

(p 1993, 23)


Hmm ... experimenting some more, these work correctly.

[cite/noauthor:@latexcompanion page 23]
[cite/noauthor:@latexcompanion p. 23]
[cite/noauthor:@latexcompanion p.23]

Still not sure why the above with the p at the front though.


I think a plain "p" in front of a number is not recognized as a locator 
prefix.
Nicolas's post mentions "page", "p.", "pp." as valid locator terms for 
page. So in your case this here seems to apply: "The part of the suffix 
before the locator is appended to reference's prefix."


Denis


Bruce

Org-export question from a pandoc user

[Denis Maier]

Hi everyone,

given the recent developments regarding the citation syntax I'm 
currently looking at orgmode as a writing environment again. One thing I 
don't understand currently: Do you have to have you export configuration 
in your source file or is there a way to keep your writing clean from 
these formatting instructions? That stuff causes a lot of overhead, and 
I was really happy to learn about pandoc after using LaTeX for a long time.


Just to clarify what I mean:
With pandoc you can add formatting information to your document 
metadata, but you can also use makefiles or external files that contain 
your settings. So, in the end your documents will only contain the contents:



#+begin_src markdown
---
author: Denis
title: My article
date: whenever it is done
---

# Introduction
The article starts here

#+end_src

The nice thing about this approach is that you can define different 
settings for different output formats and reuse them as appropriate.


How do you do that in orgmode? Is that possible?

Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 19:15 schrieb Nicolas Goaziou:

Hello,

Denis Maier  writes:


By the way, I have the impression we can easily get rid of the
bare-variants completely. If we don't need footcitetext (or if we rename
the variant to note/text as that would be more appropriate, we can
something like this:


| Style | Variant   | Command  |
|---+---+--|
| author| caps  | Citeauthor*  |
| author| full  | citeauthor   |
| author| caps-full | Citeauthor   |
| author|   | citeauthor   |
|---+---+--|
| title | full  | citetitle*   |
| title |   | citetitle|
|---+---+--|
| year  | full  | citeyear*|
| year  |   | citeyear |
|---+---+--|
| locators  | parens| pnotecite|
| locators  | parens-caps   | Pnotecite|
| locators  | foot  | fnotecite|
| locators  | caps  | Notecite |
| locators  |   | notecite |
|---+---+--|
| nocite|   | nocite   |
|---+---+--|
| note  | text  | footcitetext |
| note  |   | footcite |
|---+---+--|
| smart | caps  | Smartcite|
| smart |   | smartcite|
|---+---+--|
| super |   | supercite|
|---+---+--|
| foot  |   | footcite |
|---+---+--|
| text  | caps  | Textcite |
| text  |   | textcite |
|---+---+--|
| parens| noauthor-caps | Parencite*   |
| parens| noauthor  | parencite*   |
| parens| caps  | Parencite|
| parens|   | parencite|
|---+---+--|
| plain | noauthor-caps | Cite*|
| plain | noauthor  | cite*|
| plain | caps  | Cite |
| plain |   | cite |
|---+---+--|
| (default) | caps  | Autocite |
| (default) |   | autocite |

Well, see the revised table above. WDYT?


I'm fine with it. But I see a long discussion ensued. So, is it too
early to settle on this one, or shall I implement it?


Let's wait a bit more. Maybe others want to chime in.

Just one thing I was asking myself: Will/should users be able to 
customize that? The function that handles the export doesn't look to 
complicated after all.


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Hi,

Am 20.05.2021 um 19:06 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On Thu, May 20, 2021 at 9:57 AM Denis Maier  wrote:


I'm not really sure we need bare substyles at all. At least in biblatex
it's the basis for the other commands.


Though see my followup message on autocite config.

Does that change this discussion?


Why?


I put it in the form of a question, because I'm not sure, but ...

1. I wasn't sure Nicolas was aware of this config option, nor how one
would configure it currently (but it seems necessary in general)


There is `org-cite-biblatex-options' defcustom. Currently, it defaults
to nil, but you can set it to, e.g., "key=value,key2=value" if needed.
We can also change the default.


Is there a way to use styles that aren't loaded via biblatex package 
options, but as distinct package. E.g., biblatex-chicago is loaded as 
\usepackage{biblatex-chicago}. Internally, the package will then load 
biblatex on its own.


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 19.05.2021 um 17:23 schrieb Nicolas Goaziou:




\cite could be [cite/bare: ...]


This would be confusing. So far, "bare" is a style variant. Your
suggestion promotes it exceptionally to a full-fledged style. It hurts
my logic. :)




Could "\cite" be [cite/parens/bare:...] instead?


Another thought here:
Yes, it could be [cite/parens/bare:...] but also [cite/note/bare:...].

@Bruce: We don't have bare citation in CSL currently, right? Perhaps we 
 should add this to add some portability...


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 16:11 schrieb Bruce D'Arcus:

On Thu, May 20, 2021 at 9:57 AM Denis Maier  wrote:


I'm not really sure we need bare substyles at all. At least in biblatex
it's the basis for the other commands.


Though see my followup message on autocite config.

Does that change this discussion?


Why?


I put it in the form of a question, because I'm not sure, but ...

1. I wasn't sure Nicolas was aware of this config option, nor how one
would configure it currently (but it seems necessary in general)


No, it's only necessary to configure this if you don't want the defaults.

In authoryear styles you have autocite=inline by default
In authortitle styles you have autocite=inline by default
In verbose styles you have autocite=footnote by default

So, if you use an authoryear/authortitle style, but want 
autocite=footnote you'll have to declare this as a package option.




2. If you set default to autocite=inline, which is to say the
non-bare/plain style, the issue you note goes away?



Not sure. Autocite* => parencite*, but there's still no cite/bare* then.


cite/year => \citeyear won't work as this will just print the year
without wrapping it in parentheses. It also won't trigger the ibid. in
the next citation.
cite/bare = \cite would also work in that particular citation, but an
author might remove the preceding sentence, which will make the ibid.
disappear. You will then have a regular bare citation (= "Doe 2020", or
"Doe, Title") instead of just the year or the title in parentheses.


OK, this is one of those nuances; I need to think on this one.


That's obviously an edge case. We can of course choose to start with a 
reasonable set of styles and extend later.


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 15:22 schrieb Bruce D'Arcus:

On Thu, May 20, 2021 at 9:07 AM Denis Maier  wrote:


Am 20.05.2021 um 12:36 schrieb Bruce D'Arcus:

On Thu, May 20, 2021 at 4:18 AM Denis Maier  wrote:



But maybe cite/plain or cite/basic or so?


First, are those two suggestions just synonyms for cite/bare?


Yes. Nicolas complained about cite/bare so I've thought cite/plain may
be nicer. (See autocite=plain) But the biblatex manual uses itself the
term "bare".


OK.

I don't care; I suggested "bare" because the earlier "alt" was super vague.


Or are you indeed suggesting completely changing the current logic of
these styles and substyles? E.g "bare' substyle becomes rather a
"plain" or "basic" style?


I'm not really sure we need bare substyles at all. At least in biblatex
it's the basis for the other commands.


Though see my followup message on autocite config.

Does that change this discussion?


Why?

[...]



#+begin_example
At the beginning Doe argues this and that (2020, p. 20). He goes on to
say blabla, see ibid., p. 23.
#+end_example

In order to get the ibid., you'll need a \cite* instead of just a
\citeyear or so.


Shouldn't that example be covered in org-cite by, respectively ...

cite/year
cite/bare (or plain)


Hmm, yes. The example was not ideal. Works better in an author title style:

#+begin_example
At the beginning Doe argues this and that (Title, p. 20). Later, Doe 
then says blabla, see ibid., p. 23.

#+end_example

You'd get that with
#+begin_example
At the beginning Doe argues this and that \parencite*[20]{doe}. Later, 
Doe then says blabla, see \cite*[23]{doe}.

#+end_example

cite/year => \citeyear won't work as this will just print the year 
without wrapping it in parentheses. It also won't trigger the ibid. in 
the next citation.
cite/bare = \cite would also work in that particular citation, but an 
author might remove the preceding sentence, which will make the ibid. 
disappear. You will then have a regular bare citation (= "Doe 2020", or 
"Doe, Title") instead of just the year or the title in parentheses.




...?


And how would all of this map to natbib and citeproc? >
The style+substyles really should work well across the output formats,
and gracefully fallback if certain variants, particularly in biblatex,
aren't available in other formats.

Is that the case with your suggested changes?


The problem is indeed portability between csl and biblatex (and natbib).
I think it's unavoidable that users who use biblatex specific commands
loose that to a certain degree. Fallback mappings should be added, of
course, but they will only get you so far. We should probably indicate
which commands work in all packages so users can make their decisions
consciously.


Yes, it seems highly likely that some of biblatex just won't fully
work in other formats.

But ideally we'd limit that.


Absolutely!

Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 13:56 schrieb Bruce D'Arcus:

So backing up a bit, as I was getting confused, here's [1] one summary
of the different core biblatex commands.

- \cite [autocite=plain]: Citations are typeset as-is;
- \parencite [autocite=inline]: Citations are typeset in parentheses;
- \footcite [autocite=footnote]: Citations are typeset as footnotes;
- \supercite [autocite=superscript] (only available for the numeric
style family): Citations are typeset as superscripts.

Assuming that's correct, we're trying to sort out the relation between
those first two, and autocite; right?

I take that summary to mean this basic question can be handled by a
combination of autocite and export config; autocite=inline (or
autocite=footnote) as default export, but of course configurable?

Is that correct?


I think so, yes.


If yes, that seems straightforward; what's the problem we're trying to
solve beyond that?


Nothing really. The other things are merely additions...


Bruce

[1] https://tex.stackexchange.com/a/58592




Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 12:36 schrieb Bruce D'Arcus:
> On Thu, May 20, 2021 at 4:18 AM Denis Maier  
wrote:

>
>> Could be, but also [cite/text/bare] or cite/foot/bare or cite/super/bare
>> as they all are essentially just wrappers around the plain cite command
>> (textcite is a bit different, but parencite and footcite really have the
>> same definition as cite, the only difference being that they add some
>> kind of wrapper.)
>> So, starting from parencite and then removing the wrapper would my logic
>> instead ;-)
>> But maybe cite/plain or cite/basic or so?
>
> First, are those two suggestions just synonyms for cite/bare?
Yes. Nicolas complained about cite/bare so I've thought cite/plain may 
be nicer. (See autocite=plain) But the biblatex manual uses itself the 
term "bare".



>
> Or are you indeed suggesting completely changing the current logic of
> these styles and substyles? E.g "bare' substyle becomes rather a
> "plain" or "basic" style?
I'm not really sure we need bare substyles at all. At least in biblatex 
it's the basis for the other commands.
But anyway: My first suggestion was cite/bare, and the reasoning behing 
that was:

cite: is equal to cite/default:
cite/default is equal to cite/auto
cite/auto is equal to cite/parens or cite/note
cite/bare could be understood as cite/auto/bare, which is cite/note/bare 
or cite/parens/bare


I just don't really like the notion of first adding a wrapper just to 
remove it afterwards.


>
> If yes, I need to think on this more.
>
>> |---+---+--|
>> | parens| noauthor-caps | Parencite*   |
>> | parens| noauthor  | parencite*   |
>> | parens| caps  | Parencite|
>> | parens|   | parencite|
>> |---+---+--|
>> | plain | noauthor-caps | Cite*|
>> | plain | noauthor  | cite*|
>> | plain | caps  | Cite |
>> | plain |   | cite |
>> |---+---+--|
>
> Second, I don't understand some of the above.
>
> Why "noauthor", for example? Is that not handled currently with a 
"year" style?

>
> cite/year/caps
First of all, what does capitalization of a number mean? There's no 
\Citeyear in biblatex, after all.
But that aside, \citeauthor, \citetitle and \citeyear are lower level 
commands than \cite*{}.
\cite* will work in author-date styles and in author-title styles. It 
will either print the date or the title. When using \citeyear directly 
you cannot easily switch to a different style. And: citeyear etc. don't 
use the internal trackers (ibid., idem., etc.).


#+begin_example
At the beginning Doe argues this and that (2020, p. 20). He goes on to 
say blabla, see ibid., p. 23.

#+end_example

In order to get the ibid., you'll need a \cite* instead of just a 
\citeyear or so.


>
> And how would all of this map to natbib and citeproc?>
> The style+substyles really should work well across the output formats,
> and gracefully fallback if certain variants, particularly in biblatex,
> aren't available in other formats.
>
> Is that the case with your suggested changes?
The problem is indeed portability between csl and biblatex (and natbib). 
I think it's unavoidable that users who use biblatex specific commands 
loose that to a certain degree. Fallback mappings should be added, of 
course, but they will only get you so far. We should probably indicate 
which commands work in all packages so users can make their decisions 
consciously.


Perhaps we should start thinking from the high level commands:

| CSL | biblatex|
|-+-|
| default | autocite (=parencite or footcite)   |
| in-text | textcite|
| suppress author | autocite* (=parencite* or footcite* |
|-+-|

FWIW, footcite* does not exist in all styles, so it will just behave 
like the regular footcite.


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 20.05.2021 um 12:36 schrieb Bruce D'Arcus:

On Thu, May 20, 2021 at 4:18 AM Denis Maier  wrote:


Could be, but also [cite/text/bare] or cite/foot/bare or cite/super/bare
as they all are essentially just wrappers around the plain cite command
(textcite is a bit different, but parencite and footcite really have the
same definition as cite, the only difference being that they add some
kind of wrapper.)
So, starting from parencite and then removing the wrapper would my logic
instead ;-)
But maybe cite/plain or cite/basic or so?


First, are those two suggestions just synonyms for cite/bare?


Yes. Nicolas complained about cite/bare so I've thought cite/plain may 
be nicer. (See autocite=plain) But the biblatex manual uses itself the 
term "bare".





Or are you indeed suggesting completely changing the current logic of
these styles and substyles? E.g "bare' substyle becomes rather a
"plain" or "basic" style?


I'm not really sure we need bare substyles at all. At least in biblatex 
it's the basis for the other commands.
But anyway: My first suggestion was cite/bare, and the reasoning behing 
that was:

cite: is equal to cite/default:
cite/default is equal to cite/auto
cite/auto is equal to cite/parens or cite/note
cite/bare could be understood as cite/auto/bare, which is cite/note/bare 
or cite/parens/bare


I just don't really like the notion of first adding a wrapper just to 
remove it afterwards.




If yes, I need to think on this more.


|---+---+--|
| parens| noauthor-caps | Parencite*   |
| parens| noauthor  | parencite*   |
| parens| caps  | Parencite|
| parens|   | parencite|
|---+---+--|
| plain | noauthor-caps | Cite*|
| plain | noauthor  | cite*|
| plain | caps  | Cite |
| plain |   | cite |
|---+---+--|


Second, I don't understand some of the above.

Why "noauthor", for example? Is that not handled currently with a "year" style?

cite/year/caps


First of all, what does capitalization of a number mean? There's no 
\Citeyear in biblatex, after all.
But that aside, \citeauthor, \citetitle and \citeyear are lower level 
commands than \cite*{}.
\cite* will work in author-date styles and in author-title styles. It 
will either print the date or the title. When using \citeyear directly 
you cannot easily switch to a different style. And: citeyear etc. don't 
use the internal trackers (ibid., idem., etc.).


#+begin_example
At the beginning Doe argues this and that (2020, p. 20). He goes on to 
say blabla, see ibid., p. 23.

#+end_example

In order to get the ibid., you'll need a \cite* instead of just a 
\citeyear or so.




And how would all of this map to natbib and citeproc? >
The style+substyles really should work well across the output formats,
and gracefully fallback if certain variants, particularly in biblatex,
aren't available in other formats.

Is that the case with your suggested changes?


The problem is indeed portability between csl and biblatex (and natbib). 
I think it's unavoidable that users who use biblatex specific commands 
loose that to a certain degree. Fallback mappings should be added, of 
course, but they will only get you so far. We should probably indicate 
which commands work in all packages so users can make their decisions 
consciously.


Perhaps we should start thinking from the high level commands:

| CSL | biblatex|
|-+-|
| default | autocite (=parencite or footcite)   |
| in-text | textcite|
| suppress author | autocite* (=parencite* or footcite* |
|-+-|

FWIW, footcite* does not exist in all styles, so it will just behave 
like the regular footcite.




Bruce

PS - I hadn't yet integrated sub-styles in this table, but we probably
need a table that does that.

https://github.com/bdarcus/bibtex-actions/wiki/Org-cite

Re: An attempt to prepare critical editions within Org

[Denis Maier]

Am 20.05.2021 um 13:45 schrieb Juan Manuel Macías:

Hi,

If there is a philologist among the colisters who is working on critical
editions (a type of text with several complex apparatus of footnotes and
endnotes, and with numbering and various material at the margin ---an
example of critical edition I recently typesetted for a German publisher:
https://maciaschain.gitlab.io/lunotipia/images/muestras_cariton1.png),
you may find the following interesting.

I am working on a package, org-critical-edition, to prepare philological
critical editions from the comfort of Org Mode. The natural backend of
these documents should be LaTeX with the 'reledmac' package
(https://ctan.org/pkg/reledmac), an excellent package mantained by
Maïeul Rouquette (https://github.com/maieul/ledmac), that is the most
mature option to work in this type of texts within LaTeX. But in the
future I may add some support to export data to the TEI-xml standard,
widely used in Humanities.

The basic idea of my package is that the 'critical notes' are always
hidden and only the annotated passages are shown in the text (they are
actually Org links, but what is shown is the target, while the
description and the target label remains invisible). Each critical note
can be edited or created (over a marked region) in a dedicated buffer.

Soon I will upload to GitLab a first version of the package (quite
immature at the moment: feedback welcome!) but here is a brief
screencast:
https://lunotipia.juanmanuelmacias.com/images/org-critical-edition.mp4

Best regards,

Juan Manuel



Not a philologist, but that looks very promising.

Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 19.05.2021 um 17:23 schrieb Nicolas Goaziou:

Denis Maier  writes:

In that case, I'd think that note/bare => footcitecite isn't
a particular good fit. Footcitetext puts the citation in a footnote,
just that it doesn't print a footnote mark in a running text.
(This is useful in cases where the regular footnote mechanism in LaTeX
doesn't work, e.g. in headings or tables. In these cases you' can
place the mark manually with \footnotemark, and later you specify the
text with \footnotetext, or in that case with \footcitetext.)


OK, I'll remove it.

What about also removing \footcite altogether? We could simply
automatically wrap the citation in a inline footnote before exporting
the document. No need for a special command.



No, I wouldn't suggest that unless you want to deal with capitalization 
at the beginning of footnotes, which \footcite does automatically.

#+begin_example
\documentclass{article}
\begin{filecontents}{\jobname.bib}
@book{doe,
author = {Doe, John},
title = {On using biblatex with orgmode},
year = {2021},
}
\end{filecontents}
\usepackage[style=authortitle-ibid]{biblatex}
\addbibresource{\jobname.bib}

\begin{document}
Test.\footcite{doe}
Test.\footcite{doe} % "ibid." -> "Ibid."

\citereset
Test.\footnote{\cite{doe}.}
Test.\footnote{\cite{doe}.} "ibid." stays "ibid."
\end{document}
#+end_example



Org already handles footnotes in headings and tables, so there may be no
need to footcitetext either…


Regarding:

| locators  | bare  | notecite |
| locators  | caps  | Pnotecite|
| locators  | bare-caps | Notecite |
| locators  |   | pnotecite|


fnotecite should be added.


Under what style/variant combination?


| locators  | bare  | notecite |
| locators  | caps  | Pnotecite|
| locators  | bare-caps | Notecite |
| locators  | foot  | fnotecite|
| locators  |   | pnotecite|



One problem is there is no "\cite", or "\parencite". I though they would
make a good fit for the default style, "\cite" being the "bare" variant
of "\parencite", and "\autocite" could be moved to a "auto" style. I'm
not sure where to put \cite, then.


Why not just add a cite/parens style?


OK.


\cite could be [cite/bare: ...]


This would be confusing. So far, "bare" is a style variant. Your
suggestion promotes it exceptionally to a full-fledged style. It hurts
my logic. :)

Could "\cite" be [cite/parens/bare:...] instead?


Could be, but also [cite/text/bare] or cite/foot/bare or cite/super/bare 
as they all are essentially just wrappers around the plain cite command 
(textcite is a bit different, but parencite and footcite really have the 
same definition as cite, the only difference being that they add some 
kind of wrapper.)
So, starting from parencite and then removing the wrapper would my logic 
instead ;-)

But maybe cite/plain or cite/basic or so?

By the way, I have the impression we can easily get rid of the 
bare-variants completely. If we don't need footcitetext (or if we rename 
the variant to note/text as that would be more appropriate, we can 
something like this:



| Style | Variant   | Command  |
|---+---+--|
| author| caps  | Citeauthor*  |
| author| full  | citeauthor   |
| author| caps-full | Citeauthor   |
| author|   | citeauthor   |
|---+---+--|
| title | full  | citetitle*   |
| title |   | citetitle|
|---+---+--|
| year  | full  | citeyear*|
| year  |   | citeyear |
|---+---+--|
| locators  | parens| pnotecite|
| locators  | parens-caps   | Pnotecite|
| locators  | foot  | fnotecite|
| locators  | caps  | Notecite |
| locators  |   | notecite |
|---+---+--|
| nocite|   | nocite   |
|---+---+--|
| note  | text  | footcitetext |
| note  |   | footcite |
|---+---+--|
| smart | caps  | Smartcite|
| smart |   | smartcite|
|---+---+--|
| super |   | supercite|
|---+---+--|
| foot  |   | footcite |
|---+---+--|
| text  | caps  | Textcite |
| text  |   | textcite |
|---+---+--|
| parens| noauthor-caps | Parencit

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 19.05.2021 um 15:44 schrieb Nicolas Goaziou:

Here is the summary:

| Style | Variant   | Command  |
|---+---+--|
| author| caps  | Citeauthor*  |
| author| full  | citeauthor   |
| author| caps-full | Citeauthor   |
| author|   | citeauthor   |
|---+---+--|
| locators  | bare  | notecite |
| locators  | caps  | Pnotecite|
| locators  | bare-caps | Notecite |
| locators  |   | pnotecite|
|---+---+--|
| nocite|   | nocite   |
|---+---+--|
| note  | bare  | footcitetext |
| note  |   | footcite |
|---+---+--|
| smart | caps  | Smartcite|
| smart |   | smartcite|
|---+---+--|
| super |   | supercite|
|---+---+--|
| text  | caps  | Textcite |
| text  |   | textcite |
|---+---+--|
| title | full  | citetitle*   |
| title |   | citetitle|
|---+---+--|
| year  | full  | citeyear*|
| year  |   | citeyear |
|---+---+--|
| (default) | caps  | Autocite |
| (default) |   | autocite |

"bare" variant means "without parenthesis", I think.


Am 19.05.2021 um 15:50 schrieb Bruce D'Arcus:

To be more precise/general, it means without enclosing punctuation;
parentheses, brackets, etc.



Thanks, both. So bare is just the citation without a wrapper.

In that case, I'd think that note/bare => footcitecite isn't a 
particular good fit. Footcitetext puts the citation in a footnote, just 
that it doesn't print a footnote mark in a running text.
(This is useful in cases where the regular footnote mechanism in LaTeX 
doesn't work, e.g. in headings or tables. In these cases you' can place 
the mark manually with \footnotemark, and later you specify the text 
with \footnotetext, or in that case with \footcitetext.)


Regarding:
> | locators  | bare  | notecite |
> | locators  | caps  | Pnotecite|
> | locators  | bare-caps | Notecite |
> | locators  |   | pnotecite|

fnotecite should be added.


One problem is there is no "\cite", or "\parencite". I though they would
make a good fit for the default style, "\cite" being the "bare" variant
of "\parencite", and "\autocite" could be moved to a "auto" style. I'm
not sure where to put \cite, then.


Why not just add a cite/parens style?
\cite could be [cite/bare: ...]

Regarding \autocite being the default:
I think one strong argument in favor of this is that people may want to 
switch between different citation export processors. So if you typeset 
your article with latex you may want to use biblatex. But if the journal 
accepts submissions only as docx files you'll have to switch to a 
CSL-based citeproc. Here, the default is to wrap the citation either in 
a footnote or in parentheses, depending on the style.
So, to ensure portability of documents across export systems [cite: 
@doe] should give similar results with different systems, and I think 
\autocite would be the best choice. (By the way, it's also the way 
pandoc implements this.)


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Hi,

Am 18.05.2021 um 17:13 schrieb Nicolas Goaziou:

Hello,

In a rebased "wip-cite-new" branch, I made an modest attempt to write
a `biblatex' citation processor, in the file "oc-biblatex.el"


Just in case anyone else stumbles over this:
You'll have the add
(require 'oc-biblatex)
to the cite-init.el file.




- author(a), including caps(c), full(f) and caps-full(f) variants,
- locators(l), including bare(b), caps(c) bare-caps(bc) variants,
- nocite(n),
- note(fn), including bare(b) variant,
- smart(sm), including caps(c) variant,
- super(s),
- text(t), including caps(c) variant,
- title(ti), including full(f) variant,
- year(y), including full(f) variant,
- default style, including caps(c) variant.


What's the intended meaning of these "bare" variants?
I was a bit confused by [cite/note/bare...] going to \footcitetext
What's the intention here?

Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 19.05.2021 um 12:43 schrieb Bruce D'Arcus:

On Wed, May 19, 2021 at 6:05 AM Denis Maier  wrote:


Is there a way to get a simple \cite?


Hmm ... "cite/cite"?

What does "cite" do that "autocite" doesn't?


\cite is the most basic cite command:

In a author-year style:
\cite   => Doe 2020
\textcite   => Doe (2020)
\parencite  => (Doe 2020)
\autocite   => \parencite

In note-based styles (e.g verbose):

\cite   => Doe, Title
\footcite   => [fn:: Doe, Title]
\parencite  => (Doe, Title)
\autocite   => \footcite




Also, footcite should be there.


Footcite is already there under the "note"/"fn" style.


Good! (I was just a bit confused because biblatex has \footcite and 
\notecite.


Denis

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Denis Maier]

Am 18.05.2021 um 17:13 schrieb Nicolas Goaziou:

Hello,

In a rebased "wip-cite-new" branch, I made an modest attempt to write
a `biblatex' citation processor, in the file "oc-biblatex.el

As Bruces has already written, this doesn't look modest at all.

[...]



- author(a), including caps(c), full(f) and caps-full(f) variants,
- locators(l), including bare(b), caps(c) bare-caps(bc) variants,
- nocite(n),
- note(fn), including bare(b) variant,
- smart(sm), including caps(c) variant,
- super(s),
- text(t), including caps(c) variant,
- title(ti), including full(f) variant,
- year(y), including full(f) variant,
- default style, including caps(c) variant.


Is there a way to get a simple \cite?
Also, footcite should be there.



The default style creates "autocite" commands.


[...]


I don't use biblatex, but I'm not convinced by the default autocite
command. Wouldn't parencite be more predictable? Also, adding

   #+cite_export biblatex ... auto

to trigger autocite by default seems easy enough. 
I think autocite is a reasonable default. Parencite would be a bad fit 
for the verbose styles. And in author-year styles autocite is equivalent 
to parencite anyway.


Denis

Re: Multilingual support (proposals and state of the question)

[Denis Maier]

Am 17.05.2021 um 17:41 schrieb Juan Manuel Macías:

Hi all,

I would like to start a thread on this question, leaving some basic ideas and
sketches of my own, in case someone else wanted to join the discussion.

I think it would be nice if Org Mode offered consistent support (out of
the box) for multilingual documents. That is, those documents where
there is a main language and it is possible to toggle between a list of
others 'secondary' languages, in the LaTeX Babel way. Those documents
could be consistently exported to other formats with multilingual
support: LaTeX, of course, but also html, odt, etc.

What is your opinion?

I think Org documents should have three levels in multilingual management:

- Short text segments, something like an 'inline block' for other languages
- Blocks
- Sections

For short inline segments, IMHO and without the need to innovate, I
think an excellent candidate are the links defined with
org-link-set-parameters. For example:

Lorem ipsum [[lang:de][some text in German]] dolor sit amet

(For structures of this kind I found very interesting ideas here:
https://github.com/alhassy/org-special-block-extras)

As for blocks, I think of a hypothetical 'lang' block:

#+begin_lang el :variant polytonic
Some text in polytonic Greek...
#+end_lang

However, in a previous thread
(https://orgmode.org/list/87k0og8fss@list.aleks.bg/) Aleksandar
Dimitrov proposed an idea that seemed very suggestive, at least in
concept: add a ':lang' argument to the Org code blocks:

#+begin_src org :lang fr
Some text in french
#+end_src


Why not add a :lang property to other blocks as well?
#+begin_quote :lang en
this is english.
#+end_quote

WDYT?

Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 17.05.2021 um 00:24 schrieb Bruce D'Arcus:

On Sun, May 16, 2021 at 6:03 PM Denis Maier
 wrote:


Am 16.05.2021 um 23:38 schrieb Bruce D'Arcus:





Can you clarify the rule/situation that would use that approach?



Chicago Manual of Style 15.26:
"When the source of a block quotation is given in parentheses at the end
of the quotation, the opening parenthesis appears after the final
punctuation mark of the quoted material. No period either precedes or
follows the closing parenthesis."


Maybe me and a lot of scholars aren't very good at following these rules :-)

Or maybe the stuff I read and write doesn't follow Chicago, etc for
whatever reason.


Seems to be the same in MLA and APA by the way:
https://writingcenter.uagc.edu/block-quotations


Very helpful!

So what are you thinking; this punctuation-manipulation should not
apply to blockquotes at all?


I think there are a couple of options and combinations thereof:

1. Do nothing special, just treat block quotations like regular paragraphs.

2. Don't apply this punctuation-manipulation to blockquotes at all, i.e. 
let authors handle this manually.


3. Adjust RULE in the manipulation function: Let it accept two patterns:
'((outside outside before) (outside outside after))
The first would apply to inline quotations, the second to blockquotes.

4. IIUC, it's possible to set certain properties at block elements. So, 
maybe you could actually add citation information there, e.g.:


#+BEGIN_QUOTE :cite @doe p.45
This is a blockquote in its own paragraph.
#+END_QUOTE

Unsure about the syntax, but you get the idea. This should allow for 
complex manipulations: the citation can be added before or after the 
punctuation mark; if a journal requires quotation marks even around 
blockquotes => just add them during export; if the period is not part of 
the original quotation you could just do this:


#+BEGIN_QUOTE :cite @doe p.45 :punct .
This is a blockquote in its own paragraph
#+END_QUOTE

Then the period will be added during export, but if a journal wants an 
ellipsis in that case you can also just add that during export.

This is a blockquote in its own paragraph [...].[1]

Now, this is of course rather complex and might add a lot of overhead. I 
don't think users should be required to use this, but this could 
nevertheless be added as an additional and more powerful mechanism.


5. Don't apply punctuation-manipulation to individual blockquotes.

#+BEGIN_QUOTE :punctuation-manipulation nil
This is a blockquote in its own paragraph. [@doe p. 45]
#+END_QUOTE

(Maybe adding someting like this even for inline citations would be a 
good idea: "asdf." [cite: @doe p. 45 :punctuation-manipulation nil]
I can imagine many users will be happy with the automatism 95% of the 
time, but there will always be egde cases.)


Again, as I've said above, a combination of these options might be the 
way to go. E.g., the default could be to disable 
punctuation-manipulation for blockquotes. In addition to that there 
could also be a properties based mechanism that offers more options. 
(Thinking more about it, 3 and 4 would actually also play nicely together.)


Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 15.05.2021 um 13:56 schrieb Nicolas Goaziou:

Hello,


[...]


At the moment, the `org-cite-adjust-punctuation' function is designed
with author-year to note conversion in mind, not the other way. I don't
have enough examples of the opposite transformation to even be sure the
current interface would be appropriate. I even believe this is not often
possible, as it would imply rewording, i.e., add information that is not
present in the original document.

This doesn't seem to be a limitation, though. This feature is useful for
users having to switch between author-year and note styles. The rule of
thumb is to always write author-year in source.


Well, I have to admit I was a bit confused when I first read this since 
the examples we're currently working with wouldn't be correct examples 
for author-date citations in German and English:


--8<---cut here---start->8---
#+language: de
#+cite_export: test

1. "This is a complete sentence." [cite:@key]

2. "This is an incomplete sentence" [cite:@key].

3. This is a complete sentence. [cite:@key]

4. This is an incomplete sentence [cite:@key].
--8<---cut here---end--->8---

In German and English author-date styles example 1. and 2. will both be 
rendered as:

"This is a complete sentence" (author year).
"This is an incomplete sentence" (author year).
So, in both cases the punctuation comes after the citation.

After looking up a few guidelines from French speaking universities in 
Canada, it looks like in French you'll actually render these citations as:

"This is a complete sentence." (author year)
"This is an incomplete sentence" (author year).
(Don't know if that is consistent across la francophonie.)
I.e., with a complete sentence you'll have the final punctuation inside 
the quotation marks with the citation following the citation. So, as you 
say the location of the punctuation is semantically meaningful in French 
even with author-date styles, but that isn't the case in German and 
English. In German and British English, the location of the punctuation 
is only semantically meaningful with note citation styles.


Now, interestingly, the way you'll place the punctuation marks in German 
and British English seems to conform to French author-date punctuation 
placement.


This means that in German and British English a conversion from
"This is a complete sentence." [cite:@key]
to
"This is a complete sentence" (citation).
is actually not adding, but removing information.

OTOH, if you write targeting German/English author-date styles, it's not 
possible to switch correctly to a note style in German and British 
English. (You'll have to indicate the location of the punctuation in the 
original material, which means it has to be moved when targeting an 
author-year style.)


So, I still think (outside outside before) should work in general for 
English and German. If I understand correctly you've already added it as 
 (pcase style ("author-year" ...

Correct?

There's only one further complication: if the quotation is a set off 
block quote, the citation comes after the punctuation mark:

This is a complete sentence. (author year)
Can surrounding context be considered in that transformation?

Denis



In any case, this explains why the docstring has a bias. I updated it to
insist on the fact that these are rules for author-year to note
conversion.

Also, this function is not meant to be accessible to the end user. It is
called from the processor, which knows the type (or style) of the
citation. It may also choose not to use this function. So, I agree with
Bruce D'Arcus: selecting an appropriate rule and punctuation ought to
happen at that level.

More importantly, I don't think fine-grain configuration is required.
For specific needs, this "smart" feature should be disabled, and
elements (punctuation, citation) positioned manually. But, again, if
configuration is needed, the processor should provide it, e.g., through
variables, not Org Cite. For example, a defcustom could offer to 1) not
use this feature 2) rely on "language" keyword 3) apply a user-defined
rule and punctuation set.

What would be nice, however, would be an association between language
and default rules and punctuation characters.

WDYT?

Meanwhile, I modified `org-cite-adjust-punctuation' function a bit. Here
is its new docstring.

--8<---cut here---start->8---
Adjust punctuation around CITATION object.

When CITATION follows a quotation, or when there is punctuation next to it,
the function tries to normalize the location of punctuation and citation
according to some RULE.

RULE is a triplet of symbols (PUNCTUATION CITE ORDER):

   PUNCTUATION is the desired location of the punctuation with regards to the
   quotation, if any.  It may be `inside', `outside', or`static'.  When set to
   `static', the punctuation is not moved.

   CITE is the desired location of the citation with 

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Hi,


 (strict inside before) corresponds to French typography.



Regarding French typography.
With this example:
---
#+language: fr
#+cite_export: test

"This is a complete sentence."[cite:@key]

"This is an incomplete sentence" [cite:@key].

"This is an incomplete sentence". [cite:@key]

This is a complete sentence. [cite:@key]

This is an incomplete sentence [cite:@key].


I'm getting:


"This is a complete sentence[1]."

"This is an incomplete sentence[2]" .

"This is an incomplete sentence"[3].

This is a complete sentence[4].

This is an incomplete sentence[5].


1, 3, 4, 5 look ok.
2 is a bit odd.
- there's the spurios space before the period.
- I think in that case the footnote mark should be just before the 
period, i.e. after the quotation mark. Basically like example 3.


I think the textbook rule regarding French typography is:
Place the footnote mark just before the final punctuation.
Punctuation is placed inside quotation marks if we have a full 
quotation, otherwise outside. (OTOH, that seems to be a textbook rule. 
As I've said, I haven't seen that in real books.)


I don't know if that is feasible with the current parameters.

Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 13.05.2021 um 23:33 schrieb Nicolas Goaziou:

Hello,

[...]

   RULE is a triplet of symbols (PUNCT POSITION RELATIVE):

 PUNCT is the desired location of the punctuation with regards to the
 quotation, if any.  It may be `inside', `outside', or`strict', the latter
 meaning the punctuation should not be moved.

 POSITION is the desired location of the citation with regards to the
 quotation, if any.  It may be `inside' or `outside'.

 RELATIVE is the relative position of the citation with regards to the 
closest
 punctuation.  It may be `after' or `before'.

   For example,

 (inside outside after) corresponds to American typography;
 (strict outside after) corresponds to German typography;
 (strict inside before) corresponds to French typography.
These things are not only language dependent, but depend also on the 
chosen citation style. E.g. with in-text styles you'll have (outside 
outside before) in German, and American typography, in French likely as 
well.

So, perhaps another setting:
#+type-of-citation-style: in-text
#+type-of-citation-style: note

And ideally this RULE should be configurable directly as well:
#+punct-moving-rule: strict inside before



   INFO is the export state, as a property list.

   Optional argument PUNCT is a list of punctuation marks to be considered.
   When nil, it includes the following: \".\" \",\" \";\" \":\" \"!\" and \"?\".


Here as well, it should be possible to configure these on a user level. 
Something like:

#+moved-punctuation: ,.?!

WDYT?

Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Am 14.05.2021 um 01:21 schrieb Bruce D'Arcus:

On Thu, May 13, 2021 at 5:33 PM Nicolas Goaziou  wrote:




WDYT?


Looks really good; thanks for this!

But I get this error when I run the export to test.

org-export-as: Wrong number of arguments: #, 1

Not sure what I'm doing wrong; I:

1. pulled the branch
2. ran make
3. evaled your "test" code
4. ran the export


Exactly, what I was doing. It works without problems here.

Denis

Re: [wip-cite-new] Adjust punctuation around citations

[Denis Maier]

Thanks Nicolas! That looks quite good already.

Your test cases give good results for German.
I've also added another language property for when you want to switch to 
an in-text citation style:


(defun org-test--language-to-rule (info)
  (pcase (plist-get info :language)
("en-us" '(inside outside after))
((or "en" "de" "en-gb") '(strict outside after))
("de-author-year" '(outside outside before))
("fr" '(strict inside before))
(_ nil)))

Exporting your example with #+language: de-author-year gives me:

=
"This is a complete sentence"[1].

"This is an incomplete sentence"[2].

"This is an incomplete sentence"[3].

This is a complete sentence[4].

This is an incomplete sentence[5].
=

The only quirk here is that you'll obviously want spaces before the 
citaitons, but I guess this is because citation end up in footnotes. 
With an in-text style spaces won't be collapsed here, right?


Again, thanks for all your work on this one.

Denis

Am 13.05.2021 um 23:33 schrieb Nicolas Goaziou:

Hello,

Following discussion with Bruce D'Arcus and Denis Maier, I pushed, in
the "wip-cite-new" branch, the first version of a tool for adjusting the
location of the citation and surrounding punctuation according to fixed
rules. The name is `org-cite-adjust-punctuation' and its docstring is:

   Adjust punctuation around CITATION object.

   When CITATION follows a quotation, or when there is punctuation next to it,
   the function tries to normalize the location of punctuation and citation
   according to some RULE.

   RULE is a triplet of symbols (PUNCT POSITION RELATIVE):

 PUNCT is the desired location of the punctuation with regards to the
 quotation, if any.  It may be `inside', `outside', or`strict', the latter
 meaning the punctuation should not be moved.

 POSITION is the desired location of the citation with regards to the
 quotation, if any.  It may be `inside' or `outside'.

 RELATIVE is the relative position of the citation with regards to the 
closest
 punctuation.  It may be `after' or `before'.

   For example,

 (inside outside after) corresponds to American typography;
 (strict outside after) corresponds to German typography;
 (strict inside before) corresponds to French typography.

   INFO is the export state, as a property list.

   Optional argument PUNCT is a list of punctuation marks to be considered.
   When nil, it includes the following: \".\" \",\" \";\" \":\" \"!\" and \"?\".

   Parse tree is modified by side-effect.

   Note: if you are calling both `org-cite-adjust-punctuation' and
   `org-cite-wrap-citation' on the same object, call 
`org-cite-adjust-punctuation'
   first.

Citation processors focused on export may choose to use it, particularly
when using note style.

As an example, the following code implements a processor named `test'
that uses note style, and adjust punctuation according to the language
specified for the document.

--8<---cut here---start->8---
(defun org-test--language-to-rule (info)
   (pcase (plist-get info :language)
 ("en-us" '(inside outside after))
 ((or "en" "de" "en-gb") '(strict outside after))
 ("fr" '(strict inside before))
 (_ nil)))

(defun org-test-export-citation (citation _style _backend info)
   (pcase (org-test--language-to-rule info)
 (`nil nil)
 (rule (org-cite-adjust-punctuation citation rule info)))
   (unless (org-cite-inside-footnote-p citation)
 (org-cite-wrap-citation citation info))
   "...")

(org-cite-register-processor 'test
   :export-citation #'org-test-export-citation)
--8<---cut here---end--->8---

Once evaluated, you can test it, for example, by exporting the following
document:

--8<---cut here---start->8---
#+language: de
#+cite_export: test

"This is a complete sentence." [cite:@key]

"This is an incomplete sentence" [cite:@key].

This is a complete sentence. [cite:@key]

This is an incomplete sentence [cite:@key].
--8<---cut here---end--->8---

and changing language value.

WDYT?

Regards,

Re: CSL-JSON support for =parsebib=

[Denis Maier]

Hi,well, this is what I asked Joost in the first place. Adjusting parsebib is 
part of the efforts to make that possible.Denis

Re: Need help using the dev version on windows

[Denis Maier]

Am 07.05.2021 um 14:04 schrieb Ihor Radchenko:

Denis Maier  writes:

Then, I get this message ...
==
= Invoke "make help" for a synopsis of make targets. =
= Created a default local.mk template.   =
= Setting "oldorg" as the default target.=
= Please adapt local.mk to your local setup! =
==
... and that's it ...
Nothing happens.

What am I missing?


Most likely you need to add emacs to your %PATH% Windows system
variable. Essentially, you should be able to run "emacs" command from
the terminal.

Best,
Ihor



Thanks.
The path was correctly set. I've now installed MSYS2 (and also the MSYS2 
version of Emacs.). Now it works as expected. Don't know if a tools has 
been missing, or if it was something with the folder structure.


Denis

Fold/Hide inline footnotes

[Denis Maier]

Hi,
auctex has a nice feature to hide certain elements, e.g. footnotes. 
Would it be possible to include something similar in org-mode?

Best,
Denis

Need help using the dev version on windows

[Denis Maier]

Hi,

in order to test the new org-cite features I've tried installing orgmode 
from the git repo.


So, in my home folder
git clone https://code.orgmode.org/bzg/org-mode.git
cd org-mode
make

Then, I get this message ...
==
= Invoke "make help" for a synopsis of make targets. =
= Created a default local.mk template.   =
= Setting "oldorg" as the default target.=
= Please adapt local.mk to your local setup! =
==
... and that's it ...
Nothing happens.

What am I missing?

Denis

Re: wip-cite status question and feedback

[Denis Maier]

Am 05.05.2021 um 20:14 schrieb 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.



Just to be clear, these are meant as examples for the three language 
specific rules outlined above.
1. is an example for the "American" style, which consistently puts 
punctuation (commas and periods) inside quotation marks even if the 
punctuation mark does not appear in the original quotation.
2. is an example for the "British" style, which seems to conform to what 
seems to be correct in German.
3. is an example for what the latex csquotes describes as "French" style 
where the footnote mark seems to be included in the quotation just 
before the punctuation mark. Yesterday, I've tried to find examples for 
this rule in French book, and I couldn't. I found this:
	- Punctuation is placed inside or outside the quotation marks depending 
on whether you're quoting a complete sentence.

- If punctuation is placed inside the quotation marks the order is: 
."[1]
- If punctuation is placed outside the quotation marks the order is: 
"[1].
- If there is no preceding quotation the order is: [1].
Maybe a native French speaker can shed some light on this?

Denis

Re: [wip-cite-new] New natbib processor

[Denis Maier]

Am 05.05.2021 um 23:25 schrieb Bruce D'Arcus:

On Wed, May 5, 2021 at 2:08 PM Bruce D'Arcus  wrote:


I did some basic testing, and it seems to work well in general ...


That was just looking at the citation output, of course.

Now I did the real test: would LaTeX -> PDF work.

Answer: not ATM.

Here's my minimal document:


[cite/text/alt:see ;@mann-68]

[cite//alt/caps:@mann-68]

[cite//full:@mann-68]

[cite//caps:@mann-68]

#+cite_export: natbib
#+bibliography: test.bib


... but when I run the export, I get an "undefined citation" error.

The key is correct, as is the file name, which is in the same directly
as the test file.

What am I missing?


Bruce has sent me his test files, and it turned out to be the bibstyle 
(humannat), which apparently isn't included in current tex distributions.
Question: I can't see why this style should be used according to the 
minimal example Bruce has shared. Is this style added as the default 
style by the exporter? Or did you, Bruce, specify it somewhere?


Denis

Re: Notes about citations in Org (part 3)

[Denis Maier]

Am 05.05.2021 um 11:37 schrieb Bruce D'Arcus:



On Wed, May 5, 2021, 1:48 AM Eric S Fraga > wrote:


On Tuesday,  4 May 2021 at 18:59, Nicolas Goaziou wrote:
 > Is the default \cite{key} command (without any other package) used?

Yes, it is.  But I wouldn't be able to tell you anything about relative
frequency etc.


Does it have any more commands than \cite and \nocite?

Bruce



I don't think so.

Denis

Re: Question about citation processors [wip-cite branch]

[Denis Maier]

Am 04.05.2021 um 17:27 schrieb Joost Kremers:


On Tue, May 04 2021, Bruce D'Arcus wrote:

On Tue, May 4, 2021 at 10:47 AM Joost Kremers  wrote:


I can add some comments regarding biblatex:

- default: \parencite[1]


WDYT of \autocite for default?

It's conceptually the same as the CSL default.


If that is the case then it's probably the better choice. The biblatex manual
states that \autocite requires that the citation style defines a command for it
and that it is not appropriate for author-year style citations. I assume that's
something for the user to be aware of when using such citations?


Well, IIRC, in author-year styles \autocite is equivalent to \parencite. 
I think, what the manual talks about is not that \autocite wouldn't be 
appropriate for author-year styles, but rather that relying /solely/ on 
\autocite doesn't give authors the flexibility they might want in these 
styles, like when you want something like in your example:

```
According to \textcite[]{Jones1998} , ``students often had difficulty 
using APA
style, especially when it was their first time'' 
\pnotecite[][199]{Jones1998}.

```

So, I think \autocite is the better choice.

Denis

Re: Notes about citations in Org (part 3)

[Denis Maier]

Am 04.05.2021 um 12:10 schrieb Joost Kremers:


On Tue, May 04 2021, Eric S Fraga wrote:

Question for the longer term: for LaTeX export, I will be wanting to
have the [cite:] constructs export to BiBTeX code.  Will this be
possible in due course?  For other targets (ODT, HTML), what has been
done in this branch is fantastic but, for LaTeX, publishers will expect
BiBTeX.


Pedantic nit-pick: they *should* be expecting and using biblatex. (But perhaps
that is what you meant already. :-) )


But they most likely won't, or has that changed in recent years?

Denis

Re: Notes about citations in Org (part 3)

[Denis Maier]

Hi,

Am 04.05.2021 um 08:47 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On Mon, May 3, 2021 at 12:42 PM Nicolas Goaziou  wrote:


Anyway, I suggest to let it nil, and select it at the document level
instead, with

   #+cite_export: basic bibstyle citestyle


What is the significance of the last two items?


These are the default styles used for bibliography and citations, in the
sense of Org "styles", i.e.,

   [cite/citestyle:...]
   #+print_bibliography: bibstyle


In a CSL implementation like citeproc-el, both are defined in a single
style.

Are they defined separately in other systems?


IIUC, you can combine different bibliography and citation styles in
LaTeX. Maybe some LaTeX users could confirm this.

Yes, that's true for biblatex.

Denis

Re: wip-cite status question and feedback

[Denis Maier]

While evaluating different aspects of punctuation moving I had another 
look at the csquotes package. p. 21 f. and p. 27 ff. in the manual 
(http://mirrors.ctan.org/macros/latex/contrib/csquotes/csquotes.pdf) are 
quite instructive.[1] This package a structured representation of a 
quotation, final punctuation in the quotation, the citation, and 
trailing punctuation, which all can then be reassembled according to 
different rules.
Now, I was wondering if something similar could be used for org as well. 
I'm thinking of something like this:


1. At first parse quotations and citations into lists 
'(quotation-content final-punct-in-quotation citation trailing-punctuation)

2. Fed that into a second function that reassembles the elements.

In that case, the function org-cite-wrap-punctuation would take a 
object, info, a boolean and a function as arguments, the boolean would 
enable/disable the function, the last argument could specify how the 
elements should be reassembled, so:
(defun org-cite-wrap-citation (citation info  move-punctuation 
move-punctuation-function)

=>
(org-cite-wrap-citation citation info t American)

Does that make sense? Would that be possible?

I'm thinking whether this could make the system more flexible and 
adaptable. And it would remedy the need to come up with all possible 
patterns as it should be easy to add those later. WDYT?


Denis

[1]:  As it seems, french typography seems to place note symbols just 
before the closing quotation mark.


Am 01.05.2021 um 15:26 schrieb Bruce D'Arcus:

On Fri, Apr 30, 2021 at 5:48 PM Denis Maier  wrote:


Yes, this should be equivalent to the behaviour in pandoc.

However, as I've said before, this behaviour is only correct in American
English.

Denis and I are working on sorting out the details of how to address
this off-list ATM.

But I'm tentatively thinking this could be addressed by splitting the
MOVE-PUNCTUATION parameter in two, so that we have:

MOVE-PUNCTUATION: Move punctuation character following citation before
it, when applicable (for example [TODO]).

PUNCTUATION-INSIDE-QUOTES: If a quotation mark precedes the citation,
move punctuation before it, too, unless [TODO]

So for the examples Nicolas posted, this:

(org-cite-wrap-citation citation info t)

… would change to this:

(org-cite-wrap-citation citation info t t)

... and to get the British/German output it would be:

(org-cite-wrap-citation citation info t nil)

More when we figure out if this is feasible, with example input/output, etc.

Bruce

Re: wip-cite status question and feedback

[Denis Maier]

Hi Nicolas,

thanks for all you work on this one. I don't have a setup where I can 
test this, but from what I can tell this looks quite good already.


Am 30.04.2021 um 15:28 schrieb Nicolas Goaziou:
[...]



OK. I wrote a POC, and I would appreciate some feedback about it.

In order to test it, one need to evaluate the following, from an
up-to-date "wip-cite-new" branch:

--8<---cut here---start->8---
(defun org-cite--swap-punctuation (object info)
   "Move punctuation following OBJECT before it, if applicable.

When OBJECT is followed by some terminal punctuation character, such as
a period or a question mark, and preceded by some text, move the punctuation
at the end of the previous text.  If that text ends with a double quote,
move the punctuation before that quote, too.

INFO is the export state, as a property list."
   (let ((next (org-export-get-next-element object info))
 (previous
  (org-last
   (org-element-map (org-export-get-previous-element object info)
   'plain-text
 #'identity info)))
 (punct-re
  (rx string-start
  (group (or "." "!" "?" "..." "…"))
  (or eol (any " " "\t")
 (when (and previous
(stringp next)
(string-match punct-re next))
   (let* ((punct (match-string 1 next))
  (new-next (substring next (match-end 1)))
  (quote-re
   (rx (opt (and (group (or string-start (not (any "." "!" "?" 
"…"
 (group "\"")))
   (group (0+ (any " " "\t")))
   string-end))
  (new-previous
   (replace-regexp-in-string
quote-re (concat "\\1" punct "\\2\\3") previous)))
 (org-element-set-element next new-next)
 (org-element-set-element previous new-previous)

(defun org-cite-wrap-citation (citation info  move-punctuation)
   "Wrap an anonymous inline footnote around CITATION object in the parse tree.

INFO is the export state, as a property list.  When optional argument
MOVE-PUNCTUATION is non-nil, move punctuation character following citation 
before
it, when applicable.  If a quotation mark precedes the citation, move
punctuation before it, too.

The parse tree is modified by side-effect."
   (let ((footnote
  (list 'footnote-reference
(list :label nil
  :type 'inline
  :contents-begin (org-element-property :begin citation)
  :contents-end (org-element-property :end citation)
  :post-blank (org-element-property :post-blank 
citation)
 ;; Remove any white space before citation.
 (org-cite--set-previous-post-blank citation 0 info)
 ;; Possibly swap punctuation around citation.
 (when move-punctuation (org-cite--swap-punctuation citation info))
 ;; Footnote swallows citation.
 (org-element-insert-before footnote citation)
 (org-element-adopt-elements footnote
 (org-element-extract-element citation

;; test citation processor

(defun test-export-citation (citation nil nil info)
   (org-cite-wrap-citation citation info t)
   "...")

(org-cite-register-processor 'test
   :export-citation #'test-export-citation)
--8<---cut here---end--->8---

For example, the following document:

--8<---cut here---start->8---
#+cite_export: test

This is a test [cite:@a].

This is a test [cite:@a]?

This is a test [cite:@a]...

This is a "test" [cite:@a].

This is a "test." [cite:@a].

This is a *"test"* [cite:@a].

This is a *some /covoluted/ "test"* [cite:@a].

# Do nothing in the following cases.

This is a test [cite:@a]

This is a test. [cite:@a]

[cite:@a].

This is a "test" [cite:@a]
--8<---cut here---end--->8---

would become in ASCII export (without the uninteresting footnotes part):

--8<---cut here---start->8---
This is a test.[1]

This is a test?[2]

This is a test…[3]

This is a « test. »[4]

This is a « test. ».[5]

This is a *« test. »*[6]

This is a *some /covoluted/ « test. »*[7]

This is a test[8]

This is a test.[9]

[10].

This is a « test »[11]
--8<---cut here---end--->8---

Is it what you had in mind?


Yes, this should be equivalent to the behaviour in pandoc.

However, as I've said before, this behaviour is only correct in American 
English. TO quuote the Chicago Manual of Style 6.9: "In an alternative 
system, sometimes called British Style (as described in the /New Oxford 
Style Manual ...) ... only those punctuation points that appeared in the 
original material are included within the quotation marks." The same 
would be correct for German. Do you have an idea if/how this could be 
implemented?




Also, I have questions about punctuation.

Currently, 

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 16:07 schrieb Bruce D'Arcus:

On Tue, Apr 27, 2021 at 9:58 AM Denis Maier  wrote:


Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.

Only if you mentally parse it as a parenthetical author-date citation.

I don't think so. A period is a way we delimit sentences; is it not?


Sure, but what about this:
This is a sentence with a footnote attached to it.[fn:: This footnote 
belongs to the preceding sentence, doesn't it?]




...


I'm after all not totally sure we need a one-size-fits-all solution.

This particular sub-thread started when Andras noted he needed a way
to handle this case, and Nicolas coded up an initial example.

So I think we just need to establish what a reasonable default is.


Absolutely, I'm just asking what can be changed afterwards, maybe by 
providing an extended inline quotes syntax or so.


Denis

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 14:32 schrieb Bruce D'Arcus:

On Tue, Apr 27, 2021 at 7:44 AM Denis Maier  wrote:


Regarding simpler ways, why not just:

"A simple quote." [cite: @doe p. 45]


No, that's worse ;-)

Let's review basic requirements:

1. a plain text document really should be readable and its semantics clear
2. a user should be able to write their documents, and use different
output styles, without modifying that source document

Your example fails on 1 because it suggests the citation attaches to
(starts) the following sentence.
Only if you mentally parse it as a parenthetical author-date citation. 
If you read it as note citation then your conclusion doesn't follow 
naturally.




2 is hard given the details we've laid out, but if whatever solution
works for the majority of cases, and at worst requires the user either
a) to be aware of how the processing works and adjust accordingly+,
and/or b) to edit the final document a bit, that seems a reasonable
balance.

Bruce

+ a lot of the corner cases in citations come from a mismatch between
the need for a certain regularity and rigor required for
machine--processing, and users' desire for complete flexibility


Yes, that's indeed the question.

I'm after all not totally sure we need a one-size-fits-all solution. By 
way of analogy, biblatex has an \autocite command that scans ahead for 
following punctuation and moves that around.


Bla bla \autocite{doe20}.
can be
Bla bla (Doe 2020).
Or
Bla bla.\footnote{Doe 2020.)

"Bla bla" \autocite{doe20}.
can be
"Bla bla" (Doe 2020).
Or
"Bla bla".\footnote{Doe 2020.)

Then, for more complex cases you'll need special markup provided by the 
csquotes package. Maybe such a modular solution could be useful?


Denis

Re: wip-cite status question and feedback

[Denis Maier]

Am 27.04.2021 um 12:12 schrieb Bruce D'Arcus:

On Mon, Apr 26, 2021 at 4:35 PM Denis Maier  wrote:


Regarding the proposal: I think that could go in the right direction,
but in the current form it has the downside that you can't use the
prefix anymore, right?


Not sure why you would need a prefix for this case, but org-cite has
two levels of affixes. So maybe:

[cite/quote:Prefix ;quote @doe19]


What about keeping this separate, like so:

[quote: A simple quote.][cite: @doe p. 45]

But maybe even that is not necessary, and there might be simpler ways.


Hmm .. org doesn't have an inline quote, I guess?


Don't know. That was just a suggestion.

Regarding simpler ways, why not just:

"A simple quote." [cite: @doe p. 45]

That way no information is lost, and you could just move around 
punctuation as appropriate. A distinct syntax might be more powerful, 
but also less readable.


Denis

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Am 27.04.2021 um 09:36 schrieb Richard Lawrence:

"Bruce D'Arcus"  writes:


e.g. you can write

Smith claims foo [(cite): -@Smith2019; -@Smith2020; see also @Jones2018].

to render

Smith claims foo (2019; 2020; see also Jones 2018).



You identified the same case Andras and I discussed just above.

I think the solution is simple; with the updated syntax:

[cite/-:@Smith2019;@Smith2020; see also @Jones2018].

So the rule is (and this is for the processor to worry about, of
course, not org), when a suppress-author style is specified, the
suppression only applies to the author of the first citation
item/reference. That would generate the output you noted.


I think I see what you mean after parsing this a few times, but I would
rephrase the rule, since the way you phrased it initially seemed to
contradict the example. The point of my example was that author
suppression should also apply to the author of the *second* reference in
the list, though that happens to be the same author as the author of the
first item. So maybe the rule is more like: "when a suppress-author
style is specified, the suppression only applies to the initial segment
of citation items/references that have the same author as the first
reference"?


I think Bruce's point was that author suppresion list items other than 
the first lies in the jurisdiction of the citeproc, and has to be 
handled depending on citation style. (I.e., user input does /not/ matter 
here.)


[cite/-:@Smith2019;@Smith2020; see also @Jones2018].

=> Suppress author in the first item, Smith 2019.
=> whether the author's name in the second list item (Smith 2020) is 
shown depends on the citation style. Some styles repeat the author's 
name, others won't.


For comparison:

[cite:@Smith2019;@Smith2020; see also @Jones2018]

=> Don't suppress author in the first item, Smith 2019.
=> whether the author's name in the second list item (Smith 2020) is 
shown depends on the citation style. Some styles repeat the author's 
name, others won't.


Denis

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

[Denis Maier]

 
 
  
   
  
  
   
Nicolas Goaziou <m...@nicolasgoaziou.fr> hat am 26.04.2021 23:11 geschrieben:
   
   

   
   

   
   
    Denis Maier <denisma...@mailbox.org> writes:
   
   

   
   

 No, I was not talking about having multiple input files, but about


 having multiple bibliographies in the output doc.


 Perhaps each filtered in some way:

   
   

 #+print_bibliography: [style] [filter1]


 #+print_bibliography: [style] [filter2]

   
   

 Obviously, filter1 and filter2 must be defined somewhere. The use case


 would be something along these lines:


 - One bibliography with all the works by author X, a second


 bibliography with everything else.


 - One bibliography with books, the other with webpages

   
   
It is already possible to write multiple "print_bibliography" keywords
   
   
(even though some citation systems, like biblatex, do not support it,
   
   
IIUC). However their value is limited to style at the moment.
   
  
  
   Great, so the basic functionality is there. (by the way, biblatex is the only system that really supports multiple bibliographies.)
   
  
  
   
   
It may be possible to send anything past the style string (i.e.,
   
   
starting after the first space) to the processor, as a sixth (!)
   
   
argument, and let it deal with it.
   
   
  
  
   Ok. I've discussed this with John MacFarlane from Pandoc some time ago. IIRC, he said there are two different approaches to that problem: either do the filtering in the processor, or just let the processor return a structure that contains the necessary information and do the filtering itself in the backend.
   
  
  
   
  
  
   Denis
   
  
  
   
--
   
   
Nicolas Goaziou
   
  
 

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

[Denis Maier]

Am 26.04.2021 um 22:33 schrieb Nicolas Goaziou:

Denis Maier  writes:


Oh, and what do you think regarding the multiple bibliographies
question?

As far as Org is concerned, you can have multiple "bibliography"
keywords, e.g.,

   #+bibliography: file1.bib
   #+bibliography: file2.bib

Internally, the bibliography is stored as a list of absolute file names.

Is that what you have in mind or are you talking about something else?

Regards,
No, I was not talking about having multiple input files, but about 
having multiple bibliographies in the output doc.

Perhaps each filtered in some way:

#+print_bibliography: [style] [filter1]
#+print_bibliography: [style] [filter2]

Obviously, filter1 and filter2 must be defined somewhere. The use case 
would be something along these lines:
- One bibliography with all the works by author X, a second bibliography 
with everything else.

- One bibliography with books, the other with webpages

Denis

Re: wip-cite status question and feedback

[Denis Maier]

Am 26.04.2021 um 16:54 schrieb Bruce D'Arcus:

I had an idea on this, though it may not be a good one ...

On Sat, Apr 24, 2021 at 2:39 PM Bruce D'Arcus  wrote:


On Sat, Apr 24, 2021 at 1:47 PM Nicolas Goaziou  wrote:


Hello,

"Bruce D'Arcus"  writes:


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.

In any case, this sort of punctuation modification should be possible.


Could you show more example of this, possibly including quotes the
citation, or better, a precise description of the punctuation
modification you have in mind?


Yes.

Denis lays it out in this comment:

https://github.com/citation-style-language/documentation/issues/139#issuecomment-825934813

What he's arguing is that the rules vary by locale, with German, for
example (he's employed at a Swiss-German institution, I believe),
having different conventions than English, and American English
different than British English.

But an example from American English for illustration, derived from
Denis' examples.

"A simple quote" [cite:@doe].

When rendered, that should be this in an author-date style:

"A simple quote" (Doe 2021).

... and this in a note style:

"A simple quote."[^1]

So that rule would suggest something like:

- if a citation concludes a sentence, move the note mark and whatever
trailing quotation mark, outside the period.

But, Denis continues, "While this is perfectly acceptable in American
English, it is not in German, or even in British English. Here we have
to know whether the final period is part of the original quotation. If
yes, it will be put inside the quotes, otherwise outside." I'll paste
the rest of his examples at the end.

It's possible his rule here is more general, and would still be
acceptable in American English.


The idea is this: make use of a "quote" style and abuse the item
prefix for the quote content?

So using his example:

[cite/quote:;A simple quote. @doe20]

A processor could then know the citation is associated with a quote
that ends a sentence, vs (note missing period):

[cite/quote:;A simple quote @doe20]

... and then more easily adjust accordingly, without needing to know
anything about the surrounding punctuation.

Does that make sense?


Reminds me a bit of how the latex csquotes package works, which is often 
used together with biblatex, it even was developped by the original 
biblatex author before he mysteriously disappeared about a decade ago.


In addition to simple commands like \enquote{something} that simply 
render the argument in quotes this package also has more complex 
commands such as \textcquote or blockcquote. With these commands you can 
combine a quotation with a citation:
\textcquote[〈prenote〉][〈postnote〉]{〈key〉}[〈punct〉]{〈text〉} 
〈tpunct〉


\textcquote[45]{doe}[.]{This is the quotation}
Note the punctuation of the original quote is included in a special 
argument in brackets.

If the period weren't part of the quotation, you'd simply do:
\textcquote[45]{doe}{This is the quotation}.

Regarding the proposal: I think that could go in the right direction, 
but in the current form it has the downside that you can't use the 
prefix anymore, right? What about keeping this separate, like so:


[quote: A simple quote.][cite: @doe p. 45]

But maybe even that is not necessary, and there might be simpler ways.

WDYT?

Denis

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

[Denis Maier]

Oh, and what do you think regarding the multiple bibliographies question?

Denis

Am 26.04.2021 um 22:02 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On this, on the other (big) wip-cite thread, Nicolas said the following:

"A drawback with allowing emphasis there is that prefix and suffix become
parsed data and not plain string anymore. As a consequence, searching
through them, e.g., when looking for locator names, requires an
additional level of indirection, since you need to first transform
parsed data back into plain text."

Nicolas: I get that you need more code to do this, but are there other
practical consequences of allowing more than plain-text?


The code I need to write does not count, really. It is 10 locs at most,
without the tests.

My concern is the additional burden for processor developers. They will
need to shift from one representation to the other, this is not
convenient. Also some tasks then become an order of magnitude harder.

For example, let's consider the suffix: " p.32 and following" If it is
plain text, I can recognize p.32 as a locator, and replace it with "page
32" using something like `replace-regexp-in-string'.

Now, if it is a somewhat opaque parsed string, I need to first expand
it, for example with `org-element-interpret-data', modify the output as
above, and then parse it again to get a new parsed string.

I can no longer (concat "(" prefix author "," year suffix ")") either,
because prefix and suffix are not strings anymore. I need to

   (format "(%s%s, %s%s)"
   (org-export-data prefix info)
   (org-export-data author info)
   year;I assume year cannot contain problematic characters
   (org-export-data suffix info))

So, nothing impossible, but still slightly inconvenient.

Regards,

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

[Denis Maier]

Am 26.04.2021 um 22:02 schrieb Nicolas Goaziou:

Hello,

"Bruce D'Arcus"  writes:


On this, on the other (big) wip-cite thread, Nicolas said the following:

"A drawback with allowing emphasis there is that prefix and suffix become
parsed data and not plain string anymore. As a consequence, searching
through them, e.g., when looking for locator names, requires an
additional level of indirection, since you need to first transform
parsed data back into plain text."

Nicolas: I get that you need more code to do this, but are there other
practical consequences of allowing more than plain-text?


The code I need to write does not count, really. It is 10 locs at most,
without the tests.

My concern is the additional burden for processor developers. They will
need to shift from one representation to the other, this is not
convenient. Also some tasks then become an order of magnitude harder.


While I cannot speak for the processor developers, I still want to throw 
in that at least the major CSL processors do handle formatting in 
affixes in one way or the other. The Haskell citeproc that is used by 
pandoc treats the suffixes as markdown, citeproc-js uses some sort of 
HTML-like tags for things like italics, bold, sub-/superscript, and a 
few more things.




For example, let's consider the suffix: " p.32 and following" If it is
plain text, I can recognize p.32 as a locator, and replace it with "page
32" using something like `replace-regexp-in-string'.

Now, if it is a somewhat opaque parsed string, I need to first expand
it, for example with `org-element-interpret-data', modify the output as
above, and then parse it again to get a new parsed string.

I can no longer (concat "(" prefix author "," year suffix ")") either,
because prefix and suffix are not strings anymore. I need to

   (format "(%s%s, %s%s)"
   (org-export-data prefix info)
   (org-export-data author info)
   year;I assume year cannot contain problematic characters
   (org-export-data suffix info))

So, nothing impossible, but still slightly inconvenient.



If it isn't impossible I'd be strongly in favor of adding this. I'm 
pretty sure authors will miss it otherwises.


Denis

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Am 26.04.2021 um 09:53 schrieb Denis Maier:

Hi,

just some general remarks on that issue: I tend to think that treating 
"suppress-author" as a mode/style/command would indeed be appropriate. 
As the minus shorthand is inherited from pandoc, it might be worth 
pointing out that pandoc's syntax owes quite a lot to the markdown 
philosophy, which is also emphasized by pandoc:


Markdown is intended to be as easy-to-read and easy-to-write as is 

feasible.


Readability, however, is emphasized above all else

(https://daringfireball.net/projects/markdown/syntax#philosophy)

That is, markdown tries to use a syntax as concise as possible, without 
verbose commands and such. See e.g. this discussion: 
https://groups.google.com/g/pandoc-discuss/c/ydG9CI_XEEU/m/3LHxvp23BAAJ


The price for this is a certain opaqueness, and, to a certain degree, a 
loss of precision, expressiveness and extensibility.


Anyway, back to the modes question:

#+begin_example
[@doe]

[-@doe]

@doe

@doe [34]

-@doe [34]
#+end_example

gives us in pandos AST:

#+begin_pandoc_ast
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 2, 
citationHash = 0}] [Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = AuthorInText, citationNoteNum = 3, 
citationHash = 0}] [Str "@doe"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = AuthorInText, 
citationNoteNum = 4, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = SuppressAuthor, 
citationNoteNum = 5, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]]

#+end_pandoc_ast

So, suppress author is essentially a mode here.


Addendum:

[@doe; -@foo]

gives us:

[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0},Citation {citationId = "foo", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe;",Space,Str "-@foo]"]]


So, each citation in that cite has an individual mode, which goes in the 
direction indicated by Richard Lawrence in his earlier message. Maybe 
that speaks for two levels of styles, one pertaining to the whole 
citation group, one to the individual citations. Does that make sense?




FWIW, it might also be interesting to look at biblatex:
biblatex has a textcite command:
\textcite{doe2021} => Doe (2021)

Now, if you want to cite multiple entries, each with prefix and suffix, 
you'll need a special variant \textcites!

\textcites[12]{foo}[34]{bar} argue ...
=> Foo (2021, p. 12) and Bar (2021, p. 34) argue ...

I'm not sure how that fits into the org context. Interestingly, I 
couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
... argues". You'd probably have to resort to lower level commands such 
as \citeauthor in combination with other commands.

\citeauthor{doe} \parencites*[34]{doe}{smith}

Denis

Am 25.04.2021 um 22:12 schrieb Bruce D'Arcus:
On Sun, Apr 25, 2021 at 3:48 PM András Simonyi 
 wrote:


Dear All,

On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus  wrote:

How would you deal with these?

#+begin_example
[cite/-:@doe20; @doe21]
[cite/-:@doe20; see also @smith19]
[cite/text:@doe20; see also @smith19]
#+end_example

My thought is you want to treat the author of the first listed cite as
suppressed, or placed in-text in the last case, but that you wouldn't
touch the other author?


yes, exactly -- since it's difficult to see (at least for me) how the
context could supply the author information for the subsequent cites.


So the output for the first one would be:

(2020, 2021)

..., and not:

(2020, Doe 2021)

As in, you would suppress the author not on the first cite (what you
wrote in the original reply), but the author of the first cite?

To me, that's the only wrinkle of having this a citation-level style;
that a processor would need to be smart enough to handle cases like
that, for output styles that require it.

But otherwise it's easier and more efficient for the user.

Bruce

Re: org-cite: make 'suppress-author' a citation 'style'

[Denis Maier]

Hi,

just some general remarks on that issue: I tend to think that treating 
"suppress-author" as a mode/style/command would indeed be appropriate. 
As the minus shorthand is inherited from pandoc, it might be worth 
pointing out that pandoc's syntax owes quite a lot to the markdown 
philosophy, which is also emphasized by pandoc:


> Markdown is intended to be as easy-to-read and easy-to-write as is 
feasible.

>
> Readability, however, is emphasized above all else
(https://daringfireball.net/projects/markdown/syntax#philosophy)

That is, markdown tries to use a syntax as concise as possible, without 
verbose commands and such. See e.g. this discussion: 
https://groups.google.com/g/pandoc-discuss/c/ydG9CI_XEEU/m/3LHxvp23BAAJ


The price for this is a certain opaqueness, and, to a certain degree, a 
loss of precision, expressiveness and extensibility.


Anyway, back to the modes question:

#+begin_example
[@doe]

[-@doe]

@doe

@doe [34]

-@doe [34]
#+end_example

gives us in pandos AST:

#+begin_pandoc_ast
[Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = NormalCitation, citationNoteNum = 1, 
citationHash = 0}] [Str "[@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = SuppressAuthor, citationNoteNum = 2, 
citationHash = 0}] [Str "[-@doe]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [], citationMode = AuthorInText, citationNoteNum = 3, 
citationHash = 0}] [Str "@doe"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = AuthorInText, 
citationNoteNum = 4, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]
,Para [Cite [Citation {citationId = "doe", citationPrefix = [], 
citationSuffix = [Str "34"], citationMode = SuppressAuthor, 
citationNoteNum = 5, citationHash = 0}] [Str "@doe",Space,Str "[34]"]]]

#+end_pandoc_ast

So, suppress author is essentially a mode here.

FWIW, it might also be interesting to look at biblatex:
biblatex has a textcite command:
\textcite{doe2021} => Doe (2021)

Now, if you want to cite multiple entries, each with prefix and suffix, 
you'll need a special variant \textcites!

\textcites[12]{foo}[34]{bar} argue ...
=> Foo (2021, p. 12) and Bar (2021, p. 34) argue ...

I'm not sure how that fits into the org context. Interestingly, I 
couldn't find an easy way to get "Doe (2021, p.34; see also Smith 2020) 
... argues". You'd probably have to resort to lower level commands such 
as \citeauthor in combination with other commands.

\citeauthor{doe} \parencites*[34]{doe}{smith}

Denis

Am 25.04.2021 um 22:12 schrieb Bruce D'Arcus:

On Sun, Apr 25, 2021 at 3:48 PM András Simonyi  wrote:


Dear All,

On Sun, 25 Apr 2021 at 14:50, Bruce D'Arcus  wrote:

How would you deal with these?

#+begin_example
[cite/-:@doe20; @doe21]
[cite/-:@doe20; see also @smith19]
[cite/text:@doe20; see also @smith19]
#+end_example

My thought is you want to treat the author of the first listed cite as
suppressed, or placed in-text in the last case, but that you wouldn't
touch the other author?


yes, exactly -- since it's difficult to see (at least for me) how the
context could supply the author information for the subsequent cites.


So the output for the first one would be:

(2020, 2021)

..., and not:

(2020, Doe 2021)

As in, you would suppress the author not on the first cite (what you
wrote in the original reply), but the author of the first cite?

To me, that's the only wrinkle of having this a citation-level style;
that a processor would need to be smart enough to handle cases like
that, for output styles that require it.

But otherwise it's easier and more efficient for the user.

Bruce

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

[Denis Maier]

Hi everyone,

great to see that there's been so much progress since this issue has 
last been discussed! Looks really impressive so far.


Two comments/questions:

- I think it should be possible to use some markup in prefixes and suffixes.
- Will this proposal allow multiple bibliographies? I think that's been 
discussed last year or so.


Best,
Denis

Am 22.04.2021 um 01:34 schrieb Nicolas Goaziou:

Hello,

I just rebased "wip-cite-new" branch, which now includes citation
syntax, and an interface between external citation processors and the
rest of Org. I'll throw in a demo at the end of this message. TL;DR:
search for "Demo time".

As a reminder, the full citation syntax is

   [cite/style:common prefix ;prefix -@key suffix; ... ; common suffix]

Everything is optional, except the brackets, "cite" and the colon. Also
the citation must contain at least a key. So its minimal form is:

   [cite:@key]

or its "suppress author" variant:

   [cite:-@key]

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.

The syntax also introduces three keywords (square brackets are for
optional arguments):

#+bibliography: filename
#+print_bibliography: [style]
#+cite_export: backend-name [bibliography-style] [citation-style]

Now, the real novelty is the new "oc.el" library, which is an API to
operate simply on citations. I paste here its commentary section.


 This library provides tooling to handle citations in Org, e.g,
 follow, fontify, and export them, respectively called "follow",
 "activate" and "export" capabilities. Libraries responsible for
 providing some, or all, of these capabilities are called "citation
 processors".
 
 Such processors are defined using `org-cite-register-processor'.

 Using this function, it is possible, in addition to giving it
 a name, to attach functions associated to capabilities.  As such,
 a processor handling citation export must set the
 `:export-citation' property to an appropriate function.  Likewise,
 "activate" capability require an appropriate `:activate' property,
 and, unsurprisingly, "follow" capability implies `:follow'
 property.
 
 As a user, the first thing to do is setting a bibliography, either

 globally with `org-cite-global-bibliography', or locally using one
 ore more "bibliography" keywords.  Then one can select any
 registered processor for each capability by providing a processor
 name to the variables `org-cite-activate-processor' and
 `org-cite-follow-processor'.
 
 The "export" capability is slightly more involved as one need to

 select the processor providing it, but may also provide a default
 style for citations and bibliography.  These three parameters, or
 triplet, can be set in `org-cite-export-processor' variable, or in
 a document, through the "cite_export" keyword.
 
 Eventually, this library provides some tools, mainly targeted at

 processor implementors.  Most are export-specific and are located
 in the "Tools only available during export" section.  The few
 others can be used directly from an Org buffer, or operate on
 processors.  See "Generic tools" section.


There are two points of view to consider here. As a user, as stated
above, you first need to provide a bibliography, for all documents using
the `org-cite-global-bibliography' variable, or for a single document
(or a set of documents, using "setupfile" keyword) with

 #+bibliography: one-file.bib
 #+bibliography: another-file.ext
 #+bibliography: "some file with spaces"

You can use both the variable and the keywords, in which case files are
_accumulated_ in the list.

Then when you

   (require 'org-cite-something)

the "oc-something.el" library, in addition to possibly many other tools,
registers a "citation processor", for example `something'. That
processor may operate on any of the three entry points "activate",
"follow", or "export". If you are not sure about which one it supports,
you may inspect the processor with, e.g.,

   (org-cite-processor-has-capability-p 'something 'follow)

If this is non-nil, you can set `org-cite-follow-processor' to
`something'. Once done, calling `org-open-at-point' on a citation starts
whatever action the processor defined. If the variable is nil, nothing
happens.

If you need to use a different processor for a given document, consider
using file local variables.

Likewise, you can fontify citations according to a given processor using
`org-cite-activate-processor'. This time, however, Org provides some
fontification even when the variable is nil. The default set-up merely
applies new `org-cite' and `org-cite-key' faces on citations.

The "export" capability introduces the concept of "style", which is an