Re: [O] Citation syntax: a revised proposal

[Rasmus]

Hi,

> 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).

This is one of my concerns.  Getting [cite: pre @k post] right.  I
mentioned it in another post, but Nicolas seemed not to worry about it.

> That’s a smell in my book.

I my book it's very pleasant since it means that I can use the same
function no matter the amount of "keys" within the citation.  It's always
a list that you map on.  You don't even need a cond, though in some cases
the length of the list may be nice to have.

> 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.

With biblatex, which is the only latex backend that has sophisticated
notes functionality, this scheme makes it *super easy*!  Here's the latex
part of the hack I use for citation "in production":

;; type is e.g. textcite, and citations look like
;; [[cite: common pre; pre0 @key0 post0; pre1 @key1 post1; common post ]]
(if (org-export-derived-backend-p backend 'latex)
    (format "\\%s%s%s%s%s"
                    type (if (> (length citations) 1) "s" "")
                    common-pre common-post
                    (mapconcat
                     (lambda (cite)
                       (let ((pre  (org-string-nw-p (plist-get cite :pre)))
                             (post (org-string-nw-p (plist-get cite :post))))
                           (concat (cond
                                    ((and pre post)
                                     (format "[%s][%s]" pre post))
                                    (post (format "[%s]" post))
                                    (pre (format "[%s][]" pre))
                                    (t ""))
                                   (format "{%s}" (plist-get cite :key)))))
                             citations ""))
                   ⋯

It works well irrespective of the number of citations because a citation
is a list of keys.

> 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.

This is a technical detail that I don't know enough about to have an
opinion on.  If it would not be as you say it should be easy enough to
extract :begin and :end from daughters and figure out which one point it
on.

>> 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).

OK.  Although I don't want to make you angry, do you know
reftex-format-citation?  It's what I use for citations outside of latex.

>> 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...

I think *that* part of reftex is fairly easy to bend.  Still, Reftex has
some quirkiness.  Initially I think it's OK.

Here's John's setup:

  
https://github.com/jkitchin/org-ref/blob/master/org-ref.org#org-mode--reftex-setup

>  In the long term I’d be happy if we built something out of more easily
> composable pieces.

I agree.

>> 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).

Isn't it?  Maybe I remember wrongly.

> 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.

Magit isn't part of ELPA...  There's the new hydra thing in ELPA (haven't
tried it), which seems similar to the export dispatcher.

> What about XEmacs?  That’s another stumbling block.

I don't know.  I don't even have it installed to be honest...

–Rasmus

-- 
Summon the Mothership!