emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: "Jan Böcker" <jan.boecker@jboecker.de>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: RFC: Syntax for page numbers in file: links?
Date: Wed, 6 Jan 2010 10:05:27 +0100	[thread overview]
Message-ID: <A76BCECA-E0D9-478B-BCB2-3FF561C73678@gmail.com> (raw)
In-Reply-To: <4B437177.8060607@jboecker.de>

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öcker wrote:

>> 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.

- Carsten

  reply	other threads:[~2010-01-06  9:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-03  0:42 RFC: Syntax for page numbers in file: links? Jan Böcker
2010-01-03 20:14 ` Samuel Wales
2010-01-05 12:32 ` Carsten Dominik
2010-01-05 17:05   ` Jan Böcker
2010-01-06  9:05     ` Carsten Dominik [this message]
2010-01-06 11:07       ` Jan Böcker
2010-01-06 11:08         ` Carsten Dominik
2010-01-07  1:24 ` Torsten Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=A76BCECA-E0D9-478B-BCB2-3FF561C73678@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=jan.boecker@jboecker.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).