From: "András Simonyi" <email@example.com> To: "Bruce D'Arcus" <firstname.lastname@example.org> Cc: "John Kitchin" <email@example.com>, "Joost Kremers" <firstname.lastname@example.org>, "Gustav Wikström" <email@example.com>, Bastien <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "Nicolas Goaziou" <email@example.com> Subject: Re: wip-cite status question and feedback Date: Fri, 29 May 2020 23:59:54 +0200 [thread overview] Message-ID: <CAOWRwxBhNOOV1LRpos3EEHcKS8VD86PtLRDs8+duBTo1D9YPtw@mail.gmail.com> (raw) In-Reply-To: <CAF-FPGO0vRWVdmUuBRyBMRcQW79s_LAabF5U_jvq5rpmWvW1kg@mail.gmail.com> Hi, apologies for reacting that late (it seems that I messed up my email filtering royally) -- it is very nice to see progress in this area. Thanks to all of you for trying to bring this forward, and, of course, to Bruce for initiating the thread. I think that the syntax that has crystallized is a good starting point for having dedicated citation support in Org, so in the following I'll concentrate on some of the infrastructure issues raised. (i) Default ("built in") citation processor in Org I think citeproc-el could be a reasonable solution for this. The core is well-tested (thanks to the CSL test suite), implements a fairly large subset of the CSL 1.01 standard, and can output citations in a number of formats including in Org syntax. If I understood correctly, this would require citeproc-el to be part of Emacs, and not even an ELPA package would suffice. In principle I'm open to this, but I'm not familiar with the process and there are potential pitfalls, e.g. citeproc-el currently depends on some "modern" libraries, e.g., "s" or "dash" which AFAIK are not in Emacs. (ii) Citation API NG == Nicolas Goaziou wrote on 8 Apr 2020 NG> 2. [ ] Decide about API Org should provide for it to be useful. Here are NG> some low hanging fruits: NG> - [ ] List all ".bib" files associated to the document, NG> - [ ] List all citations, NG> - [ ] Return citation key at point, if any. NG> - Anything else? From the citeproc-el (and CSL) perspective, the list of bibliography database files, the place where the bibliography should be placed (if it's specified) and the list of citations would be enough, I think. For the proper handling of footnote-based styles it would be important to provide footnote information about each citation: is a citation in a footnote and what is its footnote number (index in the list of footnotes)? (citeproc-org contains a function to collect this info.) NG> Moreover, we need to decide about how external processors could plug into NG> the export framework. NG> - [ ] For example, it could be a simple variable bound to a list of NG> functions. Each function accepts three arguments: the export back-end, as NG> a symbol, the full citation, as a list of triplets (key, prefix, suffix) NG> along with global prefix/suffix, and the usual INFO communication channel. NG> Does it need more? Unfortunately I'm unfamiliar with the Org exporter, so this might not be a problem at all, but there is a seemingly tricky point during export, related, again, to footnotes in footnote-based citation styles: If a footnote style is used and a citation is not already in a footnote then a footnote has to be dynamically generated around the citation during export. The simplest way of doing this is to wrap the rendered citation (which can contain backend-specific font-properties, e.g. smallcaps) into an inline Org footnote block. E.g., citeproc-org, which basically acts as an Org->Org preprocessor, generates dynamical footnote citations for html export along the lines of [fn:: @@html:<span style="font-variant:small-caps">Gödel</span> 1931@@] If this scenario can be handled by the proposed mechanism then I don't expect any other problems. NG> - [ ] Also, the prefix/suffix may contain some Org markup, so this NG> needs to be also processed. Should it happen before, or after the external NG> processor does its job? I.e., should the function translate into Org or NG> target format? This is a very good (and a bit tricky...) question! Since the proposed Org citation syntax does not contain locator-related slots, the citation processor has to locate this information in the affixes (in citeproc-org, in the suffix), parse and remove it. This part should definitely be done in Org format, so I'd say the Org markup rendering should be after the citation rendering. (With the proviso that part of the citation processor's output can already be rendered in the target format as in the previous example.) NG> 3. [ ] Specify the kind of basic translation that be done out of the box? NG> Ideally, every non-derived back-end should do something, even basic. NG> Therefore, we need to propose some translation pattern for each of the NG> following: NG> - [ ] ASCII NG> - [ ] HTML NG> - [ ] LaTeX NG> - [ ] ODT NG> - [ ] Texinfo As an Org->Org preprocessor, citeproc-org supports all these back-ends in the sense that for HTML and LaTeX it outputs target specific rendering using the @@latex and @@html syntax and generic Org for the rest. (iii) Citation visualization JK == John Kitchin wrote on 8 Apr 2020 JK> org-ref relies very heavily on the link functionality to provide actions JK> on a cite, e.g. to open the pdf, or url, allow sorting, to change the cite JK> color when it is a bad key, etc If the new syntax also has that JK> capability I'd add to this that it would be very useful if citations -- similarly to links -- had a "descriptive" (as opposed to "literal") rendering mode in the buffer as well, which would show the rendered citation, as produced by a citation processor (if available). Similarly to links one could toggle between the two display modes. (iv) Bibliography format This might go without saying but perhaps it's worth specifying which bibliography format(s) should be supported by the "out of the box" functionality. My impression is that despite the clear superiority of biblatex and CSL, BibTeX is still the most widely used format, and should be the first/main target. Later on, of course, it would be nice to support others, e.g., using a CSL processor one basically gets CSL-JSON support for free, and there could be even an Org-CSL format, by analogy with Org-BibTex. What do you think? Sorry again for replying only now & best regards, András On Sun, 24 May 2020 at 15:18, Bruce D'Arcus <firstname.lastname@example.org> wrote: > > Hi Bastian, > > > On Sun, May 24, 2020 at 8:12 AM Bastien <email@example.com> wrote: > > > > Hi Bruce, > > > > "Bruce D'Arcus" <firstname.lastname@example.org> writes: > > > > > I'm not sure of the value of this sort of question thrown in the > > > middle of a long-running, many year, conversation. You seem to assume > > > nobody considered this. > > > > Well, this sounded a bit harsh, problably more than what was intended. > > Yes, probably true. > > I was trying to be direct, to avoid a potentially long-winded diversion. > > But it was a bit harsh. Sorry Gustav. > > > > But to answer anyway ... > > > > And your answer was precisely what I was (also) looking for, so thanks > > for it. I haven't followed nor helped developments in this area but I > > hope this can settle down and be widely available. > > Indeed; thanks! > > Bruce
next prev parent reply other threads:[~2020-05-29 22:00 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-07 15:15 Bruce D'Arcus 2020-04-07 17:51 ` Nicolas Goaziou 2020-04-07 18:27 ` Bruce D'Arcus 2020-04-07 18:31 ` Bruce D'Arcus 2020-04-07 21:13 ` Joost Kremers 2020-04-08 0:01 ` Bruce D'Arcus 2020-04-08 9:16 ` Joost Kremers 2020-04-08 9:32 ` Nicolas Goaziou 2020-04-08 12:19 ` Bruce D'Arcus 2020-04-08 13:39 ` John Kitchin 2020-04-08 16:12 ` Bruce D'Arcus 2020-04-09 7:38 ` Albert Krewinkel 2020-04-09 9:30 ` Bruce D'Arcus 2020-04-09 9:46 ` Bruce D'Arcus 2020-04-09 10:05 ` Bruce D'Arcus 2020-04-09 23:17 ` Nicolas Goaziou 2020-04-10 1:17 ` Bruce D'Arcus 2020-04-10 5:38 ` Albert Krewinkel 2020-04-11 11:41 ` Bruce D'Arcus 2020-04-13 12:05 ` Gustav Wikström 2020-04-13 12:33 ` Bruce D'Arcus 2020-05-24 12:12 ` Bastien 2020-05-24 13:17 ` Bruce D'Arcus 2020-05-29 21:59 ` András Simonyi [this message] 2020-05-29 22:24 ` Bruce D'Arcus 2020-05-29 22:58 ` Bruce D'Arcus 2020-06-03 14:40 ` Bastien 2020-06-03 14:53 ` Bruce D'Arcus 2020-12-14 21:24 ` Bruce D'Arcus 2021-03-24 13:22 ` Bruce D'Arcus 2021-03-24 18:27 ` M. ‘quintus’ Gülker 2021-04-11 23:15 ` Bruce D'Arcus 2021-04-12 13:19 ` Nicolas Goaziou 2021-04-12 18:53 ` András Simonyi 2021-04-16 17:05 ` András Simonyi 2021-04-16 17:23 ` Bruce D'Arcus 2021-04-18 13:11 ` Nicolas Goaziou 2021-04-18 13:35 ` Ihor Radchenko 2021-04-18 13:37 ` Bruce D'Arcus 2021-04-21 19:57 ` John Kitchin 2021-04-21 20:09 ` Bruce D'Arcus 2021-04-21 20:57 ` John Kitchin 2021-04-21 20:26 ` John Kitchin 2021-04-21 20:54 ` Bruce D'Arcus 2021-04-22 2:47 ` Timothy 2021-04-22 12:07 ` Bruce D'Arcus 2021-04-22 12:34 ` Timothy 2021-04-21 21:47 ` András Simonyi 2021-04-21 23:51 ` Nicolas Goaziou 2021-04-22 0:01 ` Bruce D'Arcus 2021-04-22 0:15 ` Nicolas Goaziou 2021-04-23 11:49 ` Nicolas Goaziou 2021-04-23 12:55 ` András Simonyi 2021-04-23 13:10 ` Bruce D'Arcus 2021-04-23 13:24 ` Bruce D'Arcus 2021-04-23 14:50 ` András Simonyi 2021-04-23 22:08 ` Bruce D'Arcus 2021-04-24 17:37 ` M. ‘quintus’ Gülker 2021-04-24 17:47 ` Nicolas Goaziou 2021-04-24 18:39 ` Bruce D'Arcus 2021-04-26 14:54 ` Bruce D'Arcus 2021-04-26 20:35 ` Denis Maier 2021-04-27 10:12 ` Bruce D'Arcus 2021-04-27 10:20 ` Timothy 2021-04-27 11:44 ` Denis Maier 2021-04-27 12:32 ` Bruce D'Arcus 2021-04-27 13:58 ` Denis Maier 2021-04-27 14:07 ` Bruce D'Arcus 2021-04-27 14:50 ` Denis Maier 2021-04-30 13:28 ` Nicolas Goaziou 2021-04-30 21:47 ` Denis Maier 2021-05-01 11:09 ` Nicolas Goaziou 2021-05-01 13:26 ` Bruce D'Arcus 2021-05-02 21:58 ` Denis Maier 2021-05-02 22:18 ` Bruce D'Arcus 2021-05-02 23:30 ` Bruce D'Arcus 2021-05-05 13:46 ` Bruce D'Arcus 2021-05-05 18:14 ` M. ‘quintus’ Gülker 2021-05-05 18:27 ` Bruce D'Arcus 2021-05-06 17:05 ` M. ‘quintus’ Gülker 2021-05-06 8:08 ` Denis Maier 2021-04-24 13:14 ` Nicolas Goaziou 2021-04-23 12:03 ` Nicolas Goaziou 2021-04-23 13:34 ` András Simonyi 2021-04-17 19:13 ` M. ‘quintus’ Gülker 2021-04-18 16:17 ` Nicolas Goaziou 2021-04-20 13:32 ` Matt Price 2021-04-21 17:07 ` Nicolas Goaziou 2021-04-21 17:53 ` Bruce D'Arcus 2020-04-10 9:29 denis.maier.lists 2020-04-10 12:22 ` Bruce D'Arcus 2020-04-10 22:56 ` Nicolas Goaziou 2020-04-11 21:42 ` denis.maier.lists 2020-04-11 22:05 ` Bruce D'Arcus 2020-04-12 10:38 ` Nicolas Goaziou 2020-04-12 11:15 ` Bruce D'Arcus 2020-04-12 14:02 ` Nicolas Goaziou 2020-04-12 14:25 ` Bruce D'Arcus 2020-04-12 15:32 ` Nicolas Goaziou 2020-04-12 15:44 ` Bruce D'Arcus 2020-04-12 15:57 ` Nicolas Goaziou 2020-04-12 17:17 ` Bruce D'Arcus 2020-04-12 20:49 ` denis.maier.lists 2020-04-12 22:19 ` Nicolas Goaziou 2020-04-13 8:33 ` Stefan Nobis 2020-04-13 10:02 ` Denis Maier 2020-04-13 10:11 ` denis.maier.lists 2020-04-13 10:05 ` Bruce D'Arcus 2020-04-13 10:14 ` denis.maier.lists 2020-04-13 9:58 ` Bruce D'Arcus 2020-04-13 10:09 ` denis.maier.lists 2020-04-13 10:10 ` Joost Kremers 2020-04-13 10:46 ` Stefan Nobis 2020-04-15 5:54 ` Richard Lawrence 2020-04-15 10:07 ` Joost Kremers 2020-04-18 9:34 ` Richard Lawrence 2020-04-18 10:56 ` Bruce D'Arcus 2020-04-18 12:48 ` Richard Lawrence 2020-04-18 13:17 ` Bruce D'Arcus 2020-04-18 13:22 ` Bruce D'Arcus 2020-04-18 20:23 ` Denis Maier 2020-04-18 20:28 ` denis.maier.lists 2020-04-19 9:11 ` Richard Lawrence 2020-04-25 16:19 ` Nicolas Goaziou 2020-04-25 17:00 ` Bruce D'Arcus 2020-04-25 20:03 ` Nicolas Goaziou 2020-04-25 21:18 ` Bruce D'Arcus 2020-05-01 17:38 ` Richard Lawrence 2020-05-01 17:54 ` Bruce D'Arcus 2020-05-02 14:06 ` Nicolas Goaziou [not found] ` <email@example.com> 2020-05-02 16:34 ` Nicolas Goaziou 2020-05-02 17:24 ` Denis Maier 2020-05-02 13:13 ` Nicolas Goaziou 2020-05-02 13:45 ` Bruce D'Arcus 2020-05-02 20:45 ` Richard Lawrence 2020-04-29 9:14 ` Denis Maier 2020-05-02 9:51 ` Nicolas Goaziou 2020-05-02 11:53 ` Bruce D'Arcus 2020-04-18 20:38 ` Joost Kremers
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAOWRwxBhNOOV1LRpos3EEHcKS8VD86PtLRDs8+duBTo1D9YPtw@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: wip-cite status question and feedback' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).