I am not sure if it makes sense to handle more that a page number,
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
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
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
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
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,
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:<path>::<page>.
With these changes, the following sample entries in org-file-apps
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
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
arguments
anyway.