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