Re: wip-cite status question and feedback

[András Simonyi]

Dear All,

On Sun, 18 Apr 2021 at 15:11, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

> I am also leaning towards removing the possibility to include Org syntax
> (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly
> useful (you can move the bold part outside of the citation object), and
> yet, adds a layer of complexity on top of the citation object.
>
> Can we assume (global)prefix/suffix are just plain text?
>

well, I think there might be some legitimate use cases, e.g.,
(see Smith 1997, p. 2, see also p. 33, pp. 45-47, but /cf./ p. 103)
here one might want cf. to be set in italics, and I can imagine
situations in which emphasizing a phrase in a prefix/suffix can be
useful,
but IMHO we can certainly start with assuming just plain text.

> In any case, Org has no clue about the "location" of the citation. It
> can provide the suffix associated to the citation key, but it is up to
> the citation processor to extract page information out of it. If this is
> desirable, we need to provide the full citation object instead of the
> key. I don't know if it is worth the trouble.

It would definitely be useful for making possible more sophisticated
opening actions.

> > Am I correct in assuming that the returned bibliography should be
> > rendered as a legitimate Org fragment regardless of the back-end?
>
> I think it should be rendered as target format, to be on par with
> citation handling.
>
> You may, however, use Org format as an intermediate step, and then, call
> `org-export-data-with-backend' (from "ox.el") on it. If this is
> desirable, I need to also provide a fifth `info' argument to the list
> above.

This is a crucial point: when a note CSL style is used, the export has
to generate footnotes "around"  those citations  which are not already
in a footnote.
Since citeproc-org generates only Org fragments, this is very simple
to do (with anonymous footnotes), but for other formats it can be
rather complicated. Would calling `org-export-data-with-backend'
handle this? If yes then adding an argument  to request this call
would be very useful.

> >
> > This might not be an important point, but citeproc-el is rather
> > citation list oriented in the sense that it processes the list of all
> > citations and returns a list of their formatted counterparts, so it
> > might be useful to provide this "bulk" API as well, at least as an
> > optional addition.
>
> I don't think any addition to the suggested API is required. If you
> cannot split citation processing, you may fill a temporary cache holding
> all exports on first citation (the full list of citations objects is
> provided right from the start), then read from that cache on subsequent
> citations.
>
> WDYT?

Basically I agree,  it would probably be premature optimization to
provide anything else at this point.

> I don't understand what you call the "identity of the notes". Could you
> provide an example?

I meant only that knowing whether a citation is in a footnote or not
is not enough -- if a numerical note index is available which
specifies
the precise position of the note among the footnotes then this is
exactly the information what is needed.

> Situation in nested footnotes can be ambiguous, tho. In the following
> example, is the expected order @a then @b then @c?

--8<---------------cut here---------------start------------->8---
Text[fn:1] [@cite:@c]

[fn:1] This[fn:2] is [cite:@b].

[fn:2] [cite:@a]
--8<---------------cut here---------------end--------------->8---

Yes, I think the order here is @a  @b and @c.

>> there is CSL-JSON and a CSL-YAML etc. If different "display"
>> and "follow" processors will be able to handle different formats then
>> the users might want to change those settings locally as well, based
>> on the bibliography format, but I'm not sure what kind of
>> infrastructure would be the best way of supporting this. (E.g.,
>> registering format support information about the processors and
>> choosing on this basis?)

>I don't have an idea about it either. This is not a blocker, tho. We can
>revisit it later, once we have "something" working.

Absolutely, in the long run probably a way of explicitly specifying
the bibliography format/type will be needed, but just a (file)name  is
a good starting point.

thanks & best regards,
András


> > infrastructure would be the best way of supporting this. (E.g.,
> > registering format support information about the processors and
> > choosing on this basis?)
>
> I don't have an idea about it either. This is not a blocker, tho. We can
> revisit it later, once we have "something" working.
>
> Thanks for your feedback.
>
> Regards,
> --
> Nicolas Goaziou