From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: Citation syntax: a revised proposal Date: Wed, 25 Feb 2015 13:59:41 +0000 Message-ID: <877fv6xfaq.fsf@gmail.com> References: <87k2zjnc0e.fsf@berkeley.edu> <87bnkvm8la.fsf@berkeley.edu> <87zj8co3se.fsf@berkeley.edu> <87ioezooi2.fsf@berkeley.edu> <87mw4bpaiu.fsf@nicolasgoaziou.fr> <8761aznpiq.fsf@berkeley.edu> <87twyjnh0r.fsf@nicolasgoaziou.fr> <87oaopx24e.fsf@berkeley.edu> <87k2zd4f3w.fsf@nicolasgoaziou.fr> <87egpkv8g9.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQcVS-0004f0-7E for emacs-orgmode@gnu.org; Wed, 25 Feb 2015 09:00:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQcVI-0004XW-U1 for emacs-orgmode@gnu.org; Wed, 25 Feb 2015 09:00:06 -0500 Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:47603) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQcVI-0004XE-Jh for emacs-orgmode@gnu.org; Wed, 25 Feb 2015 08:59:56 -0500 Received: by mail-wi0-f175.google.com with SMTP id r20so33617628wiv.2 for ; Wed, 25 Feb 2015 05:59:55 -0800 (PST) In-Reply-To: <87egpkv8g9.fsf@berkeley.edu> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Richard Lawrence , emacs-orgmode@gnu.org Hi Richard, 2015ko otsailak 20an, Richard Lawrence-ek idatzi zuen: > OK. I don't anticipate needing {:key val} myself anytime soon; I was > just trying to future-proof the syntax, and I don't want to lobby for it > if you feel strongly that this is problematic. >=20 > If there are others (John? Aaron? Samuel?) who think they really need > the {:key val} syntax *over and above* a subtype designation, please > speak up! Speaking for myself, I think the discussion so far has revealed a number of =E2=80=9Cadvanced=E2=80=9D uses of citations, such as possessive = citations, citations as footnotes, the insertion of only author/year/etc., ... At least for academic publishing, citations are pretty demanding and there isn=E2=80=99t much room for =E2=80=9Cclose enough;=E2=80=9D a paper= =E2=80=99s citations either conform to a particular style guide or they don=E2=80=99t. I think these various applications of citations, and others not yet mentioned or thought of, are best represented as binary switches. Many of these distinctions will factor well into independent implementations. For example, a citation that is :footnote t can (probably) be generated by taking the citation, whatever it is, and wrapping it in \footnote{...}. (For the latex case; other backends will have different specifics but the idea is the same.) If this is implemented in terms of subtypes, it will lead to an explosion of 2^n subtypes being necessary. Of course, not all 2^n combinations will be realized (I don=E2=80=99t think= it makes sense for a citation to be both possessive and a footnote, for example). Ultimately, it=E2=80=99s an empirical question how well different types of citation factor, and how many of the combinations make sense or are ever realized. Nicolas has given reasons why the inline attr syntax is needed independently. I think no-subtype citations + inline attr is a superset of with-subtype citations. I=E2=80=99d rather see the superset be implemen= ted. Subtypes would constrain the expressivity of citations and lead to more fragile implementations. Since we=E2=80=99re designing the syntax from scratch, I would like to avoid that. However, the most important thing is to implement something. The semipermanent beta status of master allows a period of experimentation with a citation syntax before something is made official in a release. Aaron PS A note on implementation: I envision a sort of pattern matching on key-value combinations. Something like: (((:possessive t :footnote t) (error "wtf")) ;; the generated citation command will be inserted at the %s ((:footnote t) (wrap "\footnote{%s}")) ;; slightly artificial example to illustrate pattern matching with binding ((:color _c) (wrap (format "\color{%s}{%%s}" _c))) ((:possessive t) (cite "\citeposs{%s}" ...)) ;; cite provides a list of four format strings for the ;; (non-)capitalized (non-)parenthesized ;; variants encoded in the citation type (default (cite "\cite{%s}" "\parencite{%s}" "\Cite{%s}" "\Parencite{%s}"))) Where the list of attributes is pattern-matched, and the first matching cite command is composed with all matching wrap commands. I=E2=80=99ve just shown one-place format strings for the cite key, but a full implementation would have to handle pre- and post-note. It would probably also need to handle multicites as a fifth type (or set of 4 types). Though it=E2=80=99s worth considering whether the latex \multicite family of commands provides anything above and beyond a series of sequential \cite=E2=80=99s. It might be possible to handle multicites by j= ust using elisp to concatenate individual citation commands, and not letting them vary by backend. The specifics of whether cite and wrap are sufficient primitives needs to be decided on. Probably we need to allow functions not just format strings, for the benefit of non-latex backends where the citation needs to be formatted by emacs. Then cite and wrap would just be predefined shortcuts, with the ability to drop into full elisp for more complicated cases. A small version of the 2^n problem is already visible: the 4 types of citation necessitate providing 4 strings/functions for the default case, and also for the possessive case (though I think this is unavoidable under any implementation). This is a very rough sketch, but I hope it helps stimulate thinking. There=E2=80=99s already a pattern matching library in emacs (pcase.el), tho= ugh it would need to be extended for plist pattern matching. --=20 Aaron Ecay