From: Nicolas Goaziou <firstname.lastname@example.org> To: "András Simonyi" <email@example.com> Cc: "firstname.lastname@example.org" <email@example.com>, Bruce D'Arcus <firstname.lastname@example.org> Subject: Re: wip-cite status question and feedback Date: Sun, 18 Apr 2021 15:11:07 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <CAOWRwxCb7o=LWVFx=iOuc+Wt4=UmhY_4=aX_okxjikH=_TQEyw@mail.gmail.com> (=?utf-8?Q?=22Andr=C3=A1s?= Simonyi"'s message of "Fri, 16 Apr 2021 19:05:47 +0200") Hello, András Simonyi <firstname.lastname@example.org> writes: > are short-form citations like @doe2018 or [@doe2018] also supported? No, I removed them in last year's iteration, because they are prone to false positives. I didn't want to repeat the footnote syntax mistake, when "" was equivalent to "[fn:1]". I am also leaning towards removing the possibility to include Org syntax (e.g., bold) in prefixes/suffixes. Indeed, this doesn't sound terribly useful (you can move the bold part outside of the citation object), and yet, adds a layer of complexity on top of the citation object. Can we assume (global)prefix/suffix are just plain text? >> Now about the API, which is partly implemented on a local branch. > >> - "opening" action is straightforward. All is needed for the processor >> is to provide a function accepting two arguments: the citation key, >> as a string, and possibly a universal argument, which it may ignore, >> or not. >> >> All this is already implemented locally. > > I can imagine situations in which the location (e.g. page range) of > the citation is also important, e.g., when the > processor opens the cited document, so it'd be nice to pass this > information (when available) as well. In my mind, "opening" leads to the bibliography reference, not to the original document. IIUC, in this situation, the location does not matter much, does it? In any case, Org has no clue about the "location" of the citation. It can provide the suffix associated to the citation key, but it is up to the citation processor to extract page information out of it. If this is desirable, we need to provide the full citation object instead of the key. I don't know if it is worth the trouble. >> First, export happens as pre-process, before export back-ends are >> introduced. IOW, export back-ends are never going to see a citation >> object, which means no support whatsoever is needed on their end. > > This is pretty close to how citeproc-org operates right now. I had a quick glance at citeproc-org for inspiration. I agree this is a sane way to proceed. >> Support export requires two functions. The first function is >> responsible for rendering a bibliography. Its arguments are the list >> of citations in the document, the list of bibliography files, the >> style, if any, and the export back-end. It should return a string. > > Am I correct in assuming that the returned bibliography should be > rendered as a legitimate Org fragment regardless of the back-end? I think it should be rendered as target format, to be on par with citation handling. You may, however, use Org format as an intermediate step, and then, call `org-export-data-with-backend' (from "ox.el") on it. If this is desirable, I need to also provide a fifth `info' argument to the list above. >> The second mandatory function is obviously responsible for rendering >> citations. It is called with a citation object, the desired style, >> if any, and the export back-end, the full list of citations objets >> in the document, and the list of bibliography files. It should also >> return a string. Org provides a helper function to determine the >> footnote containing a citation (and its label, or number) from >> a citation object. > > This might not be an important point, but citeproc-el is rather > citation list oriented in the sense that it processes the list of all > citations and returns a list of their formatted counterparts, so it > might be useful to provide this "bulk" API as well, at least as an > optional addition. I don't think any addition to the suggested API is required. If you cannot split citation processing, you may fill a temporary cache holding all exports on first citation (the full list of citations objects is provided right from the start), then read from that cache on subsequent citations. WDYT? > What is very important and was rather tricky to implement as I recall > is that the list of citations should be in the order they actually > appear in the exported document even for citations in footnotes, > because certain styles format citations differently if another > reference to the same work occurred in a nearby, earlier note. Noted. IIRC, `org-export--footnote-reference-map' deals with a similar issue, i.e., how to apply a function on footnote references _in order_. Situation in nested footnotes can be ambiguous, tho. In the following example, is the expected order @a then @b then @c? --8<---------------cut here---------------start------------->8--- Text[fn:1] [@cite:@c] [fn:1] This[fn:2] is [cite:@b]. [fn:2] [cite:@a] --8<---------------cut here---------------end--------------->8--- > In addition to the precise order of the citations and whether they are > in a footnote or not, the concrete identity of the notes is also > important, because formatting can differ depending on whether two > citations are in the same note or in different ones. I don't understand what you call the "identity of the notes". Could you provide an example? >> - "fontification" is meant to give full access to face selection, what >> is really displayed, additional keymaps, all using a single >> function. > >> At the moment, I have no idea about what arguments would be useful. >> I think John Kitchin gave ideas about this already on this ML. >> I have to re-read his posts on the subject. In any case, feedback >> welcome. > > I'm thinking about implementing a "fontification" solution which would > use citeproc-el with a standard style to produce nice preview-like > representations of the citations in the buffer. This would require > basically the same pieces of information as citation export I think, > although it might be made strictly local, working only with the > single citation object plus the bibliography information. OK. Citation object and list of bibliography files as arguments are a starting point. >> A citation processor does not need to provide integration in all these >> areas. Users may be able to mix and match processors. This is another >> (minor) point which is yet to be designed. How is a user supposed to >> select a processor for each integration area? It could be done through >> three variables, e.g., >> >> (setq org-cite-display-processor 'org-ref) >> (setq org-cite-export-processor 'citeproc) >> (setq org-cite-follow-processor 'default) >> >> I think it is unlikely for a user to locally select "display" and >> "follow" processors. However, we need a way to use a local export >> processor for a given document. I may need to introduce >> a #+citation_processor keyword during export. Any other idea? > > All of these solutions seem to be good starting points. As for > setting the "display" and "follow" processors locally, this leads to a > question which probably has to be addressed at a certain point: that > of bibliography formats. The Emacs world is currently rather BibTeX > centered, but biblatex is an important (and rather different) > alternative, and there is CSL as well which I expect to become more > and more relevant (it's citeproc-el's native format). Moreover, these > formats have some variants, e.g., for BibTeX there is also org-bibtex, > for CSL there is CSL-JSON and a CSL-YAML etc. If different "display" > and "follow" processors will be able to handle different formats then > the users might want to change those settings locally as well, based > on the bibliography format, but I'm not sure what kind of > infrastructure would be the best way of supporting this. (E.g., > registering format support information about the processors and > choosing on this basis?) I don't have an idea about it either. This is not a blocker, tho. We can revisit it later, once we have "something" working. Thanks for your feedback. Regards, -- Nicolas Goaziou
next prev parent reply other threads:[~2021-04-18 13:12 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 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 [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).