From: Aaron Ecay <aaronecay@gmail.com>
To: Richard Lawrence <richard.lawrence@berkeley.edu>, emacs-orgmode@gnu.org
Subject: Re: Citation syntax: a revised proposal
Date: Wed, 25 Feb 2015 13:59:41 +0000 [thread overview]
Message-ID: <877fv6xfaq.fsf@gmail.com> (raw)
In-Reply-To: <87egpkv8g9.fsf@berkeley.edu>
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.
>
> 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 “advanced” 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’t much room for “close enough;” a paper’s citations either
conform to a particular style guide or they don’t.
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’t think it
makes sense for a citation to be both possessive and a footnote, for
example). Ultimately, it’s 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’d rather see the superset be implemented.
Subtypes would constrain the expressivity of citations and lead to
more fragile implementations. Since we’re 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’ve 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’s worth considering whether the latex \multicite
family of commands provides anything above and beyond a series of
sequential \cite’s. It might be possible to handle multicites by just
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’s already a pattern matching library in emacs (pcase.el), though
it would need to be extended for plist pattern matching.
--
Aaron Ecay
next prev parent reply other threads:[~2015-02-25 14:00 UTC|newest]
Thread overview: 163+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-15 2:29 Citation syntax: a revised proposal Richard Lawrence
2015-02-15 2:45 ` Richard Lawrence
2015-02-15 3:57 ` Thomas S. Dye
2015-02-15 16:40 ` Richard Lawrence
2015-02-15 19:43 ` Thomas S. Dye
2015-02-16 3:34 ` Matt Price
2015-02-16 8:56 ` Nicolas Goaziou
2015-02-16 9:57 ` Rasmus
2015-02-17 17:18 ` Richard Lawrence
2015-02-17 18:11 ` Rasmus
2015-02-18 0:44 ` Matt Price
2015-02-18 3:38 ` Richard Lawrence
2015-02-18 2:24 ` Thomas S. Dye
2015-02-18 4:03 ` Richard Lawrence
2015-02-18 9:00 ` Stefan Nobis
2015-02-18 10:11 ` Eric S Fraga
2015-02-18 14:19 ` Nicolas Goaziou
2015-02-18 16:38 ` Richard Lawrence
2015-02-18 18:44 ` Samuel Wales
2015-02-18 18:46 ` Samuel Wales
2015-02-18 20:54 ` Aaron Ecay
2015-02-18 21:21 ` Samuel Wales
2015-02-18 21:24 ` John Kitchin
2015-02-18 19:42 ` Nicolas Goaziou
2015-02-18 20:47 ` Aaron Ecay
2015-02-18 22:43 ` Rasmus
2015-02-18 22:35 ` Rasmus
2015-02-19 17:06 ` Richard Lawrence
2015-02-20 0:10 ` Nicolas Goaziou
2015-02-20 16:44 ` Richard Lawrence
2015-02-20 19:45 ` Samuel Wales
2015-02-20 20:01 ` Rasmus
2015-02-20 22:33 ` Samuel Wales
2015-02-21 11:58 ` Rasmus
2015-02-21 17:25 ` Thomas S. Dye
2015-02-27 0:56 ` Samuel Wales
2015-02-27 8:55 ` Stefan Nobis
2015-02-27 9:56 ` Rasmus
2015-02-21 3:12 ` Richard Lawrence
2015-02-21 12:00 ` Rasmus
2015-02-21 20:19 ` Samuel Wales
2015-02-21 20:36 ` Samuel Wales
2015-02-25 13:59 ` Aaron Ecay [this message]
2015-02-25 16:57 ` Richard Lawrence
2015-02-25 22:37 ` Nicolas Goaziou
2015-02-26 5:10 ` Richard Lawrence
2015-03-01 20:35 ` Nicolas Goaziou
2015-03-01 21:31 ` Rasmus
2015-03-02 0:24 ` Thomas S. Dye
2015-03-02 8:57 ` Eric S Fraga
2015-03-02 1:37 ` Thomas S. Dye
2015-03-02 9:23 ` Rasmus
2015-03-02 19:11 ` Aaron Ecay
2015-03-02 20:15 ` Rasmus
2015-03-03 3:14 ` Richard Lawrence
2015-03-03 5:33 ` Avram Lyon
2015-03-03 17:27 ` Richard Lawrence
2015-03-03 17:56 ` Avram Lyon
2015-03-04 16:41 ` Richard Lawrence
2015-03-03 9:24 ` Rasmus
2015-03-03 9:39 ` Rasmus
2015-03-03 14:12 ` Aaron Ecay
2015-03-02 18:50 ` Richard Lawrence
2015-03-02 20:14 ` Nicolas Goaziou
2015-03-02 20:34 ` Rasmus
2015-03-02 22:17 ` Nicolas Goaziou
2015-03-02 22:33 ` Rasmus
2015-03-02 22:45 ` Nicolas Goaziou
2015-03-02 23:05 ` Rasmus
2015-03-02 23:27 ` Nicolas Goaziou
2015-03-02 23:42 ` Rasmus
2015-03-03 2:48 ` Richard Lawrence
2015-03-03 8:43 ` Nicolas Goaziou
2015-03-03 16:59 ` Richard Lawrence
2015-03-04 0:43 ` Matt Price
2015-03-08 0:16 ` Nicolas Goaziou
2015-03-03 14:23 ` Aaron Ecay
2015-03-02 18:54 ` Aaron Ecay
2015-03-02 20:26 ` Nicolas Goaziou
2015-03-03 2:53 ` Richard Lawrence
2015-03-03 8:38 ` Nicolas Goaziou
2015-03-03 9:13 ` Rasmus
2015-03-03 16:12 ` Richard Lawrence
2015-03-03 14:25 ` Aaron Ecay
2015-03-02 20:53 ` Rasmus
2015-03-03 14:57 ` Aaron Ecay
2015-03-03 15:41 ` Rasmus
2015-03-03 15:58 ` Ken Mankoff
2015-03-03 16:08 ` Rasmus
2015-03-03 17:13 ` Richard Lawrence
2015-03-10 3:44 ` Aaron Ecay
2015-03-10 9:49 ` Rasmus
2015-03-11 1:51 ` Aaron Ecay
2015-03-11 6:04 ` Thomas S. Dye
2015-03-10 16:31 ` Richard Lawrence
2015-03-11 2:21 ` Aaron Ecay
2015-03-11 17:33 ` Richard Lawrence
2015-03-13 18:13 ` Richard Lawrence
2015-03-17 5:15 ` Richard Lawrence
2015-03-17 9:27 ` Andreas Leha
2015-03-17 16:26 ` Richard Lawrence
2015-03-17 20:42 ` Andreas Leha
2015-03-17 21:34 ` Richard Lawrence
2015-03-18 1:12 ` Matt Price
2015-03-18 15:19 ` Richard Lawrence
2015-02-25 18:08 ` Thomas S. Dye
2015-02-26 21:30 ` Aaron Ecay
2015-02-26 23:50 ` Thomas S. Dye
2015-02-27 8:49 ` Stefan Nobis
2015-02-27 16:35 ` Richard Lawrence
2015-02-27 10:09 ` Rasmus
2015-03-02 5:48 ` Thomas S. Dye
2015-03-02 12:22 ` Aaron Ecay
2015-03-02 13:53 ` Thomas S. Dye
2015-03-02 19:02 ` Aaron Ecay
2015-02-20 5:27 ` Melanie Bacou
2015-02-20 16:49 ` Richard Lawrence
2015-02-24 7:08 ` Vaidheeswaran C
2015-02-25 4:29 ` Richard Lawrence
2015-02-25 5:57 ` Vaidheeswaran C
2015-02-15 11:17 ` Tory S. Anderson
2015-02-15 11:57 ` Rasmus
2015-02-15 17:05 ` Richard Lawrence
2015-02-16 8:53 ` Stefan Nobis
2015-02-16 17:52 ` Thomas S. Dye
2015-02-15 17:23 ` Nicolas Goaziou
2015-03-09 10:40 ` Sebastien Vauban
2015-03-09 10:50 ` Vaidheeswaran C
2015-02-15 17:19 ` Nicolas Goaziou
2015-02-15 17:37 ` Rasmus
2015-02-15 17:55 ` Nicolas Goaziou
2015-02-15 19:30 ` John Kitchin
2015-02-15 18:07 ` Richard Lawrence
2015-02-15 18:25 ` Nicolas Goaziou
2015-02-15 19:05 ` Aaron Ecay
2015-02-15 19:18 ` Nicolas Goaziou
2015-02-15 19:38 ` Aaron Ecay
2015-02-15 20:13 ` Nicolas Goaziou
2015-02-15 20:23 ` Rasmus
2015-02-16 9:07 ` Stefan Nobis
2015-02-16 16:59 ` Richard Lawrence
2015-02-16 17:43 ` Nicolas Goaziou
2015-02-16 18:39 ` Rasmus
2015-02-16 19:16 ` Thomas S. Dye
2015-02-16 19:40 ` Rasmus
2015-02-15 20:49 ` John Kitchin
2015-02-16 16:18 ` Richard Lawrence
2015-02-16 18:21 ` John Kitchin
2015-02-16 12:05 ` Eric S Fraga
2015-02-16 13:10 ` William Denton
2015-02-16 13:42 ` John Kitchin
2015-02-16 16:19 ` Nicolas Goaziou
2015-02-16 17:28 ` John Kitchin
2015-02-16 18:49 ` Rasmus
2015-02-16 19:16 ` John Kitchin
2015-02-23 7:26 ` Vaidheeswaran
2015-02-16 16:35 ` Jorge A. Alfaro-Murillo
2015-02-16 17:56 ` Stefan Nobis
2015-02-16 18:24 ` John Kitchin
2015-02-16 18:39 ` Jorge A. Alfaro-Murillo
2015-02-16 19:19 ` Jorge A. Alfaro-Murillo
2015-02-17 6:47 ` Stefan Nobis
2015-02-16 16:45 ` Richard Lawrence
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=877fv6xfaq.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=richard.lawrence@berkeley.edu \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).