Multicite syntax

Multicite syntax

[Vaidheeswaran C]

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

----------------------------------------------------------------

Re: Multicite syntax

[Vaidheeswaran C]

[-- 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 --]

Re: Multicite syntax

[Nicolas Goaziou]

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

Re: Multicite syntax

[Vaidheeswaran C]

[-- 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 --]

Re: Multicite syntax

[Richard Lawrence]

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

Re: Multicite syntax

[Nicolas Goaziou]

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,

Re: Multicite syntax

[Richard Lawrence]

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

Re: Multicite syntax

[Nicolas Goaziou]

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

Re: Multicite syntax

[Richard Lawrence]

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