From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Maus Subject: Re: [babel] exports, caching, remote execution Date: Fri, 18 Jun 2010 17:35:39 +0200 Message-ID: <87wrtwpd4k.wl%dmaus@ictsoc.de> References: <87eig5en4p.fsf@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="===============1681394397==" Return-path: Received: from [140.186.70.92] (port=58680 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPdd9-0003TB-Q5 for emacs-orgmode@gnu.org; Fri, 18 Jun 2010 11:37:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPdd7-00047i-P1 for emacs-orgmode@gnu.org; Fri, 18 Jun 2010 11:37:19 -0400 Received: from mysql1.xlhost.de ([213.202.242.106]:39407) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPdd7-00046O-Gm for emacs-orgmode@gnu.org; Fri, 18 Jun 2010 11:37:17 -0400 In-Reply-To: <87eig5en4p.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Eric Schulte Cc: emacs-orgmode@gnu.org --===============1681394397== Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Fri_Jun_18_17:35:38_2010-1"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --pgp-sign-Multipart_Fri_Jun_18_17:35:38_2010-1 Content-Type: text/plain; charset=US-ASCII Eric Schulte wrote: >Is "scpc" in the line above a transport protocol? Maybe this should be >an org-mode wide features, i.e. the ability to resolve remote file >references with C-c C-o and on export. Does that sound reasonable, and >would it take care of the need in this particular case? I've created two IDEA issue in the issue file for this and another operation on links especially during export: Link resolving and link dereferencing. Just out of my head without many thoughs about how to implement: 1. Following the URI specs (RFC 3986) resolving and dereferencing means: "the process of determining an access mechanism and the appropriate parameters necessary to dereference a URI (sc. resolving, D.M.); this resolution may require several iterations. To use that access mechanism to perform an action on the URI's resource is to "dereference" the URI." (1.2.2) The basic idea is, that an Org mode link is a URI identifying a resource; upon export it might be necessary or desired to provide either an access mechanism suitable for the output format to access the entity referenced by the URI or another URI (see below). E.g.: An info reference to the Org mode manual [[info:org]] could be resolved to a web link [[http://orgmode.org/manual/]] when exporting to html. Resolving is already done for files when exporting to html: [[file:foo.baz]] is resolved to a relative web link, pointing to foo.baz. Dereferencing a link like [[file:/scpc:user@example.com:/users/home/user/test.png]] could or would hence be part of resolving a file link. It fetches the resource (test.png), puts it into current directory and returns a link suitable for the export context. Another example would be a hypothetical Org mode link type "rfc" that opens and stores links to RFCs using rfcview-mode. When exporting an Org mode document to html, the function `org-rfc-resolve-link' is called and returns a web link pointing to a web resource of the RFC. When exporting to latex, the function `org-rfc-resolve-link' returns a link of type "bib" with the BibTeX key of the RFC (e.g. rfc:4287 -> bib:RFC4287), assuming that a reference to a RFC in a LaTeX document is a bibliographic reference. 2. To complete this way of link handling we require a third function: Link markup. An Org mode link handler may provide a markup-link function that takes the exporting context and the link and returns suitable markup of LINK in CONTEXT. E.g. the handler for BibTeX links provides the function `org-bib-markup-link' that returns proper markup of a bibliographic reference. In context of LaTeX export his would be a \cite command with the BibTeX key of the bib link (bib:RFC4287 -> \cite{4287}). 3. For the sake of Lispness and to avoid repeated parsing, we define a Lisp representation of an Org link to be: ((TYPE AI RESOURCE) . PROPS) Where - TYPE :: Is a symbol of the type ("scheme") of the link - RESOURCE :: Is the path or name of the referenced resource - AI :: Is t, if RESOURCE contains an authority, otherwise it is nil. Cf. RFC3986, 3.2; in the written representation of a URI the presence of an authority is indicated by the two slashes after the colon. - PROPS :: Is a property list of additional link properties (e.g. description) Examples: - [[http://orgmode.org/manual/][Org mode manual]] is represented as: ((http t "orgmode.org/manual/") . (:description "Org mode manual")) - [[info:org][Org mode manual]] is represented as ((info nil "org") . (:description "Org mode manual")) - [[file:foo/baz.org]] is represented as ((file nil "foo/baz.org")) Having this, resolving a link is modifying TYPE, RESOURCE and AI. E.g. ((file nil "foo/baz.org")) -> ((http nil "foo/baz.html")) ((file nil "/scp:user@example.com:/users/home/user/test.png")) -> ((file nil "test.png")) [dereferenced] -> ((http nil "test.png")) [finally resolved] 4. The question of how to actually resolve a link is up to the respective link handler and I am not sure how to provide easy customization of such a system. Comments are welcome, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmjena@jabber.org Email..... dmaus@ictsoc.de --pgp-sign-Multipart_Fri_Jun_18_17:35:38_2010-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EABEIAAYFAkwbkkoACgkQma24O1pEeOZ0SAEAh/QBoIxhs7V1xViDUEQ5ox/Z KQpZYylcyA4u9MdfR9MBAOXVty6B8ZOAln1TzeXsNFvnStQwhLbnkVIfg9SglIFo =jFta -----END PGP SIGNATURE----- --pgp-sign-Multipart_Fri_Jun_18_17:35:38_2010-1-- --===============1681394397== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode --===============1681394397==--