emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Citation syntax: a revised proposal


From: Richard Lawrence
Subject: Re: [O] Citation syntax: a revised proposal
Date: Mon, 16 Feb 2015 08:18:42 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Hi John,

I don't have time for a long reply but I wanted to express a couple
points of agreement:

John Kitchin <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]