Re: wip-cite status question and feedback

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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