From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: RFC: Syntax for page numbers in file: links? Date: Wed, 6 Jan 2010 10:05:27 +0100 Message-ID: References: <4B3FE803.6090400@jboecker.de> <08E7D2DE-403D-4273-B88E-F87F8291C548@gmail.com> <4B437177.8060607@jboecker.de> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSSP6-0001e9-Se for emacs-orgmode@gnu.org; Wed, 06 Jan 2010 04:42:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSSP2-0001dK-AG for emacs-orgmode@gnu.org; Wed, 06 Jan 2010 04:42:12 -0500 Received: from [199.232.76.173] (port=40538 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSSP2-0001dH-3h for emacs-orgmode@gnu.org; Wed, 06 Jan 2010 04:42:08 -0500 Received: from mail-ew0-f224.google.com ([209.85.219.224]:42310) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSSP1-00050A-Mw for emacs-orgmode@gnu.org; Wed, 06 Jan 2010 04:42:07 -0500 Received: by mail-ew0-f224.google.com with SMTP id 24so20149286ewy.26 for ; Wed, 06 Jan 2010 01:42:07 -0800 (PST) In-Reply-To: <4B437177.8060607@jboecker.de> 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: =?ISO-8859-1?Q?Jan_B=F6cker?= Cc: Org Mode Hi Jan, I don't think this will make it into 6.34, so we can relax a bit - in particular also because I am currently not updating the Emacs distribution - it is in feature freeze. Would you like to work on a patch that allows interpreting page numbers for external applications? - Carsten On Jan 5, 2010, at 6:05 PM, Jan B=F6cker wrote: >> I am not sure if it makes sense to handle more that a page number, =20= >> really. > > I have thought about this again and concluded that the approach in my > first post is, indeed, over-engineered. I also believe the approach > proposed in this post to be flexible enough to handle some extensions. > > On 05.01.2010 13:32, Carsten Dominik wrote: > >> >> I have yesterday implemented modifies for file link: >> >> file+sys: now forces opening a file with the system's open command >> file+emacs: forces opening in Emacs. >> I guess it would make sense to make more of these, so that >> one could select a specific viewer for selected files, what >> do you think? > > The method of opening a file should not be specified in the link =20 > itself, > unless it makes sense to change it for an individual link. Imagine two > users exchanging org files, where one likes to open PDFs with evince =20= > and > the other prefers doc-view-mode. > > However, this would be useful for links to file types which org-mode > does not know anything about; the user would not have to tell org-mode > about them by modifying org-file-apps first. > Maybe this should not force the opening method, but provide the =20 > default > if org-file-apps has nothing to say? > > >>> >>> - org-file-apps should allow to specify how to pass a page number to >>> an external program. Unlike the file name, this is an optional >>> argument, as a link may not specify a page number at all. >>> >>> I do not know how to do this in an elegant way, maybe let >>> the user specify multiple entries - one for links with a page >>> number, one for links without. >> >> This is not easy at all, but I am sure it can be done. >> > > org-file-apps already allows matching regular expressions against the > file name. > I propose the following changes: > - match the regular expressions against the whole link > - if the matching regex used grouping, in addition to replacing %s =20 > with > the file name in a command string, replace %1 with the first match, %2 > with the second, etc. > - if the org-file-apps entry specifies a lisp form to be evaluated, =20= > make > the group matches available to the lisp form being evaluated. > > - org-docview.el would only handle org-store-link functionality and > generate links such as file:::. > > With these changes, the following sample entries in org-file-apps =20 > could > then specify the method of how to open links to PDF files with and > without page number specifications. > > Open PDFs in evince: > > regex: \.pdf\' > command: evince %s > > regex: \.pdf::\(\d+\)\' > command: evince %s -p %1 > > Open PDFs in doc-view-mode: > > regex: \.pdf\' > visit in emacs > > regex: \.pdf::\(\d+\)\' > lisp form: (progn (org-open-file file 1) > (docview-goto-page (match-string 1 link))) > > The lisp form in the last entry could go into org-docview.el as a > convenience function. We would also need a way for org-docview.el to > supply default entries for org-file-apps, maybe a variable > org-file-apps-defaults-alist or something. > > AFAIK, this approach would be backwards-compatible with current > org-file-apps entries, which typically match an extension at the end =20= > of > the string and specify a command to open the file with, which gets > passed the file name via %s. If the link specifies arguments, the > current entries would no longer match, but they cannot handle =20 > arguments > anyway. - Carsten