RE: wip-cite status question and feedback

["Gustav Wikström" <gustav@whil.se>]

Hi,

I'm curious. So take this for what it is; I.e. curiosity. What /exactly/ is meant with a citation here? Is it a new general concept in Org mode, or is it something more narrow, as an extension for some specific third party software? Would I be able to use it without that third party software? What would the content of a citation be? Is it a link to some source plus annotations and formatting? Is it only the link? Is it also the formatting? Is it something else entirely? I'm wondering since Org mode has existing facilities for much of this already. But maybe not packaged together for citations just yet? Is there any purpose of thinking of citations as a wrapper for already existing functionality? Or could the links-syntax be extended with more properties and auxiliary functionality to fulfill the need for citations?

Maybe these questions have been discussed already. Sorry in that case, it was a long thread and I admit to not having read everything. I'm simply wondering since there may be reason for reusing and extending existing functionality before creating something new. Hence the question of what exactly a citation consists of above. Because Org mode can already provide links to external content. And, to me at least, a citation is simply that: a link. A link which is the key to the information that is to be marked as the source of the citation. Auxiliary functionality on top of that could provide facilities to collect all such links into bibliographies based on link-backend and properties of that link. Configurations (emacs config or org mode properties, [info:org#Property Syntax]) could instruct on formatting.

But as I said in the beginning. Take this as curiosity. And take it as questions for someone not very much into the academic world at this time, not having to bother with typesetting, formatting and latex related issues.

Kind regards
Gustav

> -----Original Message-----
> From: Emacs-orgmode <emacs-orgmode-bounces+gustav=whil.se@gnu.org> On
> Behalf Of Nicolas Goaziou
> Sent: den 8 april 2020 11:32
> To: Bruce D'Arcus <bdarcus@gmail.com>
> Cc: Joost Kremers <joostkremers@fastmail.fm>; emacs-orgmode@gnu.org;
> András Simonyi <andras.simonyi@gmail.com>; John Kitchin
> <jkitchin@andrew.cmu.edu>
> Subject: Re: wip-cite status question and feedback
> 
> Hello,
> 
> "Bruce D'Arcus" <bdarcus@gmail.com> 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