org-exp-bibtex missing in git?

org-exp-bibtex missing in git?

[Vikas Rawal]

org-exp-bibtex seems to have gone missing from git repository. Can
somebody confirm pleae.

Vikas

Re: org-exp-bibtex missing in git?

[François Allisson]

Le dimanche  3 mars 2013 à 08h06, Vikas Rawal a écrit:
> org-exp-bibtex seems to have gone missing from git repository. Can
> somebody confirm pleae.
>
> Vikas

Dear Vikas,

I do confirm.

org-exp-bibtex, because of its dependency on the old exporter, was first
moved from contrib/lisp to contrib/oldexp during the process of
migration towards org new exporter. And yesterday, the directory
contrib/oldexp was eventually removed[1].

It is still possible to checkout before this commit to rescue it, and
try to update it for the new exporter (which I would do, if I was
technically able to do so). In the meanwhile, checking, building, and
exporting with the old exporter is still a possible option.

Best,
François

[1] http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=ee3b3eb421e74339119d730a5bf896a070b2ed60

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Vikas,

François Allisson <francois@allisson.co> writes:

> org-exp-bibtex, because of its dependency on the old exporter, was first
> moved from contrib/lisp to contrib/oldexp during the process of
> migration towards org new exporter. And yesterday, the directory
> contrib/oldexp was eventually removed[1].

Yes.  What features of org-exp-bibtex.el would you need that you don't
have with the current version of Org (from the master branch)?  It will 
help knowing what to implement.

Thanks in advance,

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Nicolas Goaziou]

Bastien <bzg@altern.org> writes:

> Hi Vikas,
>
> François Allisson <francois@allisson.co> writes:
>
>> org-exp-bibtex, because of its dependency on the old exporter, was first
>> moved from contrib/lisp to contrib/oldexp during the process of
>> migration towards org new exporter. And yesterday, the directory
>> contrib/oldexp was eventually removed[1].
>
> Yes.  What features of org-exp-bibtex.el would you need that you don't
> have with the current version of Org (from the master branch)?  It will 
> help knowing what to implement.

It would be good to integrate citations in export framework, so we do
not rely on an external tool and \cite{...} constructs.

We already got rid of \ref{...}.

Maybe something like [cite:....]. org-element could parse this, and
ox.el provide some tools to access data. Then each back-end could deal
with them.

But it requires first to think about proper specifications.


Regards,

-- 
Nicolas Goaziou

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> Hi Vikas,
>>
>> François Allisson <francois@allisson.co> writes:
>>
>>> org-exp-bibtex, because of its dependency on the old exporter, was first
>>> moved from contrib/lisp to contrib/oldexp during the process of
>>> migration towards org new exporter. And yesterday, the directory
>>> contrib/oldexp was eventually removed[1].
>>
>> Yes.  What features of org-exp-bibtex.el would you need that you don't
>> have with the current version of Org (from the master branch)?  It will 
>> help knowing what to implement.
>
> It would be good to integrate citations in export framework, so we do
> not rely on an external tool and \cite{...} constructs.
>
> We already got rid of \ref{...}.
>
> Maybe something like [cite:....]. org-element could parse this, and
> ox.el provide some tools to access data. Then each back-end could deal
> with them.
>

This would be truly *awesome*.  This is the major barrier blocking truly
cross-backend export.

The data would be still from bibtex files?


Regards,
Andreas

Re: org-exp-bibtex missing in git?

[Nicolas Goaziou]

Hello,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Bastien <bzg@altern.org> writes:
>>
>>> Hi Vikas,
>>>
>>> François Allisson <francois@allisson.co> writes:
>>>
>>>> org-exp-bibtex, because of its dependency on the old exporter, was first
>>>> moved from contrib/lisp to contrib/oldexp during the process of
>>>> migration towards org new exporter. And yesterday, the directory
>>>> contrib/oldexp was eventually removed[1].
>>>
>>> Yes.  What features of org-exp-bibtex.el would you need that you don't
>>> have with the current version of Org (from the master branch)?  It will 
>>> help knowing what to implement.
>>
>> It would be good to integrate citations in export framework, so we do
>> not rely on an external tool and \cite{...} constructs.
>>
>> We already got rid of \ref{...}.
>>
>> Maybe something like [cite:....]. org-element could parse this, and
>> ox.el provide some tools to access data. Then each back-end could deal
>> with them.
>>
>
> This would be truly *awesome*.  This is the major barrier blocking truly
> cross-backend export.
>
> The data would be still from bibtex files?

No idea.

That's why specifications must be discussed first. What [cite:...]
entries (if we agree on that syntax) should provide?


Regards,

-- 
Nicolas Goaziou

Re: org-exp-bibtex missing in git?

[Eric S Fraga]

I have the following defined in my org customisation:

#+begin_src org
(org-add-link-type "cite" 'ebib
                   (lambda (path desc format)
                     (cond
                      ((eq format 'latex)
                       (format "\\cite{%s}" path)))))
#+end_src

which allows me to insert links like

  [[cite:jones-etal-2000][Jones et al., 2000]]

and have the correct code exported for Latex.  I have not, obviously,
defined any export rules for HTML etc.

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>> Bastien <bzg@altern.org> writes:
>>>
>>>> Hi Vikas,
>>>>
>>>> François Allisson <francois@allisson.co> writes:
>>>>
>>>>> org-exp-bibtex, because of its dependency on the old exporter, was first
>>>>> moved from contrib/lisp to contrib/oldexp during the process of
>>>>> migration towards org new exporter. And yesterday, the directory
>>>>> contrib/oldexp was eventually removed[1].
>>>>
>>>> Yes.  What features of org-exp-bibtex.el would you need that you don't
>>>> have with the current version of Org (from the master branch)?  It will 
>>>> help knowing what to implement.
>>>
>>> It would be good to integrate citations in export framework, so we do
>>> not rely on an external tool and \cite{...} constructs.
>>>
>>> We already got rid of \ref{...}.
>>>
>>> Maybe something like [cite:....]. org-element could parse this, and
>>> ox.el provide some tools to access data. Then each back-end could deal
>>> with them.
>>>
>>
>> This would be truly *awesome*.  This is the major barrier blocking truly
>> cross-backend export.
>>
>> The data would be still from bibtex files?
>
> No idea.
>
> That's why specifications must be discussed first. What [cite:...]
> entries (if we agree on that syntax) should provide?
>
>
> Regards,

Some thoughts on this.

For me, citations are more than links but also include information on
formatting (\citep) and on what to use in the citation (\citeauthor).

I am not sure on how far an org-mode implementation of citations should
go, but from a LaTeX-targeted view, they could support
1. different citation commands (\cite, \citep, ..., \footfullcite)
2. pre- and postnotes
so that it'd be possible to have something like this generated in LaTeX
export:
\footfullcite[prenote][postnote]{key}

Eric suggested/uses this format (thanks for sharing, Eric):
  [[cite:jones-etal-2000][Jones et al., 2000]]
         ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
             key           displayed in org

So, a possible extension of that could, for instance,
use a third pair of [] as in
  [[cite:jones-etal-2000][Jones et al., 2000][[citationcommand][prenote][postnote]]]
         ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
             key           displayed in org


If org only supports \cite (or only \cite and \citep), for serious
writing I'll still have to use LaTeX commands.

On the other hand, since I don't (yet?) see a chance to support any of
that for a different backend than LaTeX it might be overengineered to
support these at org-modes side?


Regards,
Andreas

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Andreas and all,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Eric suggested/uses this format (thanks for sharing, Eric):
>   [[cite:jones-etal-2000][Jones et al., 2000]]
>          ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
>              key           displayed in org

I'd suggest to treat org-link-abbrev-alist and locally defined
abbreviated links differently when opening the link at point and
when exporting the buffer.

At expand time, the exporter could attach a list of export functions
(filters?) to the expanded link, depending on the local setting for
the abbreviated link or `org-link-abbrev-alist'.  For example:

 #+LINK: cite file:my.bib::%s org-latex-bibtex-link
 
 (setq org-link-abbrev-alist
   '(("cite" "file:my.bib::%s" 'org-latex-bibtex-link)))
 
Then org-latex-bibtex-link would internally find the link, process
the BibTeX entry and return a sensible \cite{...} string.

What do you think?

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

> Hi Andreas and all,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> Eric suggested/uses this format (thanks for sharing, Eric):
>>   [[cite:jones-etal-2000][Jones et al., 2000]]
>>          ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
>>              key           displayed in org
>
> I'd suggest to treat org-link-abbrev-alist and locally defined
> abbreviated links differently when opening the link at point and
> when exporting the buffer.
>
> At expand time, the exporter could attach a list of export functions
> (filters?) to the expanded link, depending on the local setting for
> the abbreviated link or `org-link-abbrev-alist'.  For example:
>
>  #+LINK: cite file:my.bib::%s org-latex-bibtex-link
>  
>  (setq org-link-abbrev-alist
>    '(("cite" "file:my.bib::%s" 'org-latex-bibtex-link)))
>  
> Then org-latex-bibtex-link would internally find the link, process
> the BibTeX entry and return a sensible \cite{...} string.
>
> What do you think?

If we're not going to provide a multi-backend solution, I suggest to
keep things simple and write LaTeX code directly (or use the solution
provided by Eric). Unless you have something else in mind with these
link abbrevs, of course.


Regards,

-- 
Nicolas Goaziou

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Bastien <bzg@altern.org> writes:
>
>> Hi Andreas and all,
>>
>> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>>
>>> Eric suggested/uses this format (thanks for sharing, Eric):
>>>   [[cite:jones-etal-2000][Jones et al., 2000]]
>>>          ^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^^^
>>>              key           displayed in org
>>
>> I'd suggest to treat org-link-abbrev-alist and locally defined
>> abbreviated links differently when opening the link at point and
>> when exporting the buffer.
>>
>> At expand time, the exporter could attach a list of export functions
>> (filters?) to the expanded link, depending on the local setting for
>> the abbreviated link or `org-link-abbrev-alist'.  For example:
>>
>>  #+LINK: cite file:my.bib::%s org-latex-bibtex-link
>>  
>>  (setq org-link-abbrev-alist
>>    '(("cite" "file:my.bib::%s" 'org-latex-bibtex-link)))
>>  
>> Then org-latex-bibtex-link would internally find the link, process
>> the BibTeX entry and return a sensible \cite{...} string.
>>
>> What do you think?
>
> If we're not going to provide a multi-backend solution, I suggest to
> keep things simple and write LaTeX code directly (or use the solution
> provided by Eric). Unless you have something else in mind with these
> link abbrevs, of course.
>

I agree.  Getting 'simple' \cite or better [[cite: ]] links to export in
other backends than LaTeX only should be the first step, anyway.

Regards,
Andreas

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> If we're not going to provide a multi-backend solution, I suggest to
> keep things simple and write LaTeX code directly (or use the solution
> provided by Eric). Unless you have something else in mind with these
> link abbrevs, of course.

Can you resend me the link to Eric's suggestion?

Actually my suggestion is multi-backends ready: I gave an example for
`org-latex-bibtex-link', but `org-html-bibtex-link' could be used at
the same place.

The link export mechanism would be in charge to select the right
function when there are several.  If there is no backend-specific
function, the exporter would fall back on the normal export mechanism
for links.

The trick would just be to attach the available functions (possibly
multiple ones, for the various backends) as properties to the links
(aka :latex-link-function for the :link object in the internal
representation) and to select the correct function depending on the
export backend.

Do it make (some) sense?  The idea is to *not* add a new link type
with a new syntax, but to rely on the abbreviated links, which I
think are flexible enough.

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Hi Bastien,

Bastien <bzg@altern.org> writes:

> Hi Nicolas,
>
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> If we're not going to provide a multi-backend solution, I suggest to
>> keep things simple and write LaTeX code directly (or use the solution
>> provided by Eric). Unless you have something else in mind with these
>> link abbrevs, of course.
>
> Can you resend me the link to Eric's suggestion?

http://permalink.gmane.org/gmane.emacs.orgmode/67574

>
> Actually my suggestion is multi-backends ready: I gave an example for
> `org-latex-bibtex-link', but `org-html-bibtex-link' could be used at
> the same place.
>
> The link export mechanism would be in charge to select the right
> function when there are several.  If there is no backend-specific
> function, the exporter would fall back on the normal export mechanism
> for links.
>
> The trick would just be to attach the available functions (possibly
> multiple ones, for the various backends) as properties to the links
> (aka :latex-link-function for the :link object in the internal
> representation) and to select the correct function depending on the
> export backend.
>
> Do it make (some) sense?  The idea is to *not* add a new link type
> with a new syntax, but to rely on the abbreviated links, which I
> think are flexible enough.

To give some un-qualified comment: As far as I understand your
suggestion, I like it from the technical point of view.
But it looks very verbose to me.  I expect the introduction to a
scientific paper (with typically many \cite{}s) to look disrupted.

Regards,
Andreas

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Andreas,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> But it looks very verbose to me.  I expect the introduction to a
> scientific paper (with typically many \cite{}s) to look disrupted.

Each \cite{...} would be nothing more than
[[cite:A.N.Whitehead][A.N.Whitehead]] in the Org file.

The config happens in the #+LINK: cite ... line.

I also think the proposal makes it easy to use several
bibliographic files, with several #+LINK: citeN ... lines.

In general, the idea is just to be able to hook an export
function to a link after it has been expanded, and maybe 
this can be useful beyond this use-case.  For example:

  #+LINK: local file://%s org-odt-local-link
  #+LINK: local file://%s org-odt-global-link

The first line would be used for documents that you want
to use locally, creating links to your files on your machine.
The second line would be used for documents that want to 
share with others.

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Hi Bastien,


Bastien <bzg@altern.org> writes:

> Hi Andreas,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> But it looks very verbose to me.  I expect the introduction to a
>> scientific paper (with typically many \cite{}s) to look disrupted.
>
> Each \cite{...} would be nothing more than
> [[cite:A.N.Whitehead][A.N.Whitehead]] in the Org file.
>

In this case, you can ignore my comment on verbosity.

> The config happens in the #+LINK: cite ... line.
>
> I also think the proposal makes it easy to use several
> bibliographic files, with several #+LINK: citeN ... lines.
>
> In general, the idea is just to be able to hook an export
> function to a link after it has been expanded, and maybe 
> this can be useful beyond this use-case.  For example:
>
>   #+LINK: local file://%s org-odt-local-link
>   #+LINK: local file://%s org-odt-global-link
>
> The first line would be used for documents that you want
> to use locally, creating links to your files on your machine.
> The second line would be used for documents that want to 
> share with others.

Now, that there is a proposal supporting additional citation command,
and pre-, post-notes 
(http://permalink.gmane.org/gmane.emacs.orgmode/67818) I would
definitely love to see that supported.
So my question is: are your proposals mergable?  Or are they orthogonal?

Regards,
Andreas

Re: org-exp-bibtex missing in git?

[aaronecay]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

2013ko martxoak 6an, Bastien-ek idatzi zuen:
> I'd suggest to treat org-link-abbrev-alist and locally defined
> abbreviated links differently when opening the link at point and
> when exporting the buffer.
> 
> At expand time, the exporter could attach a list of export functions
> (filters?) to the expanded link, depending on the local setting for
> the abbreviated link or `org-link-abbrev-alist'.  For example:
> 
>  #+LINK: cite file:my.bib::%s org-latex-bibtex-link
>  
>  (setq org-link-abbrev-alist
>    '(("cite" "file:my.bib::%s" 'org-latex-bibtex-link)))
>  
> Then org-latex-bibtex-link would internally find the link, process
> the BibTeX entry and return a sensible \cite{...} string.
> 
> What do you think?

I’m not sure I understand this proposal correctly.  Specifically, the
exporter needs to know to insert a link to the bib file in the header of
the document (for BibLaTeX, this is the \addbibresource command); I’m
not sure where that information would come from in this proposal: would
the backend have to inspect the value of ‘org-link-abbrev-alist’?

I’ve got some mostly-working code that exports citations, only for
latex, using a different approach (similar to Eric’s).  I’ve cleaned it
up some, and attached it as a patch to this email.  It uses the
following syntax for links: [[type:key;pre;post][desc]].  I agree with
Eric that an expanded syntax for encoding pre and post citation commands
would be welcome.  This code does insert the commands to load the bibtex
file(s) into the document’s header.  It shoudl support multiple bib
files, as well as setting the file with an EXPORT_BIBLIOGRAPHY property
on a subtree, though I haven’t tested either of those functions
thoroughly.  It also supports following a link to either a bibtex file
or (if you manage your bibliography with org-bibtex) an org file.

Things it doesn’t yet do:
- automatically insert the latex code to print the bibliography (because
  I couldn’t think of a way to do this customizably enough – someone
  might want to have the bibliography at the end, not at the end, one
  bibliography per section, ...)
- automatically insert the proper \usepackage into the header.  I think
  the code should eventually do this, but Nicolas might disagree that
  that should instead go into org-latex-classes.

Obviously this code needs work, but perhaps it can be a base on which to
build.  Supporting non-biblatex latex packages is an obvious low-hanging
fruit.  Support for HTML could probably come from citeproc-js
(https://bitbucket.org/fbennett/citeproc-js/wiki/Home), but I will leave
work on that to someone who is more familiar with HTML/JS/the ox-html
backend than I.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Support-export-of-bibliography-links-WIP.patch --]
[-- Type: text/x-patch, Size: 5315 bytes --]

From 044f84632ecf8518184f45802a97a9fa91f9a6d6 Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Thu, 7 Mar 2013 00:22:07 -0500
Subject: [PATCH] Support export of bibliography links (WIP)

---
 lisp/ox-bib.el   | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lisp/ox-latex.el |   8 +++++
 lisp/ox.el       |   1 +
 3 files changed, 117 insertions(+)
 create mode 100644 lisp/ox-bib.el

diff --git a/lisp/ox-bib.el b/lisp/ox-bib.el
new file mode 100644
index 0000000..d726e31
--- /dev/null
+++ b/lisp/ox-bib.el
@@ -0,0 +1,108 @@
+(require 'bibtex)
+(require 'ox)
+
+(defvar ox-bib-find-entries-in-org-file nil
+  "Whether to look for bibliogrpahy entries in an org mode file
+or a bibtex file.")
+
+(defun ox-bib-get-bibliography ()
+  (mapcar (lambda (s)
+            (org-no-properties s))
+	  ;; Don't explode if before the first headline
+          (or
+           (condition-case nil
+               (plist-get (org-export-get-environment nil t) :bibliography)
+             (error nil))
+           (save-excursion
+             (widen)
+             (goto-char (point-min))
+             (plist-get (org-export-get-environment) :bibliography)))))
+
+(defun ox-bib-get-key (path &optional desc)
+  "Extract cite key from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+  (nth 0 (split-string path ";")))
+
+(defun ox-bib-get-pre (path &optional desc)
+  "Extract pre-citation arg from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+  (or (nth 1 (split-string path ";")) ""))
+
+(defun ox-bib-get-post (path &optional desc)
+  "Extract post-citation arg from a link path and desc.
+
+Currently expects links in the format:
+\[[type:key;pre;post;][desc]]"
+  (or (nth 2 (split-string path ";")) ""))
+
+;; Adapted from org-find-entry-with-custom-id; there might be a better
+;; way to do this
+(defun org-find-entry-with-custom-id (ident)
+  (let ((id ident)
+        (case-fold-search nil))
+    (save-excursion
+      (save-restriction
+        (widen)
+        (goto-char (point-min))
+        (when (re-search-forward
+               (concat "^[ \t]*:CUSTOM_ID:[ \t]+" (regexp-quote id) "[ \t]*$")
+               nil t)
+          (org-back-to-heading t)
+          (point))))))
+
+(defun ox-bib-cite-follow (path)
+  (let* ((files (ox-bib-get-bibliography))
+	 (key (ox-bib-get-key path))
+	 file done)
+    (when ox-bib-find-entries-in-org-file
+      (setq files
+	    (mapcar (lambda (s)
+		      (replace-regexp-in-string "\\.bib\\'" ".org" s))
+		    files)))
+    (while (and (car-safe files) (not done))
+      (setq file (car-safe files))
+      (when (file-exists-p file)
+        (let* ((buf (find-file-noselect file))
+
+	       (pos (with-current-buffer buf
+		      (cond
+		       (ox-bib-find-entries-in-org-file
+			(org-find-entry-with-custom-id key))
+		       (t (bibtex-search-entry key))))))
+	  (when pos
+	    (setq done (cons buf pos)))))
+      (setq files (cdr files)))
+    (if done
+	(progn
+          (pop-to-buffer (car done))
+	  (goto-char (cdr done))
+          (when ox-bib-find-entries-in-org-file
+            (org-show-context)))
+      (message "Citation not found: %s" key))))
+
+(defun ox-bib-textcite-export (path desc format)
+  (cond
+   ((org-export-derived-backend-p format 'latex)
+    (let ((key (ox-bib-get-key path desc))
+	  (pre (ox-bib-get-pre path desc))
+	  (post (ox-bib-get-post path desc)))
+      (format "\\textcite[%s][%s]{%s}" pre post key)))
+   (t
+    (format "<textcite to: %s>" path))))
+
+(defun ox-bib-parencite-export (path desc format)
+  (cond
+   ((org-export-derived-backend-p format 'latex)
+    (let ((key (ox-bib-get-key path desc))
+          (pre (ox-bib-get-pre path desc))
+          (post (ox-bib-get-post path desc)))
+      (format "\\parencite[%s][%s]{%s}" pre post key)))
+   (t
+    (format "<parencite to: %s>" path))))
+
+(org-add-link-type "textcite" #'ox-bib-cite-follow #'ox-bib-textcite-export)
+(org-add-link-type "parencite" #'ox-bib-cite-follow #'ox-bib-parencite-export)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 8a5b6a6..ed5dcad 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1153,6 +1153,14 @@ holding export options."
 	       (or (plist-get info :description) "")
 	       (if (not (plist-get info :with-creator)) ""
 		 (plist-get info :creator))))
+     ;; Bibliography
+     (let* ((bibs (plist-get info :bibliography))
+            (bib-cmds (mapconcat (lambda (s)
+                                   (format "\\addbibresource{%s}" s))
+                                 bibs "\n")))
+       (if bibs
+	   (concat bib-cmds "\n")
+	 ""))
      ;; Document start.
      "\\begin{document}\n\n"
      ;; Title command.
diff --git a/lisp/ox.el b/lisp/ox.el
index 3a0764d..bdff5ee 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -118,6 +118,7 @@
     (:select-tags "SELECT_TAGS" nil org-export-select-tags split)
     (:time-stamp-file nil "timestamp" org-export-time-stamp-file)
     (:title "TITLE" nil nil space)
+    (:bibliography "BIBLIOGRAPHY" nil nil split)
     (:with-archived-trees nil "arch" org-export-with-archived-trees)
     (:with-author nil "author" org-export-with-author)
     (:with-clocks nil "c" org-export-with-clocks)
-- 
1.8.1.5


[-- Attachment #3: Type: text/plain, Size: 17 bytes --]



-- 
Aaron Ecay

Re: org-exp-bibtex missing in git?

[Eric S Fraga]

<aaronecay@gmail.com> writes:

[...]

> I’ve got some mostly-working code that exports citations, only for
> latex, using a different approach (similar to Eric’s).  I’ve cleaned it
> up some, and attached it as a patch to this email.

This looks quite nice.

I am unlikely to try it out, however, as my simple cite: (and related
citep:) link definition does the job for me.  I keep things simple when
writing papers... I let the journal editors and publishers worry about
detail ;-).  Nevertheless, I can see this enhancement being quite useful
for those that need the extra features in reference citations.

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Aaron,

I now see where you and Eric go and this is good!

Here is a revised suggestion, allowing to add link types from withing
the #+LINK keyword.

1. Allow more syntax for #+LINK:
   
   #+LINK: bib;%s;%s file:my.bib::%s org-bib-follow-link org-bib-export-link

If `org-bib-follow-link' is nil, it'll follow [[bib:my.bib::key][key]]
like it does right now, jumping to the "key" line in the my.bib file.

If `org-bib-follow-link' is non-nil, it will operate on
[[bib:my.bib::key;prenote;postnote][key]] and find the correct key.

If `org-bib-export-link' is non-nil, it will operate on
[[bib:my.bib::key;prenote;postnote][key]] and export it correctly
depending on the backend.

The change required for the exporter is to let `org-bib-follow-link'
and `org-bib-export-link' operate on [[bib::my.bib::key;prenote;postnote]], 
not on the expanded link.  IOW, link expansion should happen within
the backend export routines, treating abbreviated links with formatting
strings (aka "bib;%s;%s") in a special way.

I see two advantages:

- adding new types will be easier -- e.g.:
  #+LINK: cite file:my.bib::%s org-bib-follow-link org-bib-export-link

- users can decide what syntactic glue they want to their abbreviated
  links (using ";" or another separator).

Nicolas, do you think it is feasible/good to delay link expansion
till the backend knows whether the abbreviated link is associated
to follow/export function that would understand formatting strings
in the abbreviated form?

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Aaron Ecay]

Hi Bastien,

On Thu, Mar 7, 2013 at 5:21 AM, Bastien <bzg@altern.org> wrote:
> Hi Aaron,
>
> I now see where you and Eric go and this is good!
>
> Here is a revised suggestion, allowing to add link types from withing
> the #+LINK keyword.

I suspect you may be targeting the wrong layer.  Don't we want to use
org-link-protocols, not org-link-abbrev-alist?  Protocols are already
handled by the exporter, so there should be no need for a change like
this one:
[...]
> Nicolas, do you think it is feasible/good to delay link expansion
> till the backend knows whether the abbreviated link is associated
> to follow/export function that would understand formatting strings
> in the abbreviated form?

My proposal works without any changes to the exporter's structure
(except adding the #+BIBLIOGRAPHY keyword, which is a one-line
emendation).  It does not allow the equivalent of your "#+LINK:
bib:%s;%s;%s" for specifying the pre/post delimiters, but maybe it
would be better from a standardization-of-syntax point of view to have
just one way of encoding them?

Aaron

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> I suspect you may be targeting the wrong layer.  Don't we want to use
> org-link-protocols, not org-link-abbrev-alist?  Protocols are already
> handled by the exporter, so there should be no need for a change like
> this one:
> [...]

I want to allow adding link protocols (what I called "adding link
types") from #+LINK.

>> Nicolas, do you think it is feasible/good to delay link expansion
>> till the backend knows whether the abbreviated link is associated
>> to follow/export function that would understand formatting strings
>> in the abbreviated form?
>
> My proposal works without any changes to the exporter's structure
> (except adding the #+BIBLIOGRAPHY keyword, which is a one-line
> emendation).  It does not allow the equivalent of your "#+LINK:
> bib:%s;%s;%s" for specifying the pre/post delimiters, but maybe it
> would be better from a standardization-of-syntax point of view to have
> just one way of encoding them?

IIUC your proposal introduces some syntactic glue here:
[[type:key;pre;post][desc]]
          ^   ^

If we allow this, it's better to allow this in general than just for a
specific link type.  Hence my proposal to extend link abbreviation to
be recognized as new link types when the #+LINK line contains more
than two strings.

See for example this new link type (or "protocol"):

#+LINK: with-title::%s http://orgmode.org/worg/doc.html# nil org-html-link-with-title

  [[with-title::org-mode::A link title][org-mode]]

org-html-link-with-title would then take care of exporting this
as a link like <a href="..." title="A link title">org-mode</a>.

There are really two changes here:

1. extending #+LINK so that the third and fourth strings are
   recognized as follow and export functions

2. extending #+LINK so that a formatting string in the link
   abbreviation name is handle later on by those functions.

What do you think?

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Aaron Ecay]

Hi Bastien,

On Thu, Mar 7, 2013 at 6:16 AM, Bastien <bzg@altern.org> wrote:
> I want to allow adding link protocols (what I called "adding link
> types") from #+LINK.

Hmm.  I think I am beginning to understand your motivation for this.

> IIUC your proposal introduces some syntactic glue here:
> [[type:key;pre;post][desc]]
>           ^   ^
>
> If we allow this, it's better to allow this in general than just for a
> specific link type.  Hence my proposal to extend link abbreviation to
> be recognized as new link types when the #+LINK line contains more
> than two strings.

Will this be general enough, though?  HTML links can have a target in
addition to a title.  What if we used a key/value syntax?  Something
like:
[[type:address;key1=value1,key2=value2][description]]

The key/value pairs could be handled by the parser, and passed to the
link export function as an additional argument (or somehow stored in
one of the plists that gets shuffled around).

Then org-html-link would have to learn how to handle title, target,
and alt properties (the latter for images), as well as perhaps class
(for CSS styles).   I think there was a thread in the past couple
weeks, wherein it came to light that it's not possible presently to
uniquely associate an alt text with an image link (but I could be
misremembering, I didn't pay very close attention); this would fix
that issue as well.  org-bib-link would handle pre and post keywords.
(Obviously, the delimiters for this syntax would have to be chosen
carefully: semicolon and comma may not be the best choices.)

Then, it could be possible to have a keyword (perhaps LINK, but
perhaps PROTOCOL to decrease ambiguity) that behaves like a BIND for
org-link-protocols.  That is in the document
#+PROTOCOL: foo org-follow-foo org-export-foo
would be equivalent to the following lisp
(org-add-link-type "foo" #'org-follow-foo #'org-export-foo)

This still doesn't meet your desideratum of being able to specify new
syntaxes on the fly in a #+LINK keyword.  But one still has to write
lisp on your proposal (the org-html-link-with-title function), so it
just comes down to whether the customization goes in the document or
in the lisp.  (Which is ultimately a matter of taste, although my
impression is that one of the themes of the switch to the new exporter
has been to constrain the syntax and provide richer interfaces at the
lisp level for customizing behavior.)

Does that sound like a sensible proposal?  It has grown a bit beyond
the original "let's have bibliographies" motivation, but I hope that
it facilitates that while also being helpful more broadly.

Aaron

Re: org-exp-bibtex missing in git?

[Nicolas Goaziou]

Bastien <bzg@altern.org> writes:

> Hi Aaron,
>
> I now see where you and Eric go and this is good!
>
> Here is a revised suggestion, allowing to add link types from withing
> the #+LINK keyword.
>
> 1. Allow more syntax for #+LINK:
>    
>    #+LINK: bib;%s;%s file:my.bib::%s org-bib-follow-link org-bib-export-link
>
> If `org-bib-follow-link' is nil, it'll follow [[bib:my.bib::key][key]]
> like it does right now, jumping to the "key" line in the my.bib file.
>
> If `org-bib-follow-link' is non-nil, it will operate on
> [[bib:my.bib::key;prenote;postnote][key]] and find the correct key.
>
> If `org-bib-export-link' is non-nil, it will operate on
> [[bib:my.bib::key;prenote;postnote][key]] and export it correctly
> depending on the backend.
>
> The change required for the exporter is to let `org-bib-follow-link'
> and `org-bib-export-link' operate on [[bib::my.bib::key;prenote;postnote]], 
> not on the expanded link.  IOW, link expansion should happen within
> the backend export routines, treating abbreviated links with formatting
> strings (aka "bib;%s;%s") in a special way.
>
> I see two advantages:
>
> - adding new types will be easier -- e.g.:
>   #+LINK: cite file:my.bib::%s org-bib-follow-link org-bib-export-link
>
> - users can decide what syntactic glue they want to their abbreviated
>   links (using ";" or another separator).
>
> Nicolas, do you think it is feasible/good to delay link expansion
> till the backend knows whether the abbreviated link is associated
> to follow/export function that would understand formatting strings
> in the abbreviated form?

I think that if we ever implement a bibliography/citations handlers,
they should be first class objects in Org syntax (like footnotes).
Overloading link syntax would, IMO, be wrong in that case.

Also, link abbrevs and link protocol handlers are meant for the
end-user, not for official syntax.

I suggest to avoid using link syntax for citations altogether, but if we
do, the citation must not depend on an user-defined function. The whole
syntax must be attached to the link.

Therefore, I agree that link syntax needs to be extended. I'm thinking
in particular about per-link export properties. Adding in separator in
the path part is an interesting idea, as long as it isn't a string
widely used in paths.

In a nutshell, my POV is:
 - we should avoid overloading #+LINK syntax and overusing link-abbrevs.
 - citations, if implemented globally, deserve their own syntax.
 - changing the general link type to:

     [[PROTOCOL:PATH/SEP/OPTIONS][DESCRIPTION]]

   is fine.

 
Regards,

-- 
Nicolas Goaziou

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Nicolas,

I like Aaron's idea (maybe others proposed this too) of having
parameters in links:

[[file:my.bib::key&&prenote=my prenote&&postnote=my postnote]]

[[http://perdu.com&&title=You're lost?]]

This is orthogonal to my proposal of extending #+LINK to be able
to define new protocols (by allowing to add a follow and an export
functions); and this is orthogonal to whether link abbrevs can have
more than one formatting string %s.

We would just need to pass the parameters as keywords to the export
function, either the default one, either the defined by the protocol.

E.g., the first link would be represented by the parser like this:

   (:type "file"
    :path "my.bib"
    :raw-link "file:orgmode.org::test2"
    :application nil
    :search-option "test2"
    :parameters '(:title "You're lost")
    :begin 63
    :end 97
    :contents-begin 90
    :contents-end 95
    :post-blank 0
    :parent #3)

Then org-html-link would get the parameters with

  (org-element-property :parameters link)
  => '(:title "You're lost")

I think this is general and useful.

If we implement this, it would be nice to extend link abbrevs to
support multiple formatters in `org-link-abbrev-alist'.

  #+LINK: citeA file:my.bib::%s&&prenote=%s&&postnote=%s

And this would spare us for the need of another object dedicated
to bibliographic citations:

  [[citeA::key&&prenote=my note&&postnote=my note]]

What do you think?

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Achim Gratz]

Bastien writes:
> I like Aaron's idea (maybe others proposed this too) of having
> parameters in links:

We've had some of this discussion about two years ago IIRC, so here I am
again: there's an internet standard for this kind of thing, it's called
URN/URI.  If we adhere to this, we can at least hope for
interoperability and outside tool support.  I don't think we should try
to invent something that is almost, but not entirely unlike the
standard.  (with apologies to the late Douglas N. Adams) 

Back to citations, I don't know if an URI scheme for citations already
exists.  Citation tools are complicated because nobody really agrees on
what they should do exactly and there are many different citation
styles.

The common ground is that there is a key/handle for the citation itself
and then different fields for different types of citations to pull the
various bits of information together into an actual citation, in
whatever order and form that is prescribed.  If you're writing for the
Journal of Irreproducible Results and the Magazine of Things that go
Boom!, you'll likely have just two definitions that you will somehow
reference in the respective articles.  Here's what Wikipedia says is
around, and that surely is only the tip of the iceberg:

https://en.wikipedia.org/wiki/Comparison_of_reference_management_software

If there's no support for BibTeX however, you probably shouldn't play at
all.  BibTeX itself has a long and colored past:

https://en.wikipedia.org/wiki/BibTeX

That it is still used should be an indication that its basic principles
are sound.  The most interesting part of this history from the Org/Emacs
perspective is perhaps CL-BibTeX.  At least Bibsonomy.org has several
response formats for queries including JSON (and BibTeX, of course) and
lets you ask for the whole database entry and a pre-formatted citation.
I haven't payed close attention to Zotero, but I think they are doing
something similar.  So it might be possible today to simply (or not so
simply) have a reference scheme and have all the database and formatting
work done by one of these (or more likely several of them) services.
But even coming up with a good reference scheme (the "links with
parameters" part) for this will be a sizeable project.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Bastien writes:
>> I like Aaron's idea (maybe others proposed this too) of having
>> parameters in links:
>
> We've had some of this discussion about two years ago IIRC, so here I am
> again: there's an internet standard for this kind of thing, it's called
> URN/URI.  

I'm all for following established standards, but I'm not sure what is
the concrete proposal here.

Do you mean using something like this

  [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]

for the file: protocol, where key, prenote and postnote would be
parsed as keywords by the export function?  Obvisouly we cannot
use this for the http protocol, local parameters would conflict
with the URL ones -- but maybe I didn't understand.

Thanks for further enlightenment!

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Achim Gratz]

Bastien writes:
> I'm all for following established standards, but I'm not sure what is
> the concrete proposal here.

I don't have one yet, mainly because I'm fuzzy on what direction this
will take.  I ask again to consider what's already out there and that's
mainly BibTeX and things that work in principle like BibTex: in the
document itself you only say "here's a citation" and the rest of the
handling takes place outside (there are style files, databases in files
and online, tools for making and converting them).  You make the
connection by specifying a configuration in the document.  Now if Org
would abstract away some of these differences and maybe work in
conjunction with some of these outside programs to maybe pull references
from online sources and cache them locally (I always hate this step
since it is so repetitive), then we're talking.

> Do you mean using something like this
>
>   [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]
>
> for the file: protocol

This is a prime example of how _not_ to do this, IMHO.  The file
protocol is an established protocol that you shouldn't bolt any extra
parameters on.  In fact there is no reason to even think of it as a
file: protocol since the filename is just another parameter; you don't
want to get a file at all.  Choose another more suitable protocol or, if
none exists, define your own.  Assuming I interpret the intent of this
link correctly, you want to look up key in file my.bib and then
construct a citation with a post- and prenote, while (redundantly?)
using key again for display in the Org document.  This is involving a
lot of things that don't necessarily belong into the same invocation:
where the data is stored, how to get at it, what parts of the data to
extract and lastly how to present the result.  I submit that this is is
probably too complicated to try and cram all of this into the "link
syntax".


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: org-exp-bibtex missing in git?

[Rasmus Pank Roulund]

The following message is a courtesy copy of an article
that has been posted to gmane.emacs.orgmode as well.

Achim Gratz <Stromeko@nexgo.de> writes:

>> Do you mean using something like this
>>
>>   [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]
>>
>> for the file: protocol
>
> This is a prime example of how _not_ to do this, IMHO.  The file
> protocol is an established protocol that you shouldn't bolt any extra
> parameters on.  

I very much agree.  The current "hacks" using links are annoying and
ugly, and if we were to do citations properly in Org—and I think we
should—it should NOT be using links (as Nicolas also pointed out).
It's a hack and shouldn't be made official.

In my book it would seem 'natural' to strive towards the following:

  1. It should be Bibtex-based.  I.e. Bibtex should be the 'database'
     or storage for citation information.  It may be stored in
     Org-Bibtex-whatever, but Bibtex should be the natural base.
  2. Citation selection should be possible via Reftex.
  3. It should look nice in the buffer.  For instance, with the
     current link hacks I am shown the pre or post notes in place of
     the citation.  Ideally, it should be able to specify a
     reftex-cite-format string on how to display stuff in the buffer.
     Notes should be viewable in an non-disturbing way.
     Ideally, I would want to see something like:
       (POSTFIX, Jensen, 1906, SUFFIX)
     or
       Jensen (POSTFIX, 1906, SUFFIX)
     (If my memory serves me correctly this is how BibLatex places
     notes).
 (4. If we are to adopt LaTeX terminology we should adopt the
     terminology of BibLatex as opposed to Natbib). 

–Rasmus

-- 
Dung makes an excellent fertilizer

Re: org-exp-bibtex missing in git?

[Rasmus]

 Achim Gratz <Stromeko@nexgo.de> writes:

>> Do you mean using something like this
>>
>>   [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]
>>
>> for the file: protocol
>
> This is a prime example of how _not_ to do this, IMHO.  The file
> protocol is an established protocol that you shouldn't bolt any extra
> parameters on.  

I very much agree.  The current "hacks" using links are annoying and
ugly, and if we were to do citations properly in Org—and I think we
should—it should NOT be using links (as Nicolas also pointed out).
It's a hack and shouldn't be made official.

In my book it would seem 'natural' to strive towards the following:

  1. It should be Bibtex-based.  I.e. Bibtex should be the 'database'
     or storage for citation information.  It may be stored in
     Org-Bibtex-whatever, but Bibtex should be the natural base.
  2. Citation selection should be possible via Reftex.
  3. It should look nice in the buffer.  For instance, with the
     current link hacks I am shown the pre or post notes in place of
     the citation.  Ideally, it should be able to specify a
     reftex-cite-format string on how to display stuff in the buffer.
     Notes should be viewable in an non-disturbing way.
     Ideally, I would want to see something like:
       (POSTFIX, Jensen, 1906, SUFFIX)
     or
       Jensen (POSTFIX, 1906, SUFFIX)
     (If my memory serves me correctly this is how BibLatex places
     notes).
 (4. If we are to adopt LaTeX terminology we should adopt the
     terminology of BibLatex as opposed to Natbib). 

–Rasmus


-- 
May the Force be with you

Re: org-exp-bibtex missing in git?

[Thomas S. Dye]

Rasmus <rasmus@gmx.us> writes:

>  Achim Gratz <Stromeko@nexgo.de> writes:
>
>>> Do you mean using something like this
>>>
>>>   [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]
>>>
>>> for the file: protocol
>>
>> This is a prime example of how _not_ to do this, IMHO.  The file
>> protocol is an established protocol that you shouldn't bolt any extra
>> parameters on.  
>
> I very much agree.  The current "hacks" using links are annoying and
> ugly, and if we were to do citations properly in Org—and I think we
> should—it should NOT be using links (as Nicolas also pointed out).
> It's a hack and shouldn't be made official.
>
> In my book it would seem 'natural' to strive towards the following:
>
>   1. It should be Bibtex-based.  I.e. Bibtex should be the 'database'
>      or storage for citation information.  It may be stored in
>      Org-Bibtex-whatever, but Bibtex should be the natural base.
>   2. Citation selection should be possible via Reftex.
>   3. It should look nice in the buffer.  For instance, with the
>      current link hacks I am shown the pre or post notes in place of
>      the citation.  Ideally, it should be able to specify a
>      reftex-cite-format string on how to display stuff in the buffer.
>      Notes should be viewable in an non-disturbing way.
>      Ideally, I would want to see something like:
>        (POSTFIX, Jensen, 1906, SUFFIX)
>      or
>        Jensen (POSTFIX, 1906, SUFFIX)
>      (If my memory serves me correctly this is how BibLatex places
>      notes).
>  (4. If we are to adopt LaTeX terminology we should adopt the
>      terminology of BibLatex as opposed to Natbib). 

Given that 1., 2., and 4. are possible with "link hacks" doesn't this
leave just 3. in need of solution?  If the current link syntax would
take another function used to display the link, then wouldn't that solve
3.? 

Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-exp-bibtex missing in git?

[Rasmus]

tsd@tsdye.com (Thomas S. Dye) writes:

> Rasmus <rasmus@gmx.us> writes:
>
>>  Achim Gratz <Stromeko@nexgo.de> writes:
>>
>>>> Do you mean using something like this
>>>>
>>>>   [[file:my.bib&key=key;prenote=note1;postnote=note2][key]]
>>>>
>>>> for the file: protocol
>>>
>>> This is a prime example of how _not_ to do this, IMHO.  The file
>>> protocol is an established protocol that you shouldn't bolt any extra
>>> parameters on.  
>>
>> I very much agree.  The current "hacks" using links are annoying and
>> ugly, and if we were to do citations properly in Org—and I think we
>> should—it should NOT be using links (as Nicolas also pointed out).
>> It's a hack and shouldn't be made official.
>>
>> In my book it would seem 'natural' to strive towards the following:
>>
>>   1. It should be Bibtex-based.  I.e. Bibtex should be the 'database'
>>      or storage for citation information.  It may be stored in
>>      Org-Bibtex-whatever, but Bibtex should be the natural base.
>>   2. Citation selection should be possible via Reftex.
>>   3. It should look nice in the buffer.  For instance, with the
>>      current link hacks I am shown the pre or post notes in place of
>>      the citation.  Ideally, it should be able to specify a
>>      reftex-cite-format string on how to display stuff in the buffer.
>>      Notes should be viewable in an non-disturbing way.
>>      Ideally, I would want to see something like:
>>        (POSTFIX, Jensen, 1906, SUFFIX)
>>      or
>>        Jensen (POSTFIX, 1906, SUFFIX)
>>      (If my memory serves me correctly this is how BibLatex places
>>      notes).
>>  (4. If we are to adopt LaTeX terminology we should adopt the
>>      terminology of BibLatex as opposed to Natbib). 
>
> Given that 1., 2., and 4. are possible with "link hacks" doesn't this
> leave just 3. in need of solution?  If the current link syntax would
> take another function used to display the link, then wouldn't that solve
> 3.? 

Indeed, but perhaps there is a better possible syntax.  With Reftex
the the link-way is OK, but I still think that we should think about
whether there is a "Better Way"ᵀᴹ if Org was to add it officially.

There are some recent projects adding citation support for higher
level languages such as:

   1. https://github.com/cboettig/knitcitations
   2. http://wordpress.org/extend/plugins/kcite/

–Rasmus

-- 
May the Force be with you

Re: org-exp-bibtex missing in git?

[Thomas S. Dye]

Aloha Rasmus,

Rasmus <rasmus@gmx.us> writes:

> tsd@tsdye.com (Thomas S. Dye) writes:
>
>
> Indeed, but perhaps there is a better possible syntax.  With Reftex
> the the link-way is OK, but I still think that we should think about
> whether there is a "Better Way"ᵀᴹ if Org was to add it officially.
>
> There are some recent projects adding citation support for higher
> level languages such as:
>
>    1. https://github.com/cboettig/knitcitations
>    2. http://wordpress.org/extend/plugins/kcite/

Thanks for these pointers--very interesting. It is certainly seductive
to think about pointing to a location such as a DOI and coming away with
a useful citation.

In my experience, there is typically a fairly wide gap between the
publisher's citation style and the information available digitally, even
in standard MARC records from a library. I bridge this gap by hand with
lots of changes to a Bib(La)TeX entry taken off the Web.  It would
certainly be a feat if this could be done automatically.

Part of the problem is publisher's citation styles.  BibLaTeX tries to
canvas that field, and the result is pretty complex.  The data needs for
a fully catholic BibLaTeX database are impractically large.

I'm not trying to throw cold water on a prospective project and would be
an avid user of a working "Better Way."

All the best,
Tom 

-- 
T.S. Dye & Colleagues, Archaeologists
735 Bishop St, Suite 315, Honolulu, HI 96813
Tel: 808-529-0866, Fax: 808-529-0884
http://www.tsdye.com

Re: org-exp-bibtex missing in git?

[aaronecay]

Hi Rasmus,

2013ko martxoak 7an, Rasmus Pank Roulund-ek idatzi zuen:
> 
> In my book it would seem 'natural' to strive towards the following:
> 
>   1. It should be Bibtex-based.  I.e. Bibtex should be the 'database'
>      or storage for citation information.  It may be stored in
>      Org-Bibtex-whatever, but Bibtex should be the natural base.
>   2. Citation selection should be possible via Reftex.

In principle this is true, but I think RefTeX is deeply intertwined with
the assumption that it is running in a LaTeX buffer.  Going through its
code and making it major-mode-agnostic is a worthy project all of its
own.  But it might take less effort and be more long-run maintainable to
just wire up the bibtex.el bundled with emacs, CompletionUI
(http://www.emacswiki.org/CompletionUI) and YAsnippet
(http://emacswiki.org/emacs/Yasnippet).

>   3. It should look nice in the buffer.  For instance, with the
>      current link hacks I am shown the pre or post notes in place of
>      the citation.  Ideally, it should be able to specify a
>      reftex-cite-format string on how to display stuff in the buffer.
>      Notes should be viewable in an non-disturbing way.
>      Ideally, I would want to see something like:
>        (POSTFIX, Jensen, 1906, SUFFIX)
>      or
>        Jensen (POSTFIX, 1906, SUFFIX)
>      (If my memory serves me correctly this is how BibLatex places
>      notes).

One could do this with font-lock and the new citation syntax I proposed
in my other email.  We would need two alists.  One would pair citation
lookup types with functions to resolve them to a location, and to get
their properties.  The other would pair display types with two
functions: one to return a format string that would be displayed by
font-lock instead of the citation markup, and one to return the code to
export the citation.

So, a citation like [cite:doi:parens:some-doi:key=val&key2=val2] would be
displayed by:
1. call (org-lookup-cite-doi "some-doi") -> (:author "Foo" :title "bar" ...)
2. call (org-display-cite-parens '(:author "Foo" :title "bar" ...)) ->
   "(Foo 2000)"
3. (font-lock puts an overlay over the citation markup, with the
   returned string)

If you click on the citation, org would open the location (URL or local
file) returned by (org-resolve-cite-doi "some-doi")

A citation could exported by calling (org-export-cite-parens 'doi
"some-doi" (:author "foo" :title "bar") current-backend).  This function
could just return \parencite{foo} if exporting to latex and the citation
was already in a bibtex file.  But it could also just return “Foo 2000”
as a static string for dumb backends like ASCII, or write the
information to a temporary bibtex file (so that latex can atomatically
use the bibliographic info looked up from a DOI citation).

In any event, this is a big, complicated project.  Step zero for me (and
many people, I guess) is to get a slightly less hackish way to export
Bibtex-based citations to latex, and the other pieces can be built on
top of that.

-- 
Aaron Ecay

Re: org-exp-bibtex missing in git?

[Rasmus]

Aaron,

>>   2. Citation selection should be possible via Reftex.
>
> In principle this is true, but I think RefTeX is deeply intertwined with
> the assumption that it is running in a LaTeX buffer.  Going through its
> code and making it major-mode-agnostic is a worthy project all of its
> own.  But it might take less effort and be more long-run maintainable to
> just wire up the bibtex.el bundled with emacs, CompletionUI
> (http://www.emacswiki.org/CompletionUI) and YAsnippet
> (http://emacswiki.org/emacs/Yasnippet).

These are not shipped with Emacs.  Reftex is.  I don't know how big of
a project it would be to adapt Reftex.

This is what I use for selecting entries.  Admittedly, it's 'hackish'.

#+BEGIN_SRC emacs-lisp

(defun org-mode-reftex-setup ()
  (load-library "reftex")
  (and (buffer-file-name)
       (file-exists-p (buffer-file-name))
       (reftex-parse-all))
  (make-local-variable 'reftex-cite-format)
  (setq reftex-cite-format 'org)
  (define-key org-mode-map (kbd "C-c )") 'reftex-citation))

(add-hook 'org-mode-hook 'org-mode-reftex-setup)


(eval-after-load 'reftex-vars
  '(progn
     (add-to-list 'reftex-cite-format-builtin
                  '(org "Org-mode citation"
                        ((?\C-m . "[[cite:%l]]")
                         (?t . "[[textcite:%l]]")
                         (?p . "[[parencite:%l]]")
                         (?s . "[[citepos:%l]]")
                         (?a . "[[citeauthor:%l]]")
                         (?y . "[[citeyear:%l]]")
                         (?n . "%l")
                         ;; the following depends on org-link-search-must-match-exact-headline
                         (?o . "[[file:~/documents/literature/lit.org::*%t][%2a (%y). %T]]"))))))

#+END_SRC


>>   3. It should look nice in the buffer.  [...]
>
> One could do this with font-lock and the new citation syntax I proposed
> in my other email.  We would need two alists.  One would pair citation
> lookup types with functions to resolve them to a location, and to get
> their properties.  The other would pair display types with two
> functions: one to return a format string that would be displayed by
> font-lock instead of the citation markup, and one to return the code to
> export the citation.

> So, a citation like [cite:doi:parens:some-doi:key=val&key2=val2] would be
> displayed by:
> 1. call (org-lookup-cite-doi "some-doi") -> (:author "Foo" :title "bar" ...)
> 2. call (org-display-cite-parens '(:author "Foo" :title "bar" ...)) ->
>    "(Foo 2000)"
> 3. (font-lock puts an overlay over the citation markup, with the
>    returned string)

Looks nice. 

> If you click on the citation, org would open the location (URL or local
> file) returned by (org-resolve-cite-doi "some-doi")

Yeah, I that aspect of url'ing is nice, I agree.

> A citation could exported by calling (org-export-cite-parens 'doi
> "some-doi" (:author "foo" :title "bar") current-backend).  This function
> could just return \parencite{foo} if exporting to latex and the citation
> was already in a bibtex file.  But it could also just return “Foo 2000”
> as a static string for dumb backends like ASCII, or write the
> information to a temporary bibtex file (so that latex can atomatically
> use the bibliographic info looked up from a DOI citation).

That also sounds nice.  Reftex provide many ways to format strings
which could be useful for ASCII backend, say, but perhaps it's too
tied to LaTeX, as you suggest above.

> In any event, this is a big, complicated project.  Step zero for me (and
> many people, I guess) is to get a slightly less hackish way to export
> Bibtex-based citations to latex, and the other pieces can be built on
> top of that.

If such a project is undertaken it should, however, be done right, I
am sure we would agree. Making citation "first class citizens" would
be a first step IMO.

Cheers,
Rasmus

-- 
If you can mix business and politics wonderful things can happen!

Re: org-exp-bibtex missing in git?

[aaronecay]

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

Hello Bastien (et al),

2013ko martxoak 7an, Bastien-ek idatzi zuen:
> 
> Hi Nicolas,
> 
> I like Aaron's idea (maybe others proposed this too) of having
> parameters in links:
> 
> [[file:my.bib::key&&prenote=my prenote&&postnote=my postnote]]
> 
> [[http://perdu.com&&title=You're lost?]]
> 
> This is orthogonal to my proposal of extending #+LINK to be able
> to define new protocols (by allowing to add a follow and an export
> functions); and this is orthogonal to whether link abbrevs can have
> more than one formatting string %s.
> 
> We would just need to pass the parameters as keywords to the export
> function, either the default one, either the defined by the protocol.
> 
> E.g., the first link would be represented by the parser like this:
> 
>    (:type "file"
>     :path "my.bib"
>     :raw-link "file:orgmode.org::test2"
>     :application nil
>     :search-option "test2"
>     :parameters '(:title "You're lost")
>     :begin 63
>     :end 97
>     :contents-begin 90
>     :contents-end 95
>     :post-blank 0
>     :parent #3)

This is now implemented, in the first of three patches attached to this
email.  The second patch is a reworked version of the bibliography
support in my last patch, and the third implements link attributes for
HTML links.

To Nicolas:

> I think that if we ever implement a bibliography/citations handlers,
> they should be first class objects in Org syntax (like footnotes).
> Overloading link syntax would, IMO, be wrong in that case.

Do you have a proposal for how this syntax would look?  You certainly
know the parser very well, so you probably have an idea of what will
work and not conflict with other things.  I think minimally we need
to include info on:
- how to look up the citation (DOI, arXiv id, in a bibtex file, ...)
- how to display/export the citation (parens, footnote, in-text, ...)
- a list of properties (incl. at least pre- and post-note)
- (of course) the citation key

So maybe:

[cite:lookup-type:display-type:key:prop1=val1,prop2=val2]

Alternatively, the lookup-type and display-type could just be made
properties, as long as there is a clear notion of what the default for
these should be.


[-- Attachment #2: 0001-Add-support-for-link-properties.patch --]
[-- Type: text/x-patch, Size: 5597 bytes --]

From 69e7a98a2f8044362597de31789b43b955e1fc7a Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Fri, 8 Mar 2013 13:31:38 -0500
Subject: [PATCH 1/3] Add support for link properties
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-element.el (org-element-link-parser): include :properties in
  plist of parsed link
* lisp/org.el (org-make-link-string): don’t escape properties
* lisp/ox-html.el (org-html-link)
  lisp/ox-latex.el (org-latex-link): pass link properties to
  org-link-protocols functions

The properties of a link are appended to the link path, separated by the
string “&&”.  Each property should have the form key=val.  No escaping
is applied to key or val, and they must not contain an “=” character.

The properties of a link are passed as the optional fourth argument to
export functions defined by org-add-link-type and
org-link-protocols.  (Currently only for the HTML and LaTeX backends).
---
 lisp/org-element.el | 18 ++++++++++++++----
 lisp/org.el         | 15 +++++++++------
 lisp/ox-html.el     |  3 ++-
 lisp/ox-latex.el    |  3 ++-
 4 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 6810b98..b944ffd 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -2982,7 +2982,7 @@ Assume point is at the beginning of the link."
   (save-excursion
     (let ((begin (point))
 	  end contents-begin contents-end link-end post-blank path type
-	  raw-link link search-option application)
+	  raw-link link search-option application properties)
       (cond
        ;; Type 1: Text targeted from a radio target.
        ((and org-target-link-regexp (looking-at org-target-link-regexp))
@@ -2998,9 +2998,18 @@ Assume point is at the beginning of the link."
 	      ;; abbreviation in it.
 	      raw-link (org-translate-link
 			(org-link-expand-abbrev
-			 (org-match-string-no-properties 1)))
-	      link (org-link-unescape raw-link))
-	;; Determine TYPE of link and set PATH accordingly.
+			 (org-match-string-no-properties 1))))
+	(when (string-match "&&" raw-link)
+	  (let ((components (split-string raw-link "&&"))
+		p)
+	    (setq raw-link (nth 0 components))
+	    (dolist (prop (cdr components))
+	      (setq p (split-string prop "="))
+	      (setq properties (plist-put properties
+					  (intern (concat ":" (nth 0 p)))
+					  (nth 1 p))))))
+        (setq link (org-link-unescape raw-link))
+        ;; Determine TYPE of link and set PATH accordingly.
 	(cond
 	 ;; File type.
 	 ((or (file-name-absolute-p link) (string-match "^\\.\\.?/" link))
@@ -3058,6 +3067,7 @@ Assume point is at the beginning of the link."
 		  :raw-link (or raw-link path)
 		  :application application
 		  :search-option search-option
+		  :properties properties
 		  :begin begin
 		  :end end
 		  :contents-begin contents-begin
diff --git a/lisp/org.el b/lisp/org.el
index 811506a..5611adb 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -9449,12 +9449,15 @@ according to FMT (default from `org-email-link-description-format')."
 	     (not (string-match (org-image-file-name-regexp) link))
 	     (not (equal link (org-link-escape link))))
     (setq description (org-extract-attributes link)))
-  (setq link
-	(cond ((string-match (org-image-file-name-regexp) link) link)
-	      ((string-match org-link-types-re link)
-	       (concat (match-string 1 link)
-		       (org-link-escape (substring link (match-end 1)))))
-	      (t (org-link-escape link))))
+  (let ((parts (split-string link "&&")))
+    (setq link (nth 0 parts))
+    (setq link
+	  (cond ((string-match (org-image-file-name-regexp) link) link)
+		((string-match org-link-types-re link)
+		 (concat (match-string 1 link)
+			 (org-link-escape (substring link (match-end 1)))))
+		(t (org-link-escape link))))
+    (setq link (mapconcat #'identity (cons link (cdr parts)) "&&")))
   (concat "[[" link "]"
 	  (if description (concat "[" description "]") "")
 	  "]"))
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 829fe28..9d5fdc7 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2630,7 +2630,8 @@ INFO is a plist holding contextual information.  See
 			(org-export-resolve-coderef path info)))))
      ;; Link type is handled by a special function.
      ((functionp (setq protocol (nth 2 (assoc type org-link-protocols))))
-      (funcall protocol (org-link-unescape path) desc 'html))
+      (funcall protocol (org-link-unescape path) desc
+               'html (org-element-property :properties link)))
      ;; External link with a description part.
      ((and path desc) (format "<a href=\"%s\"%s>%s</a>" path attributes desc))
      ;; External link without a description part.
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index d17dd60..a1cacf0 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1948,7 +1948,8 @@ INFO is a plist holding contextual information.  See
 	      (org-export-resolve-coderef path info)))
      ;; Link type is handled by a special function.
      ((functionp (setq protocol (nth 2 (assoc type org-link-protocols))))
-      (funcall protocol (org-link-unescape path) desc 'latex))
+      (funcall protocol (org-link-unescape path) desc
+               'latex (org-element-property link :properties)))
      ;; External link with a description part.
      ((and path desc) (format "\\href{%s}{%s}" path desc))
      ;; External link without a description part.
-- 
1.8.1.5


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Support-bibliographies-for-export.patch --]
[-- Type: text/x-patch, Size: 5216 bytes --]

From 6428103e7199acbf947cacaa5860ac39b3b78b46 Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Fri, 8 Mar 2013 13:41:00 -0500
Subject: [PATCH 2/3] Support bibliographies for export

* lisp/ox.el (org-export-options-alist): Add BIBLIOGRAPHY
* lisp/ox-latex.el (org-latex-template): Support bibliographies
* lisp/ox-bib.el: Add file

Add export support for bibliographies.  Currently only works for
BibLaTeX, using the latex backend.  To use, put
#+BIBLIOGRAPHY: file.bib
in the header of the document, and (require 'ox-bib).  Then use
links of the form:
[[textcite:bibtex-key&&pre=foo&&post=bar][whatever]]
which will be exported to:
\textcite[foo][bar]{bibtex-key}
Using parencite as a link type is also supported.

The BIBLIOGRAPHY keyword in the header will be translated to an
appropriate \addbibresource command.
---
 lisp/ox-bib.el   | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lisp/ox-latex.el |  8 +++++
 lisp/ox.el       |  1 +
 3 files changed, 98 insertions(+)
 create mode 100644 lisp/ox-bib.el

diff --git a/lisp/ox-bib.el b/lisp/ox-bib.el
new file mode 100644
index 0000000..a3f9de9
--- /dev/null
+++ b/lisp/ox-bib.el
@@ -0,0 +1,89 @@
+(require 'bibtex)
+(require 'ox)
+
+(defvar ox-bib-find-entries-in-org-file nil
+  "Whether to look for bibliogrpahy entries in an org mode file
+or a bibtex file.")
+
+(defun ox-bib-get-bibliography ()
+  (mapcar (lambda (s)
+            (org-no-properties s))
+	  ;; Don't explode if before the first headline
+          (or
+           (condition-case nil
+               (plist-get (org-export-get-environment nil t) :bibliography)
+             (error nil))
+           (save-excursion
+             (widen)
+             (goto-char (point-min))
+             (plist-get (org-export-get-environment) :bibliography)))))
+
+;; Adapted from org-find-entry-with-custom-id; there might be a better
+;; way to do this
+(defun org-find-entry-with-custom-id (ident)
+  (let ((id ident)
+        (case-fold-search nil))
+    (save-excursion
+      (save-restriction
+        (widen)
+        (goto-char (point-min))
+        (when (re-search-forward
+               (concat "^[ \t]*:CUSTOM_ID:[ \t]+" (regexp-quote id) "[ \t]*$")
+               nil t)
+          (org-back-to-heading t)
+          (point))))))
+
+(defun ox-bib-cite-follow (path)
+  (let* ((files (ox-bib-get-bibliography))
+	 (key (ox-bib-get-key path))
+	 file done)
+    (when ox-bib-find-entries-in-org-file
+      (setq files
+	    (mapcar (lambda (s)
+		      (replace-regexp-in-string "\\.bib\\'" ".org" s))
+		    files)))
+    (while (and (car-safe files) (not done))
+      (setq file (car-safe files))
+      (when (file-exists-p file)
+        (let* ((buf (find-file-noselect file))
+
+	       (pos (with-current-buffer buf
+		      (cond
+		       (ox-bib-find-entries-in-org-file
+			(org-find-entry-with-custom-id key))
+		       (t (bibtex-search-entry key))))))
+	  (when pos
+	    (setq done (cons buf pos)))))
+      (setq files (cdr files)))
+    (if done
+	(progn
+          (pop-to-buffer (car done))
+	  (goto-char (cdr done))
+          (when ox-bib-find-entries-in-org-file
+            (org-show-context)))
+      (message "Citation not found: %s" key))))
+
+(defun ox-bib-textcite-export (path desc format &optional props)
+  (cond
+   ((org-export-derived-backend-p format 'latex)
+    (format "\\textcite[%s][%s]{%s}"
+	    (plist-get props :pre)
+	    (plist-get props :post)
+	    key))
+   (t
+    (format "[textcite to: %s]" path))))
+
+(defun ox-bib-parencite-export (path desc format &optional props)
+  (cond
+   ((org-export-derived-backend-p format 'latex)
+    (format "\\parencite[%s][%s]{%s}"
+            (plist-get props :pre)
+            (plist-get props :post)
+            key))
+   (t
+    (format "[parencite to: %s]" path))))
+
+(org-add-link-type "textcite" #'ox-bib-cite-follow #'ox-bib-textcite-export)
+(org-add-link-type "parencite" #'ox-bib-cite-follow #'ox-bib-parencite-export)
+
+(provide 'ox-bib)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a1cacf0..08cdd18 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1192,6 +1192,14 @@ holding export options."
 	       (or (plist-get info :description) "")
 	       (if (not (plist-get info :with-creator)) ""
 		 (plist-get info :creator))))
+     ;; Bibliography
+     (let* ((bibs (plist-get info :bibliography))
+            (bib-cmds (mapconcat (lambda (s)
+                                   (format "\\addbibresource{%s}" s))
+                                 bibs "\n")))
+       (if bibs
+	   (concat bib-cmds "\n")
+	 ""))
      ;; Document start.
      "\\begin{document}\n\n"
      ;; Title command.
diff --git a/lisp/ox.el b/lisp/ox.el
index 40c0617..f405eff 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -118,6 +118,7 @@
     (:select-tags "SELECT_TAGS" nil org-export-select-tags split)
     (:time-stamp-file nil "timestamp" org-export-time-stamp-file)
     (:title "TITLE" nil nil space)
+    (:bibliography "BIBLIOGRAPHY" nil nil split)
     (:with-archived-trees nil "arch" org-export-with-archived-trees)
     (:with-author nil "author" org-export-with-author)
     (:with-clocks nil "c" org-export-with-clocks)
-- 
1.8.1.5


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Support-properties-for-HTML-links.patch --]
[-- Type: text/x-patch, Size: 3402 bytes --]

From 8aaf0718e2d43195cc42ff9bbf2b0e0d6eff4bcf Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
Date: Fri, 8 Mar 2013 13:44:17 -0500
Subject: [PATCH 3/3] Support properties for HTML links

* lisp/ox-html.el (org-html-link--inline-image): use link properties in
  addition to ATTR_HTML ones
  (org-html--properties-to-attributes): new function
  (org-html-link): use link properties instead of ATTR_HTML ones

Link attributes of the form [[http://test.com/&&key=value]] will be
translated to <a href="http://test.com/" key="value"> upon export.  For
image links which are exported inline, the key="value" will be inserted
in the img tag.
---
 lisp/ox-html.el | 38 +++++++++++++++++++-------------------
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 9d5fdc7..fe2e10c 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -2405,7 +2405,8 @@ used as a communication channel."
 	 (parent (org-export-get-parent-element link))
 	 (caption (org-export-data (org-export-get-caption parent) info))
 	 (label (org-element-property :name parent))
-	 (attr (mapconcat #'identity (org-element-property :attr_html parent) " ")))
+	 (attr (concat (mapconcat #'identity (org-element-property :attr_html parent) " ")
+		       (org-html--properties-to-attributes (org-element-property :properties link)))))
     ;; Return proper string, depending on DISPOSITION.
     (org-html-format-inline-image
      path caption label attr (org-html-standalone-image-p link info))))
@@ -2454,6 +2455,20 @@ standalone images, do the following.
 			   (= (incf inline-image-count) 1)))
 			(t nil))))))))
 
+(defun org-html--properties-to-attributes (properties)
+  "Convert a plist of link properties to an HTML attribtes string.
+
+For a plist having the form (:key1 \"value1\" ...), returns a
+string of the form \"key1=\\\"value1\\\" ...\"."
+  (mapconcat #'identity
+             (loop for key in properties by 'cddr
+                   collect (concat " "
+                                   (substring (symbol-name key) 1)
+                                   "=\""
+                                   (plist-get properties key)
+                                   "\""))
+             ""))
+
 (defun org-html-link (link desc info)
   "Transcode a LINK object from Org to HTML.
 
@@ -2507,24 +2522,9 @@ INFO is a plist holding contextual information.  See
 					     (mapconcat 'number-to-string
 							numbers "-")))))))))
 	   (t raw-path)))
-	 attributes protocol)
-    ;; Extract attributes from parent's paragraph. HACK: Only do this
-    ;; for the first link in parent.  This is needed as long as
-    ;; attributes cannot be set on a per link basis.
-    (and (setq attributes
-	       (let ((parent (org-export-get-parent-element link)))
-		 (if (not (eq (org-element-map parent 'link 'identity info t)
-			      link))
-		     ""
-		   (mapconcat
-		    'identity
-		    (let ((att (org-element-property :attr_html parent)))
-		      (unless (and desc att
-				   (string-match (regexp-quote (car att)) desc))
-			att))
-		    " "))))
-	 (unless (string= attributes "")
-	   (setq attributes (concat " " attributes))))
+	 (properties (org-element-property :properties link))
+	 (attributes (org-html--properties-to-attributes properties))
+	 protocol)
     (cond
      ;; Image file.
      ((and (or (eq t org-html-inline-images)
-- 
1.8.1.5


[-- Attachment #5: Type: text/plain, Size: 17 bytes --]



-- 
Aaron Ecay

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Aaron,

aaronecay@gmail.com writes:

> This is now implemented, in the first of three patches attached to this
> email.  The second patch is a reworked version of the bibliography
> support in my last patch, and the third implements link attributes for
> HTML links.

This is great -- I'll be offline this week-end, so I won't have time 
to have a careful look before monday.  But I will.

Thanks!

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Aaron Ecay]

Hi Bastien,

2013ko martxoak 9an, Bastien-ek idatzi zuen:
> 
> This is great -- I'll be offline this week-end, so I won't have time 
> to have a careful look before monday.  But I will.

I hope this is not bothersome, but have you had a chance to look at
these patches?

I thought they would solve the problem in the thread at
http://thread.gmane.org/gmane.emacs.orgmode/68649 involving HTML image
width specifications, but I was mistaken.  Nonetheless, I think they are
useful for a sort of bare-bones LaTeX bibliographies, as well as solving
the problem of not being able to specify different ATTR_HTML lines for 2
links in the same paragraph.

Thanks,

-- 
Aaron Ecay

Re: org-exp-bibtex missing in git?

[Bastien]

Hi Aaron,

Aaron Ecay <aaronecay@gmail.com> writes:

> I hope this is not bothersome

... it is not, heads up are always welcome.

> but have you had a chance to look at these patches?

No -- and we are close to the release now, so let's not introduce
new syntax for this.  We still need to discuss this after Org 8.0,
as the functionality is indeed needed.

Feel free to raise it again then!  And thanks for those patches.

-- 
 Bastien

Re: org-exp-bibtex missing in git?

[Nicolas Goaziou]

Hello,

aaronecay@gmail.com writes:

>> I think that if we ever implement a bibliography/citations handlers,
>> they should be first class objects in Org syntax (like footnotes).
>> Overloading link syntax would, IMO, be wrong in that case.
>
> Do you have a proposal for how this syntax would look?  You certainly
> know the parser very well, so you probably have an idea of what will
> work and not conflict with other things.  I think minimally we need
> to include info on:
> - how to look up the citation (DOI, arXiv id, in a bibtex file, ...)
> - how to display/export the citation (parens, footnote, in-text, ...)
> - a list of properties (incl. at least pre- and post-note)
> - (of course) the citation key
>
> So maybe:
>
> [cite:lookup-type:display-type:key:prop1=val1,prop2=val2]

I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter
(link syntax) implies a (optional) description part. I don't think
a description is ever meaningful in citations.

Also, as I already mentioned, link syntax is already overloaded: there
are many types of links and the link transcoder function in export
back-ends is generally one of the most complicated to write (along with
tables).


Regards,

-- 
Nicolas Goaziou

Re: org-exp-bibtex missing in git?

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I favor [cite:PROPERTIES] over [[cite:PROPERTIES]], because the latter
> (link syntax) implies a (optional) description part. I don't think
> a description is ever meaningful in citations.

I have been holding on to this for a while.  Just typing it out as it
comes to my mind.

I favor the above syntax.  

I view Citations as closer to Footnotes.  The syntax should parallels
footnotes syntax.

1. PROPERTIES should be opaque to Org.  It is a key or a list of keys
   possibly bibtex but Org doesn't take stand on how it looks like.
   
2. There will be a org-BACKEND-citation-reference.
3. There will be a org-BACKEND-bibliography.

2, 3 more likely with interface with respective citation processor
(citation processor as opposed to a database) via CLI.  Citation
processor could be whatever org-exp-bibtex interfaces with right now.  I
also have some proof-of-concept - see zotcite - for zotero.

2, 3 will parallel footnote-reference and footnote-section callbacks in
HTML backend.

4. Footnotes can be introduced with either fn: prefix or cite: prefix.
   There should be a way to put fn: and cite: in same enumeration
   context.  There should be a way to put fn: and cite: in different
   enumeration context.  The former case could be a degenerate mode
   where Org can transcode what is seen in the buffer where everything
   is footnotes.  The latter case will result in Citations and
   Bibliography being generated by the above backend transcoders.

5. Citation definitions in Org buffer will be *ignored*.  (It could be
   considered when the exporter works in a degenerate footnote only mode
   where plain text transcoding is resorted to because there is no
   suitable application available for the backend format.)  Plain text
   citation definitions are only to help the author have a glimpse of
   what he is doing, it has only UI-value but no contents value.

6. There may be an advisory citation style - say APA, Chicago etc -
   which the backends may honor or ignore.

I am not clear about:

1. How multiple keys are to be handled.
2. What prenotes or postnotes mean.
3. Chicago note style etc.


I think the community should answer and articulate 1, 2, 3 clearly.
With my proposal, there could be some minor changes in Footnotes
normalization and some minor changes in existing transcoders.

The Org syntax for citations should *at this point* in time should NOT
make any assumptions about the Citation Database or the Citation
Application.  As far Org is concerned, there should be a way for Emacs
to interact with these engines and have them return Citation Refernece
and Citation Defintion contents in required backend format.

-- 

Re: org-exp-bibtex missing in git?

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Citation processor could be whatever org-exp-bibtex interfaces with
> right now.  I also have some proof-of-concept - see zotcite - for
> zotero.

I have a proof-of-concept on how to use Jabref to get citations in to
ODT export.  I will share a recipe sometime (when it will happen I
cannot say, my muse should sit with me.)

My proposal may sound abstract but I do have some prototype that
validates the simplicity and practicality of my suggestions.  It will
also minimize Nicolas efforts - Get the cite key but don't bother about
grokking it for good.

Re: org-exp-bibtex missing in git?

[Thomas S. Dye]

Jambunathan K <kjambunathan@gmail.com> writes:

>
> I am not clear about:
>
> 1. How multiple keys are to be handled.
> 2. What prenotes or postnotes mean.
> 3. Chicago note style etc.
>
>
> I think the community should answer and articulate 1, 2, 3 clearly.
> With my proposal, there could be some minor changes in Footnotes
> normalization and some minor changes in existing transcoders.

1. One approach to multiple keys is "qualified citation lists", see
section 3.7.3 of _The biblatex Package Programmable Bibliographies and
Citations by Philipp Lehman_ (`texdoc biblatex' on my Mac).

2. (see Lehman 2012:92 for an explanation of prenotes and postnotes).
    ^^^                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  prenote               postnote

3. BibLaTeX ships with several standard styles, which can be used as
starting points for writing specific styles required by publishers.  See
section 3.3 of the BibLaTeX manual.  For an idea of what it takes to
support the Chicago style, please see the 129 page manual for the
biblatex-chicago style (http://www.ctan.org/pkg/biblatex-chicago).  This
package supports both the "author-date" system used in the sciences and
the "notes & bibliography" system used in the humanities.  (Jambunathan,
for your reference, the paper I sent you uses the "notes & bibliography"
system--it was written in Org-mode and formatted with LaTeX and BibLaTeX.)

We use the Chicago Manual of Style at work and the BibTeX approximation
of the Chicago bibliography and reference styles.  I looked at
biblatex-chicago several years ago and had to let it go because of the
heavy data requirements.  In particular, the changes needed for the .bib
database broke other styles that we thought we might use.  Apparently,
it's not possible to design a data table that supports all the
bibliography styles that one might want to use.

hth,
Tom


-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-exp-bibtex missing in git?

[Jambunathan K]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> \footfullcite[prenote][postnote]{key}

What would prenote and postnote typically contain.  Where would they
appear in the exported document - In the citation reference or in the
citation definition.  Can the same key have different pre-note and
post-note attached to it.

I see "Note"s in Chicago-related style.  Do these notes have anything to
do with Chicago stuff.

ps: I believe different faculties - by faculties I mean science,
humanities, engineering, law etc. - have their own "preferred" citation
style.  So for the sake of discussion and finalizing the overall
spec. it would be beneficial if people can circulate what styles they
use and how it looks in the print format - journal or book.  Sticking to
LaTeX (alone) will only result it LaTeX only solution but not a
cross-backend solution (A cross-backend solution is what Nicolas seems
to be proposing right now.)

-- 

Re: org-exp-bibtex missing in git?

[Andreas Leha]

Jambunathan K <kjambunathan@gmail.com> writes:

> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> \footfullcite[prenote][postnote]{key}
>
> What would prenote and postnote typically contain.  Where would they
> appear in the exported document - In the citation reference or in the
> citation definition.  Can the same key have different pre-note and
> post-note attached to it.
>

I was away for a few days.  By now, this is nicely addressed -- not
necessarily targeted to footnotes -- by Tom in
http://permalink.gmane.org/gmane.emacs.orgmode/68056

[...]

- Andreas

Re: org-exp-bibtex missing in git?

[Vikas Rawal]

> 
> I do confirm.

Thank you. I have been trying to migrate to the new-exporter. I have
not had much success so far but I hope to be able to figure it all out
soon. Since we do not yet have a documentation, it is difficult.
Nicolas has been very kind with help.

I have a website that is built using old exporter. It used
org-exp-bibtex. I will move it to the new exporter, and if there is a
problem, get back to the mailing list.

Till then, thank you for your responses.

Best,

Vikas

Re: org-exp-bibtex missing in git?

[Suvayu Ali]

On Mon, Mar 04, 2013 at 10:10:37AM +0530, Vikas Rawal wrote:
> 
> I have a website that is built using old exporter. It used
> org-exp-bibtex. I will move it to the new exporter, and if there is a
> problem, get back to the mailing list.

I think people should be using maint instead of master for production
use.

-- 
Suvayu

Open source is the future. It sets us free.