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: Aaron Ecay
Subject: Re: [O] Citation syntax: a revised proposal
Date: Mon, 02 Mar 2015 12:22:05 +0000
User-agent: Notmuch/0.19+52~g1722ea2 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu)

Hi Tom,

2015ko martxoak 2an, "Thomas S. Dye"-ek idatzi zuen:
> 
> Aloha Aaron,
> 
> Aaron Ecay <address@hidden> writes:
> 
>> By way of illustration, Biblatex (AFAICT) doesn’t provide a possessive
>> citation command, which was mentioned by someone in this thread (or its
>> predecessor) as a desideratum.  I’d expect a savvy latex user to put in
>> their preamble:
>> 
>> \newcommand{\citeposs}[1]{\citeauthor{#1}’s (\citeyear{#1})}
>> 
>> That doesn’t really work in org.  (It could be put together with an org
>> macro, but would lose the kind of click-to-view functionality that
>> org-ref already provides and which would be ported to the new syntax as
>> well.)
> 
> #+name: define-citeposs-link
> #+begin_src emacs-lisp :results silent :exports none
>     (org-add-link-type 
>      "citeposs" 'ebib-open-org-link
>      (lambda (path desc format)
>        (cond
>         ((eq format 'html)
>          (format "(<cite>%s</cite>)" path))
>         ((eq format 'latex)
>          (format "\\citeauthor{%s}'s (\\citeyear{%s})" path path)))))
> #+end_src
> 
> I haven't tested this, but I think it would work in Org mode.

The main thrust of this thread, and the previous one, has been to
define a citation syntax in org.  I don’t think anyone contests that
link-based solutions basically do the trick for Latex (only).  And
yet, (almost?) everyone has agreed that something more is needed, or
at least inevitable.  So I’m puzzled why you brought this up.

Are you trying to argue for subtype-based citations?  This is what I
infer from your messages (not just this one, and please do correct me if
I’m wrong).  If so, it would make it easier for me to understand you if
you said so outright.  My own opinion is that plists are better than
subtypes, but I’ve also said that I don’t think the correct decision can
be made a priori.  So don’t let me stop you (in general, not just Tom)
from going ahead with an implementation of subtypes, if that’s your
preferred solution.  I would like to help out with coding or testing,
though I haven’t yet been able to figure out where my efforts would be
best applied.  So if there’s something you (again, in general) think
would be helpful, don’t hesitate to ask.

Thanks,

-- 
Aaron Ecay



reply via email to

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