> Note that, as a consequence, the new object is incompatible with the > previous one, since every citation is a multi-cite citation. See > commit message for details. Just a quick feedback. (:parenthetical nil :begin 807 :post-blank 0 :end 843 :references ((:key "wilde" :prefix nil :suffix nil) (:key "moore" :prefix nil :suffix nil) (:key "westfahl:space" :prefix nil :suffix nil)) :parent #3#) Having a plist for `reference' as opposed to a an Element proper gives me cognitive dissonance. How about replacing this (:key "wilde" :prefix nil :suffix nil) with this instead (reference :key "wilde" :prefix nil :suffix nil :parent ) ^^^^^^^^ ^^^^^^ Each `reference' is transcoded to it's contents in it's own right in ox-jabref. (a) Batch export all cites. In case of citeproc-java it would be batch export each multicite. http://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00262.html) (b) Map `reference' to `contents' with transcoding being done by the citation command line. Please confirm whether this change request is possible or not. ---------------------------------------------------------------- You may also want to replace `citaiton' with a `citation-cluster'(or a multicite) and replace `reference' with a `citation'. In effect, a citation-cluster (or a multicite) is one or more citaitons. ----------------------------------------------------------------
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --] I have fixed up ox-jabref.el to support multicites. Only common prefixes and suffixes are handled. I don't know how to handle per-key prefix/suffix-es. If someone has any complaints about the output, please write to me. Attaching files that I have used for testing. (Author-Date file lacks year because of a bug in Chicago filters bundled with JabRef. JabRef style file uses 'year' field but biblatex-examples.bib provides only a 'date' field.) On Sunday 08 March 2015 11:59 AM, Vaidheeswaran C wrote: > >> Note that, as a consequence, the new object is incompatible with the >> previous one, since every citation is a multi-cite citation. See >> commit message for details. > > Just a quick feedback. > > (:parenthetical nil :begin 807 :post-blank 0 :end 843 :references > ((:key "wilde" :prefix nil :suffix nil) > (:key "moore" :prefix nil :suffix nil) > (:key "westfahl:space" :prefix nil :suffix nil)) > :parent #3#) > > Having a plist for `reference' as opposed to a an Element proper gives > me cognitive dissonance. > > How about replacing this > > (:key "wilde" :prefix nil :suffix nil) > > with this instead > > (reference :key "wilde" :prefix nil :suffix nil :parent ) > ^^^^^^^^ ^^^^^^ > > Each `reference' is transcoded to it's contents in it's own right in > ox-jabref. > > (a) Batch export all cites. > > In case of citeproc-java it would be batch export each multicite. > http://lists.gnu.org/archive/html/emacs-orgmode/2015-03/msg00262.html) > > (b) Map `reference' to `contents' with transcoding being done by the > citation command line. > > Please confirm whether this change request is possible or not. > > ---------------------------------------------------------------- > > You may also want to replace `citaiton' with a `citation-cluster'(or a > multicite) and replace `reference' with a `citation'. > > In effect, a citation-cluster (or a multicite) is one or more > citaitons. > > ---------------------------------------------------------------- > > > [-- Attachment #2: cite-chicago-fullnote.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11118 bytes --] [-- Attachment #3: cite-numeric.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11054 bytes --] [-- Attachment #4: cite.org --] [-- Type: application/vnd.lotus-organizer, Size: 1204 bytes --] [-- Attachment #5: cite-chicago-author-date.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11009 bytes --]
Vaidheeswaran C <vaidheeswaran.chinnaraju@gmail.com> writes:
>> Note that, as a consequence, the new object is incompatible with the
>> previous one, since every citation is a multi-cite citation. See
>> commit message for details.
>
> Just a quick feedback.
>
> (:parenthetical nil :begin 807 :post-blank 0 :end 843 :references
> ((:key "wilde" :prefix nil :suffix nil)
> (:key "moore" :prefix nil :suffix nil)
> (:key "westfahl:space" :prefix nil :suffix nil))
> :parent #3#)
>
> Having a plist for `reference' as opposed to a an Element proper gives
> me cognitive dissonance.
>
> How about replacing this
>
> (:key "wilde" :prefix nil :suffix nil)
>
> with this instead
>
> (reference :key "wilde" :prefix nil :suffix nil :parent )
> ^^^^^^^^ ^^^^^^
Agreed. I introduced yet another syntax change in "wip-cite" branch.
Now there are two separate objects "citation" and "citation-reference".
So the following multicite
[cite:prefix; pre @a post; @b]
is parsed like
(citation (:prefix "prefix" :parenthetical nil)
(citation-reference (:key "a" :prefix "pre" :suffix "post"))
(citation-reference (:key "b")))
The annoying thing is about bare-keys. When on a bare @key,
`org-element-context' cannot grap the citation, only the reference.
I don't think it is an issue for now.
Regards,
--
Nicolas Goaziou
[-- Attachment #1: Type: text/plain, Size: 638 bytes --] On Sunday 08 March 2015 09:58 PM, Nicolas Goaziou wrote: > Agreed. I introduced yet another syntax change in "wip-cite" branch. > > Now there are two separate objects "citation" and "citation-reference". > So the following multicite > > [cite:prefix; pre @a post; @b] > > is parsed like > > (citation (:prefix "prefix" :parenthetical nil) > (citation-reference (:key "a" :prefix "pre" :suffix "post")) > (citation-reference (:key "b"))) I have pushed the corresponding changes to http://repo.or.cz/w/org-mode/org-cv.git. The pull URL is git://repo.or.cz/org-mode/org-cv.git. I am attaching sample files for inspection. [-- Attachment #2: cite-chicago-author-date.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11307 bytes --] [-- Attachment #3: cite-chicago-full-note.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11434 bytes --] [-- Attachment #4: cite.org --] [-- Type: application/vnd.lotus-organizer, Size: 1302 bytes --] [-- Attachment #5: cite-numeric.odt --] [-- Type: application/vnd.oasis.opendocument.text, Size: 11344 bytes --]
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> Agreed. I introduced yet another syntax change in "wip-cite" branch.
>
> Now there are two separate objects "citation" and "citation-reference".
> So the following multicite
>
> [cite:prefix; pre @a post; @b]
>
> is parsed like
>
> (citation (:prefix "prefix" :parenthetical nil)
> (citation-reference (:key "a" :prefix "pre" :suffix "post"))
> (citation-reference (:key "b")))
With this change, what's the proper way to get the citation-references
inside a citation? Before this change, one could simply do:
(org-element-property :references citation)
to get the references in a citation; what's the equivalent incantation
now?
Your example here makes it look like I should be able to do something
like:
#+BEGIN_SRC elisp
(let* ((citation (org-element-context))
(references
(remove-if-not
(lambda (o) (and (listp o) (eq (car o) 'citation-reference)))
citation)))
; ...
)
#+END_SRC
But, AFAICT, citation objects do not actually have citation-reference
objects within them, at least when returned by org-element-context.
I'm sure there is something simple I am misunderstanding here about how
nested objects work...can you enlighten me?
Thanks!
Best,
Richard
Richard Lawrence <richard.lawrence@berkeley.edu> writes: > With this change, what's the proper way to get the citation-references > inside a citation? Before this change, one could simply do: > > (org-element-property :references citation) > > to get the references in a citation; what's the equivalent incantation > now? [...] > But, AFAICT, citation objects do not actually have citation-reference > objects within them, at least when returned by org-element-context. `org-element-context' never returns contents of objects or elements. > I'm sure there is something simple I am misunderstanding here about how > nested objects work...can you enlighten me? You could do the following (let ((citation (org-element-lineage (org-element-context) '(citation) t)) references) (save-excursion (goto-char (org-element-property :contents-begin citation)) (let ((end (org-element-property :contents-end citation))) (while (< (point) end) (let ((reference (org-element-lineage (org-element-context) '(citation-reference) t)))) (push reference references) (goto-char (org-element-property :end reference))))) (nreverse references)) Regards,
Hi Nicolas,
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
> `org-element-context' never returns contents of objects or elements.
>
>> I'm sure there is something simple I am misunderstanding here about how
>> nested objects work...can you enlighten me?
>
> You could do the following
>
> (let ((citation (org-element-lineage (org-element-context) '(citation) t))
> references)
> (save-excursion
> (goto-char (org-element-property :contents-begin citation))
> (let ((end (org-element-property :contents-end citation)))
> (while (< (point) end)
> (let ((reference (org-element-lineage
> (org-element-context) '(citation-reference) t))))
> (push reference references)
> (goto-char (org-element-property :end reference)))))
> (nreverse references))
Thanks!
Just to clarify: I see that this is necessary when getting a citation
object via org-element-context, but is it also necessary in an export
context, where the whole buffer or region has already been parsed?
I ask because in that kind of context, I think it is generally going to
be more useful to deal with citation objects as a whole. I am not sure
we will want to treat citation-references as individual objects which
are themselves exported; instead, I think we will want to handle
exporting the citation-references in a citation all at once.
Best,
Richard
Hello, Richard Lawrence <richard.lawrence@berkeley.edu> writes: > Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: >> You could do the following >> >> (let ((citation (org-element-lineage (org-element-context) '(citation) t)) >> references) >> (save-excursion >> (goto-char (org-element-property :contents-begin citation)) >> (let ((end (org-element-property :contents-end citation))) >> (while (< (point) end) >> (let ((reference (org-element-lineage >> (org-element-context) '(citation-reference) t)))) >> (push reference references) >> (goto-char (org-element-property :end reference))))) >> (nreverse references)) > > Thanks! For correctness, (push ...) and (goto-char ...) obviously need to be located within the (let ...). > Just to clarify: I see that this is necessary when getting a citation > object via org-element-context, but is it also necessary in an export > context, where the whole buffer or region has already been parsed? No, with a full parse tree, `org-element-contents' on a citation object returns the list of all citation-reference objects within. > I ask because in that kind of context, I think it is generally going to > be more useful to deal with citation objects as a whole. I am not sure > we will want to treat citation-references as individual objects which > are themselves exported; instead, I think we will want to handle > exporting the citation-references in a citation all at once. I don't know. In any case, they need to be treated as regular object (e.g., they are expected to have a filter associated to them). If some back-end doesn't need to export directly citation references, it just needs to skip the relative translator. Regards, -- Nicolas Goaziou
Nicolas Goaziou <mail@nicolasgoaziou.fr> writes: >> I ask because in that kind of context, I think it is generally going to >> be more useful to deal with citation objects as a whole. I am not sure >> we will want to treat citation-references as individual objects which >> are themselves exported; instead, I think we will want to handle >> exporting the citation-references in a citation all at once. > > I don't know. In any case, they need to be treated as regular object > (e.g., they are expected to have a filter associated to them). Hmm. I can see that making sense if the filter manipulates the citation-reference object itself, but I can't see it making sense if the idea is that the exporter transcodes citation-references individually, and the filter manipulates the transcoded string. For example, suppose LaTeX export works by mapping a citation object to a biblatex command, and consider this citation: [cite: See @Doe99 ch. 1; @Doe2000 p. 10] This should be transcoded in the final output to something like: \textcite[See][ch. 1]{Doe99}[][p. 10]{Doe2000} in which case the transcoded string corresponding to the first citation-reference object is "[See][ch. 1]{Doe99}". It's hard for me to see how you could do anything useful with just this string, and it might even be dangerous to manipulate it, since it is only part of a complete command, which you might mess up by modifying the string. In other backends, there might not even be a syntactically-identifiable chunk of the output citation which corresponds to a given citation-reference. (I'm having trouble thinking of a good example at the moment, but I'm thinking of cases where e.g. CSL processing turns a reference into "Ibid.", or some other output that only has meaning relative to its place in the document and doesn't correspond in a context-free way to the citation-reference object.) But like I said, it makes more sense if the filter can manipulate the citation-reference object itself, e.g. by setting additional properties or modifying the prefix and suffix strings *before* the object is transcoded as part of a citation. > If some back-end doesn't need to export directly citation references, it > just needs to skip the relative translator. Sure. I guess I'm just having a hard time seeing why a backend would ever need/want to translate citation-references individually, rather than generating a complete citation all at once. That seems to be the way to do it in both the LaTeX and CSL worlds, anyway. Best, Richard