Re: wip-cite status question and feedback

["Bruce D'Arcus" <bdarcus@gmail.com>]

On Wed, Apr 8, 2020, 5:32 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

[snip]

> Sounds like a plan. Let me summarize it a bit :
>
> 1. [ ] Finalize Org citation syntax. It is mostly good, but we need to
>    decide about the following points:
>
>    - [ ] Should it include both "(cite):" and "cite:", i.e., does it
>      make sense to provide a (very limited) style specification piece
>      wise?

There are two questions here; right?

So (cite:) is the standard citation form (in the pandoc syntax
[@doe19]), and cite: is the bare variant @doe19?

On the latter, probably yes, depending on how ready citeproc.el/org is
to take over processing for more advanced needs.

>    - [ ] Should it include /global/ prefix and suffix?

On further reflection, and discussion on the csl forum, I think yes.

The flat pandoc syntax works well, but does break down in one situation:

Where you have a multicite, and where the output processor resorts them.

Global affixes would fix that.

>    - [ ] Should we keep the short specification, i.e., "[@key]"?

If you kept it, would it be possible to allow more than one key?

So something like [@doe17; @doe18]?

>    - [ ] What kind of markup do we allow in a citation? At the moment
>      the exhaustive list is: bold, code, entity, italic, latex-fragment,
>      strike-through, subscript, superscript, underline, verbatim and
>      line breaks.

I don't see any downside to being liberal here. Do you?

Though most common by far, I think, would be just bold and italic.

> 2. [ ] Decide about API Org should provide for it to be useful. Here are
>    some low hanging fruits:
>
>    - [ ] List all ".bib" files associated to the document,
>
>    - [ ] List all citations,
>
>    - [ ] Return citation key at point, if any.
>
>    - Anything else?
>
>    Moreover, we need to decide about how external processors could plug
>    into the export framework.
>
>    - [ ] For example, it could be a simple variable bound to a list of
>      functions. Each function accepts three arguments: the export
>      back-end, as a symbol, the full citation, as a list of triplets
>      (key, prefix, suffix) along with global prefix/suffix, and the
>      usual INFO communication channel. Does it need more?
>
>    - [ ] Also, the prefix/suffix may contain some Org markup, so this
>      needs to be also processed. Should it happen before, or after the
>      external processor does its job? I.e., should the function
>      translate into Org or target format?

Obviously on the above group of questions, would be really good to
hear from Andras, but the citeproc-el docs should be helpful?

https://github.com/andras-simonyi/citeproc-el#usage

> 3. [ ] Specify the kind of basic translation that be done out of the
>    box? Ideally, every non-derived back-end should do something, even
>    basic. Therefore, we need to propose some translation pattern for
>    each of the following:
>
>    - [ ] ASCII
>
>    - [ ] HTML
>
>    - [ ] LaTeX
>
>    - [ ] ODT
>
>    - [ ] Texinfo

So this would the default output for each format. This would be
assuming, to go back to earlier posts here, basic formatting built it,
and not integrating citeproc-el?

Bruce