Re: wip-cite status question and feedback

[András Simonyi]

Dear All,

thank you very much for bringing this forward and thanks to Nicholas
for his work and detailed write-up on the API! Unfortunately, I'm
extremely busy right now, but will try to comment in detail on the
coming days, most probably on Thursday. I'm very excited by the new
developments!

best regards,
András

On Mon, 12 Apr 2021 at 15:19, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Hello,
>
> "Bruce D'Arcus" writes:
>
> > Maybe since Nicolas has been around lately, he can weigh in?
>
> I guess I can make a summary about the current state of the citations
> branch, i.e., what is done, what is missing.
>
> There are three major steps to complete in order to add citations in
> Org: defining the syntax, designing the Org API for citation processors,
> and writing a default processor.
>
> The syntax is complete in "wip-cite-new" branch. For the record, in its
> full glory, it can look like this:
>
>   [cite/style: global prefix; prefix -@key suffix ; ... ; global suffix]
>
> "/style", "global prefix", "prefix", "-" marker, "suffix" and "global
> suffix" are all optional. So, in its minimal form, it can be as simple
> as:
>
>   [cite:@Doe:1995a]
>
> The syntax also includes a new #+bibliography keyword, which, when
> paired with a new `org-cite-global-bibliography', defines global or
> local bibliographies.
>
> For exporting needs, I also introduced #+print_bibliography,
> #+citation_style and #+bibliography_style keywords.
>
> Now about the API, which is partly implemented on a local branch.
>
> Citations processors, in addition to any tools they may provide, can
> integrate into Org in three distinct areas: opening (with
> `org-open-at-point'), fontification, and export.
>
>   - "opening" action is straightforward. All is needed for the processor
>     is to provide a function accepting two arguments: the citation key,
>     as a string, and possibly a universal argument, which it may ignore,
>     or not.
>
>     All this is already implemented locally.
>
>   - "exporting" action is trickier, because there are multiple ways to
>     do the integration, and, since I'm not an implementor for citation
>     processors, I don't have an accurate view about what is the best
>     design. Anyway, here is the
>
>     First, export happens as pre-process, before export back-ends are
>     introduced. IOW, export back-ends are never going to see a citation
>     object, which means no support whatsoever is needed on their end.
>
>     Support export requires two functions. The first function is
>     responsible for rendering a bibliography. Its arguments are the list
>     of citations in the document, the list of bibliography files, the
>     style, if any, and the export back-end. It should return a string.
>
>     The second mandatory function is obviously responsible for rendering
>     citations. It is called with a citation object, the desired style,
>     if any, and the export back-end, the full list of citations objets
>     in the document, and the list of bibliography files. It should also
>     return a string. Org provides a helper function to determine the
>     footnote containing a citation (and its label, or number) from
>     a citation object.
>
>     In the functions described above, I don't know if the arguments are
>     sufficient. I would love to hear about citeproc-org and org-ref
>     developers about this.
>
>     Also, note that style is an indication. Export is requested to
>     handle regular [cite:...] syntax. Unknown styles should fall-back to
>     this.
>
>   - "fontification" is meant to give full access to face selection, what
>     is really displayed, additional keymaps, all using a single
>     function.
>
>     At the moment, I have no idea about what arguments would be useful.
>     I think John Kitchin gave ideas about this already on this ML.
>     I have to re-read his posts on the subject. In any case, feedback
>     welcome.
>
>     This not implemented yet.
>
> A citation processor does not need to provide integration in all these
> areas. Users may be able to mix and match processors. This is another
> (minor) point which is yet to be designed. How is a user supposed to
> select a processor for each integration area? It could be done through
> three variables, e.g.,
>
>   (setq org-cite-display-processor 'org-ref)
>   (setq org-cite-export-processor 'citeproc)
>   (setq org-cite-follow-processor 'default)
>
> I think it is unlikely for a user to locally select "display" and
> "follow" processors. However, we need a way to use a local export
> processor for a given document. I may need to introduce
> a #+citation_processor keyword during export. Any other idea?
>
> The last step is implementing a default processor. The point is to
> provide a self-contained, very basic processor handling all three areas
> described above.
>
> I started implementing one. It relies on built-in bibtex.el library, so
> it assumes bibliography is written as a BibTex file. At the moment it
> properly "follows" citations. It also exports citations as (Name, date).
> However, it doesn't export bibliographies yet. It does not fontify
> either.
>
> As a conclusion, besides the syntax, the branch is not ready for
> inclusion yet. There are a few design questions about the API to answer.
> Once done, and as long as no one has high expectations about the default
> processor, this last part should not be too hard to complete.
>
>
> Regards,
> --
> Nicolas Goaziou