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!
