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: Tue, 03 Mar 2015 14:57:37 +0000
User-agent: Notmuch/0.19+52~g1722ea2 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu)

Hi Rasmus,

2015ko martxoak 2an, Rasmus-ek idatzi zuen:
> 
> Looks cool Aaron.  Thanks!
> 
> Aaron Ecay <address@hidden> writes:
> 
>> The first issue is that the parser includes trailing punctuation in
>> “bare” @key citations.  So the following does not work as expected (the
>> :key includes the period): “This was demonstrated most recently by
>> @Smith2015.”  I’m not sure what the right approach is – one option
>> would be to say that keys can contain punctuation, but must end (and
>> begin) with an alphanumeric character.
> 
> I also tried to solve this in the attached patch.  Feel free to use it in
> the unlikely case that it adds anything to your fix (I didn't check).
> Note, cf. my other recent post, this should probably be part of a
> citations object rather than a citation object (assuming you take my idea
> at good value).

It looks like the patch you sent also adds support for subtypes.  Rather
than try to distill the essential bit from it, I’ll wait for you and/or
Nicolas to get to it (there’s no particular hurry...)

I’m not sure I’m happy about the citations/citation proposal (under any
assignment of different names to the pieces).  A citations containing
only one citation is degenerate: it can never have a :prefix or :suffix
(these will rather be attached to the lone daughter citation).  That’s a
smell in my book.

It also makes the latex export more complicated: a one-daughter
citations should export as \textcite etc., whereas a multi-daughter one
will be \multicite.  From my perspective it would be more
straightforward to only have the citations wrapper be generated if there
are actually multiple citations.  But I don’t know how that would affect
the parser, so you should do what seems best to you.

Another tangentially related issue is what does (org-element-context)
return when point is in a multi-citation.  It would be nice if it
returned the citation daughter, rather than the wrapping citations
element.  This would make implementing goto-citation-at-point very
easy.

>> -> How much of the non-latex citation code is it worth implementing in
>> elisp.
> 
> As little as possible, though a highlevel API is nice, e.g. being able to
> make a citepos using (concat (citeauthor cite) "'s" (citeyear cite)).

I think I have an idea for this (though based on string templates rather
than list forms).

> I haven't tried org-ref, but isn't it just reftex?  

I haven’t either, but my impression is that, while perhaps based on
reftex, there’s a lot of spit and polish that goes into making it work
nicely.  It would be nice to be able to “steal” that because...

> If so something like this
> 
> (add-to-list 'reftex-cite-format-builtin
>                '(org "Org-mode citation"
>                      ((?t . "[cite:%l]")
>                       (?p . "[parencite:%l]"))))
> 
> Should work.  We'd automatically add subtypes and maybe make an
> intelligent choice based on whether prefix and postfix is used.  

Every time I’ve looked at the reftex internals I get grumpy, because
they are heavily tuned towards latex usecases, and involve some weird
cache structure which manipulates the plist of an interned symbol.  So
customizing it for org always seems precarious.  In the long term I’d be
happy if we built something out of more easily composable pieces.

> Another idea would be to use the ox-export dispatcher code, somehow...

If this was a composable piece I’d be happy (I haven’t looked at it).
There was also an attempt to factor the menu code out of magit (called
makey IIRC).  I’ve used it for some small things, but it wasn’t terribly
pleasant.

> 
>> PS the code uses relatively new functions from the subr-x and let-alist
>> libraries, so it probably works best on a recent-ish (past few months)
>> trunk version of emacs.
> 
> In another post, Nicolas said we can target (at least?) 24.4 for v8.4.
> I'm assuming citation won't make 8.3...

What about XEmacs?  That’s another stumbling block.

Thanks,

-- 
Aaron Ecay



reply via email to

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