From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: Citation syntax: a revised proposal Date: Mon, 16 Feb 2015 08:18:42 -0800 Message-ID: <87bnktrfrx.fsf@berkeley.edu> References: <87k2zjnc0e.fsf@berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNOOb-0007v0-Lr for emacs-orgmode@gnu.org; Mon, 16 Feb 2015 11:19:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNOOX-0001mb-8q for emacs-orgmode@gnu.org; Mon, 16 Feb 2015 11:19:41 -0500 Received: from plane.gmane.org ([80.91.229.3]:51643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNOOX-0001mX-2I for emacs-orgmode@gnu.org; Mon, 16 Feb 2015 11:19:37 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YNOOP-0006ui-RN for emacs-orgmode@gnu.org; Mon, 16 Feb 2015 17:19:30 +0100 Received: from c-67-169-117-151.hsd1.ca.comcast.net ([67.169.117.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Feb 2015 17:19:29 +0100 Received: from richard.lawrence by c-67-169-117-151.hsd1.ca.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Feb 2015 17:19:29 +0100 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: emacs-orgmode@gnu.org Hi John, I don't have time for a long reply but I wanted to express a couple points of agreement: John Kitchin writes: > I think the usual suspects reftex, helm-bibtex, and probably ebib > could be taught to output most of this syntax for whatever type, and > they could give human readable hints about the intended format, > e.g. intext, parenthetical, noauthor, etc... Or you could have > dedicated commands with key completion to do that. So many options, > this should not be an issue. Yes, I would hope the syntax is fairly straightforward to generate. > Presumably each &/@key will be clickable like a link, and the function > it runs would get the key (and maybe additional info about the cite)? If > not, that would be a show-stopper to me. Yes, that is certainly what I had in mind. org-element may even be able to provide support for this, so you don't have to parse the keys out yourself in Elisp (though I think maybe this would require making keys, in addition to complete citations, a category of object -- is that right, Nicolas?). > There is no question in my mind that some people will want to extend > this, as there are just too few of the latex citation commands > supported out of the box, especially for biblatex users (who used that > because of limitations in bibtex ;). Do you think there are important commands that I missed? I did try to make sure that all the major distinctions in biblatex were covered, though I ignored some more esoteric things like smartcite and volcite. > My sense is the syntax may then be too verbose, and difficult to write > exporters for and they would go back to links. That is probably a > small number of people, and maybe I am wrong about it. I am anyway > supportive enough to see it tried out. I am a bit worried about this too; but one reason I suggested an arbitrary s-expression for the %%(...) part was that it is flexible enough to let people get very creative in making simple expressions for particular needs. For example, I thought this was a cute hack for genitive citations: > @McCarthy1958 %%('s) clever use of Lisp syntax... If you use those enough, that's a lot nicer to type and read than > @McCarthy1958 %%(:type genitive) clever use of Lisp syntax... So I suggest we let a thousand flowers bloom, and see what people come up with, rather than trying to cut down on the verbosity up front. > My final comment is that I suggest two additional things to go with this > syntax: > > [bibliographystyle: some-kind-of-information-probably-unsrt/alpha/chicago] > This would tell some backend how to style the bibliography entries. This > does not need to be clickable (I don't know what a click would do > anyway, at most select the style? edit the style?). > > [bibliography: @some-kind-of-source-probably-a-file; @maybe-more-than-one] > This is where the keys are stored. And, it would also indicate where the > bibliography should actually be placed. This should also be clickable, > with a default action to just open the file that was clicked on. > > I prefer those to file attributes, e.g. > #+BIBLIOGRAPHY: @some-kind-of-source-probably-a-file; > @maybe-more-than-one > > I don't think that can be used to specify where a bibliography should be > placed, and it doesn't make sense to me to use two things to specify the > same information. Hmm, OK. Let's discuss this in another thread. > So, overall, I am on the positive side of zero. Haha, leave it to a physical scientist to turn a discrete interval into a continuous one... ;) Best, Richard