On Wed, Apr 8, 2020, 5:32 AM Nicolas Goaziou <m...@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
