Re: wip-cite status question and feedback

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus" <address@hidden> writes:

> Note that in CSL processors, the locators are meaningful key-values,
> basically; not plain text strings.

OK, but it is enough for Org to feed a CSL processor with, e.g.,

  key    -> "@doe99"
  prefix -> "see "
  suffix -> ", pp. 33-35"

Then CSL processor does its job to extract whatever information it
needs. Am I right?

> While I of course can't speak for John, I would hope and expect org
> ref to support the new syntax.
>
> I would hope and expect the same of other packages (like ebib) that
> use their own custom syntax.

I hope so, too. But it would help if developers could chime in and tell
what API Org should provide. This is particularly important since Org
will only provide the API, without any specialized implementation. More
on this at the end of the message.

> 1. just have a super simple citation export formatter, with (per
>    above) room to configure an external one

Sure. Org should provide default export for citations in LaTeX, ASCII,
HTML, Texinfo and ODT. Suggestions are more than welcome.

> 2. while I don't know its status, include citeproc-org in org and
> emacs

I think citeproc-el should ship with Emacs, but I cannot speak for
Emacs; it would be nice to ask Emacs developers about it.

> I'd say if citeproc-org is far along and free of substantial bugs, 2
> might make sense. I am, of course, biased, but CSL's been widely
> deployed in the wild for more than a decade, and there are thousands
> of available styles.
>
> Otherwise, and more likely, 1 would be the best path; users get basic
> output formatting for citations, but then can plug in more elaborate
> tools (citeproc-org, citeproc-hs*, etc.) if they need them.

Option 2 makes a lot of sense if citeproc-el is integrated with Emacs.
Until them, I agree that option 1 is the way to go at the moment.

> WDY about that?

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?

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

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

   - [ ] 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.

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?

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

4. Anything else?


We need help, or at least opinion, from actual implementors to go
further. I'm CC'ing some of them.

I can take care of the implementation (with some time, my plate is full
at the moment), but I'm mostly incompetent about design issues.

So, what about ticking off some items?

Regards,

-- 
Nicolas Goaziou