Re: wip-cite status question and feedback

[John Kitchin <jkitchin@andrew.cmu.edu>]

>>>   - "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.

For fontification in an org-file, what I currently find helpful in org-ref:

1. the citations have a face that makes them stand out (it is usually a
green color, unless the key is not found in the bibfiles, and then it is
red). I have a way to turn that off though, because it can cause
performance issues in large documents with large bibliographies.

2. There is a tooltip that shows a lightly formatted reference. The
tooltip is fairly crude, and not related to any particular bibliography
style. It would be great if it did, but so far the effort to achieve
that has been too high. With an integrated citation processor it might
be better, but I am skeptical they will ever look quite like they would
in a latex export, especially if you use latex code in your bibtex
files. This tooltip only needs to be good enough in my opinion to tell
what the key is representing at that point.

3. I like having keymaps on the citations. The most common use for me is to
press S-up to sort a sequence of citations by year, followed by S-left
and S-right to transpose citations in a sequence, followed by
M-left/right to navigate across citations.

4. I tend to have my follow function launch a hydra menu, which provides
many action choices. I think this is easier than trying to remember a lot of
different commands that also work at the citation at point. I started
this with helm, then ivy and now hydra. I can't tell if a new generation
of approaches like selectrum, or the package bibtex-actions will
eventually replace these. This isn't quite fontification, but since you
can put keymaps on with fontification, it isn't fully indpendent either.

5. I mostly think the citations should be displayed as plain text, i.e.
not replaced by a numbered overlay, or equivalent. I could see hiding
the [], but also guess that would be more confusing than beneficial.

>>
>> I'm thinking about implementing a "fontification" solution which would
>> use citeproc-el with a standard style to produce nice preview-like
>> representations of the citations in the buffer. This would require
>> basically the same pieces of information as citation export I think,
>> although it might be made strictly  local, working only with the
>> single citation object plus the bibliography information.
>
> OK. Citation object and list of bibliography files as arguments are
> a starting point.
>
>>> 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?
>>
>> All of these solutions seem to be good starting points.  As for
>> setting the "display" and "follow" processors locally, this leads to a
>> question which probably has to be addressed at a certain point: that
>> of bibliography formats. The Emacs world is currently rather BibTeX
>> centered, but biblatex is an important (and rather different)
>> alternative, and there is CSL as well which I expect to become more
>> and more relevant (it's citeproc-el's native format). Moreover, these
>> formats have some variants, e.g., for BibTeX there is also org-bibtex,
>> for CSL 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.

This suggests that there is an API of required functions that have a
defined interface for these. That is sort of what org-ref does to
support helm, and a few ivy backends for completion. It is mostly done
by defining some variables that point to functions in those backend
libraries, and the variables are funcalled in a core library.

for example in the follow processor there would be a function that takes
a key, and some bibliography source information, and it would be
responsible for doing what you mean by follow.

export is trickier, but same idea.


>
> Thanks for your feedback.
>
> Regards,


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