From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: org-exp-bibtex missing in git? Date: Thu, 7 Mar 2013 07:03:59 -0500 Message-ID: References: <20130303070635.GA12112@panahar> <87fw0cg42y.fsf@allisson.co> <87vc98be83.fsf@bzg.ath.cx> <87ehfwwgdd.fsf@gmail.com> <87ppzg2r05.fsf@med.uni-goettingen.de> <87ppzgusem.fsf@gmail.com> <87ppzcfy2e.fsf@med.uni-goettingen.de> <87lia0s7wi.fsf@bzg.ath.cx> <876213lqfk.fsf@gmail.com> <87wqtjo6h6.fsf@bzg.ath.cx> <876213laso.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:44495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDZYJ-00064j-76 for emacs-orgmode@gnu.org; Thu, 07 Mar 2013 07:04:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UDZYH-0003Ka-4T for emacs-orgmode@gnu.org; Thu, 07 Mar 2013 07:04:03 -0500 Received: from mail-qe0-f44.google.com ([209.85.128.44]:39807) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UDZYH-0003KV-13 for emacs-orgmode@gnu.org; Thu, 07 Mar 2013 07:04:01 -0500 Received: by mail-qe0-f44.google.com with SMTP id x7so198112qeu.3 for ; Thu, 07 Mar 2013 04:04:00 -0800 (PST) In-Reply-To: <876213laso.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: Andreas Leha , emacs-orgmode@gnu.org Hi Bastien, On Thu, Mar 7, 2013 at 6:16 AM, Bastien 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