* [PATCH] Allow regexps in org-file-apps to capture link parameters using groups
@ 2010-01-16 14:45 Jan Böcker
0 siblings, 0 replies; 5+ messages in thread
From: Jan Böcker @ 2010-01-16 14:45 UTC (permalink / raw)
To: Org Mode
What is this?
=============
This patch changes the way extension regexps in `org-file-apps' are
handled. Instead of against the file name, the regexps are now matched
against the whole link, and you can use grouping to extract link
parameters which you can then use in a command string to be executed.
For example, to allow linking to PDF files using the syntax
file:/doc.pdf::<page number>, you can add the following entry to
org-file-apps:
Extension: \.pdf::\([0-9]+\)\'
Command: evince "%s" -p %1
In a command string to be executed, the parameters can be referenced
using %1, %2, etc. Lisp forms can access them using (string-match n link).
Where to get it?
================
Either apply the patch by hand or
git pull git://github.com/jboecker/org-mode.git org-file-apps-parameters
What's next? / Feedback
=======================
- Find the bugs. Since this messes with links, a central concept of Org,
I probably have missed some edge cases; so please test this and
report if it works for you.
I also appreciate any feedback on code quality or the design decisions
made. I am learning elisp along the way, so you may be able to write
some changes in a more idiomatic and/or elegant way.
- Add a mechanism for org-mode modules to add default values to
org-file-apps, similar to the variables org-file-apps-defaults-*.
This could be used by modules to define their own extensions to the
syntax of file: links.
- Modify org-docview.el to use this and deprecate the docview: link syntax.
What does it (intentionally) break?
===================================
This patch introduces a backwards-incompatible change. If LINE or SEARCH
is given, the file is no longer guaranteed to open in emacs: if IN-EMACS
is nil and an entry in org-file-apps matches, that takes precedence.
A grep of the lisp/ and contrib/ directories showed that no code in the
org-mode distribution was relying on this behaviour; whereever LINE or
SEARCH is given, IN-EMACS is also set to t.
I decided against adding an additional parameter because that would be
redundant; the original link as seen by org-open-at-point can be
reconstructed from PATH, LINE and SEARCH.
I am not that sure if this is the right way to do this, but it seems to
break as little as possible while hopefully avoiding to add too much
complexity.
---
lisp/ChangeLog | 10 ++++++++++
lisp/org.el | 56
+++++++++++++++++++++++++++++++++++++++++++++-----------
2 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/lisp/ChangeLog b/lisp/ChangeLog
index 3f46f3c..c4605bd 100755
--- a/lisp/ChangeLog
+++ b/lisp/ChangeLog
@@ -1,3 +1,13 @@
+2010-01-16 Jan Böcker <jan.boecker@jboecker.de>
+
+ * org.el (org-open-file): Allow regular expressions in
+ org-file-apps to capture link parameters using groups. In a
+ command string to be executed, the parameters can be referenced
+ using %1, %2, etc. Lisp forms can access them using
+ (string-match n link).
+ (org-apps-regexp-alist): Adopt the created regexp, as this is now
+ matched against a file: link instead of the file name.
+
2010-01-16 Carsten Dominik <carsten.dominik@gmail.com>
* org.el (org-link-unescape, org-link-escape): Only use hexlify if
diff --git a/lisp/org.el b/lisp/org.el
index ee81c4d..2351419 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -1463,7 +1463,7 @@ you can use this variable to set the application
for a given file
extension. The entries in this list are cons cells where the car
identifies
files and the cdr the corresponding command. Possible values for the
file identifier are
- \"regex\" Regular expression matched against the file name. For
backward
+ \"regex\" Regular expression matched against the file: link. For
backward
compatibility, this can also be a string with only
alphanumeric
characters, which is then interpreted as an extension.
`directory' Matches a directory
@@ -1494,9 +1494,13 @@ Possible values for the command are:
does define this command, but you can overrule/replace it
here.
string A command to be executed by a shell; %s will be replaced
- by the path to the file.
+ by the path to the file. If the file identifier is a regex,
+ %n will be replaced by the match of the nth
subexpression (group).
sexp A Lisp form which will be evaluated. The file path will
- be available in the Lisp variable `file'.
+ be available in the Lisp variable `file', the link itself
+ in the Lisp variable `link'. If the file identifier is a
regex,
+ the original match data will be restored, so
subexpression matches
+ are accessible using (match-string n link).
For more examples, see the system specific constants
`org-file-apps-defaults-macosx'
`org-file-apps-defaults-windowsnt'
@@ -8935,10 +8939,12 @@ With a double C-c C-u prefix arg, Org tries to
avoid opening in Emacs
and to use an external application to visit the file.
Optional LINE specifies a line to go to, optional SEARCH a string to
-search for. If LINE or SEARCH is given, the file will always be
-opened in Emacs.
+search for. If LINE or SEARCH is given, but IN-EMACS is nil, it will
+be assumed that org-open-file was called to open a file: link, and the
+original link to match against org-file-apps will be reconstructed
+from PATH and whichever of LINE or SEARCH is given.
+
If the file does not exist, an error is thrown."
- (setq in-emacs (or in-emacs line search))
(let* ((file (if (equal path "")
buffer-file-name
(substitute-in-file-name (expand-file-name path))))
@@ -8950,10 +8956,19 @@ If the file does not exist, an error is thrown."
file))
(a-m-a-p (assq 'auto-mode apps))
(dfile (downcase file))
+ ;; reconstruct the original file: link from the PATH, LINE and SEARCH
args
+ (link (cond ((and (eq line nil)
+ (eq search nil))
+ file)
+ (line
+ (concat file "::" (number-to-string line)))
+ (search
+ (concat file "::" search))))
+ (dlink (downcase link))
(old-buffer (current-buffer))
(old-pos (point))
(old-mode major-mode)
- ext cmd)
+ ext cmd link-match-data)
(if (string-match "^.*\\.\\([a-zA-Z0-9]+\\.gz\\)$" dfile)
(setq ext (match-string 1 dfile))
(if (string-match "^.*\\.\\([a-zA-Z0-9]+\\)$" dfile)
@@ -8965,8 +8980,13 @@ If the file does not exist, an error is thrown."
(t
(setq cmd (or (and remp (cdr (assoc 'remote apps)))
(and dirp (cdr (assoc 'directory apps)))
- (assoc-default dfile (org-apps-regexp-alist apps a-m-a-p)
- 'string-match)
+ ;; if we find a match in org-file-apps, store the match data for
later
+ (let ((match (assoc-default dlink (org-apps-regexp-alist apps
a-m-a-p)
+ 'string-match)))
+ (if match
+ (progn (setq link-match-data (match-data))
+ match)
+ nil))
(cdr (assoc ext apps))
(cdr (assoc t apps))))))
(when (eq cmd 'system)
@@ -8996,6 +9016,18 @@ If the file does not exist, an error is thrown."
(shell-quote-argument
(convert-standard-filename file)))
t t cmd)))
+ ;; Replace "%1", "%2" etc. in the command with group matches from
the regex
+ (save-match-data
+ (let ((match-index 1)
+ (number-of-groups (- (/ (length link-match-data) 2) 1)))
+ (set-match-data link-match-data)
+ (while (<= match-index number-of-groups)
+ (let ((regex (concat "%" (number-to-string match-index)))
+ (replace-with (match-string match-index dlink)))
+ (while (string-match regex cmd)
+ (setq cmd (replace-match replace-with t t cmd))))
+ (setq match-index (+ match-index 1)))))
+
(save-window-excursion
(start-process-shell-command cmd nil cmd)
(and (boundp 'org-wait) (numberp org-wait) (sit-for org-wait))
@@ -9008,7 +9040,9 @@ If the file does not exist, an error is thrown."
(if search (org-link-search search))))
((consp cmd)
(let ((file (convert-standard-filename file)))
- (eval cmd)))
+ (save-match-data
+ (set-match-data link-match-data)
+ (eval cmd))))
(t (funcall (cdr (assq 'file org-link-frame-setup)) file)))
(and (org-mode-p) (eq old-mode 'org-mode)
(or (not (equal old-buffer (current-buffer)))
@@ -9038,7 +9072,7 @@ be opened in Emacs."
nil
(if (string-match "\\W" (car x))
x
- (cons (concat "\\." (car x) "\\'") (cdr x)))))
+ (cons (concat "\\." (car x) "\\(::.*\\)?\\'") (cdr x)))))
list))
(if add-auto-mode
(mapcar (lambda (x) (cons (car x) 'emacs)) auto-mode-alist))))
--
1.6.6
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups
[not found] ` <4BA630AD.1080901@jboecker.de>
@ 2010-03-21 17:13 ` Carsten Dominik
2010-04-05 0:33 ` Luke Amdor
0 siblings, 1 reply; 5+ messages in thread
From: Carsten Dominik @ 2010-03-21 17:13 UTC (permalink / raw)
To: Jan Böcker; +Cc: org-mode Mode
Hi Jan,
I have now applied this patch.
Hi everyone,
I am not sure if I completely understood every part of it, so if
anyone finds strange behavior of links, make sure to report it so
that we (Jan, that is :-) gets a chance to fix it.
Thanks!
- Carsten
On Mar 21, 2010, at 3:43 PM, Jan Böcker wrote:
> On 20.03.2010 16:07, Carsten Dominik wrote:
>> Hi Jan,
>>
>> I forgot what the last status of this thread was. Could you please
>> remind me?
>>
>> Thanks.
>>
>> - Carsten
>>
>
> Hi Carsten,
>
> The patch is ready to be applied. I have been using it since January
> 16
> without any problems.
> As mentioned in the description, it does introduce a
> backwards-incompatible change, but I know of no existing code which
> depends on the old behavior.
>
> However, I noticed an error in the docstrings and commit message: in
> several places where it says "(string-match n link)", it should say
> "(match-string n link)".
> I have attached a fixed version, which is also available via:
> git pull http://github.com/jboecker/org-mode.git for-carsten
>
> The motivation for this patch went something like this:
> - I wanted to link to PDFs, so I wrote org-docview.el
> - Someone pointed out that docview links did not respect
> org-link-file-path-type, which I fixed
> - Daniel M. German started integrating evince and xournal with
> org-protocol and asked if there was a link syntax to link to a
> specific
> page of a PDF (there were docview: links, but these are hard-coded to
> open within emacs)
> - I realized that docview: links are/should be a special case of file:
> links, so I wrote this patch
>
>> On Jan 27, 2010, at 10:29 AM, Jan Böcker wrote:
>>>
>>> Btw, since posting the patch I stumbled upon another disadvantage:
>>> 'extended' link types defined this way will only support
>>> autocompletion
>>> for the file name, i.e. you will not be prompted for a page number
>>> when
>>> entering a link using C-c C-l file <RET>, then specifying the path
>>> to
>>> some PDF file.
>
> I do no longer count this as a reason against this patch, because
> normal
> file: links do not prompt you for a line number, either, and you
> should
> not be typing in links by hand anyway most of the time.
>
>>> A better way to extend file links might be to make it easy to
>>> create new
>>> links with "file" behaviour, instead of applying this patch (so a
>>> pdf
>>> link would look like file+pdf:/document.pdf::4, and because the link
>>> type starts with "file+", it will e.g. respect org-link-file-path-
>>> type
>>> automatically).
>>> What do you think?
>
> Because I no longer care about prompting for a page number, I no
> longer
> care about this crazy idea of mine, too. Please go ahead and apply the
> patch in its current state.
>
>>> Unfortunately, I won't have much time for programming for about a
>>> month
>>> due to exams.
>
> This has also changed, I passed all three :)
> Now that I again have time to code and Daniel M German's patches to
> xournal and evince are functional, my next steps will be the two
> things
> mentioned under "What's next?" in the initial patch description.
>
> If you have any further questions, just ask!
> - Jan
>
>
> PS:
> On 27.01.2010 11:53, Carsten Dominik wrote:
>> It is in my list, and I will get to it....
> When the author of org-mode says it's on his list, you know he will
> come
> back to it and you don't have to add it to yours :)
> <0001-Allow-regexps-in-org-file-apps-to-capture-link-param.patch>
- Carsten
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups
2010-03-21 17:13 ` [PATCH] Allow regexps in org-file-apps to capture link parameters using groups Carsten Dominik
@ 2010-04-05 0:33 ` Luke Amdor
2010-04-05 10:07 ` Jan Böcker
0 siblings, 1 reply; 5+ messages in thread
From: Luke Amdor @ 2010-04-05 0:33 UTC (permalink / raw)
To: Carsten Dominik; +Cc: org-mode Mode
[-- Attachment #1.1: Type: text/plain, Size: 4373 bytes --]
Hi guys, I believe I found one little thing that this patch broke. That is
linking to either a text search or heading search in a different org file.
I've attached two files which illustrate this. The first file
test.orgcontains a link to a heading search of "* Hello" in the other
file (
other.org). Let me know if you need any more information. Thanks.
Luke
On Sun, Mar 21, 2010 at 12:13 PM, Carsten Dominik <carsten.dominik@gmail.com
> wrote:
> Hi Jan,
>
> I have now applied this patch.
>
> Hi everyone,
>
> I am not sure if I completely understood every part of it, so if
> anyone finds strange behavior of links, make sure to report it so
> that we (Jan, that is :-) gets a chance to fix it.
>
> Thanks!
>
> - Carsten
>
> On Mar 21, 2010, at 3:43 PM, Jan Böcker wrote:
>
> On 20.03.2010 16:07, Carsten Dominik wrote:
>>
>>> Hi Jan,
>>>
>>> I forgot what the last status of this thread was. Could you please
>>> remind me?
>>>
>>> Thanks.
>>>
>>> - Carsten
>>>
>>>
>> Hi Carsten,
>>
>> The patch is ready to be applied. I have been using it since January 16
>> without any problems.
>> As mentioned in the description, it does introduce a
>> backwards-incompatible change, but I know of no existing code which
>> depends on the old behavior.
>>
>> However, I noticed an error in the docstrings and commit message: in
>> several places where it says "(string-match n link)", it should say
>> "(match-string n link)".
>> I have attached a fixed version, which is also available via:
>> git pull http://github.com/jboecker/org-mode.git for-carsten
>>
>> The motivation for this patch went something like this:
>> - I wanted to link to PDFs, so I wrote org-docview.el
>> - Someone pointed out that docview links did not respect
>> org-link-file-path-type, which I fixed
>> - Daniel M. German started integrating evince and xournal with
>> org-protocol and asked if there was a link syntax to link to a specific
>> page of a PDF (there were docview: links, but these are hard-coded to
>> open within emacs)
>> - I realized that docview: links are/should be a special case of file:
>> links, so I wrote this patch
>>
>> On Jan 27, 2010, at 10:29 AM, Jan Böcker wrote:
>>>
>>>>
>>>> Btw, since posting the patch I stumbled upon another disadvantage:
>>>> 'extended' link types defined this way will only support autocompletion
>>>> for the file name, i.e. you will not be prompted for a page number when
>>>> entering a link using C-c C-l file <RET>, then specifying the path to
>>>> some PDF file.
>>>>
>>>
>> I do no longer count this as a reason against this patch, because normal
>> file: links do not prompt you for a line number, either, and you should
>> not be typing in links by hand anyway most of the time.
>>
>> A better way to extend file links might be to make it easy to create new
>>>> links with "file" behaviour, instead of applying this patch (so a pdf
>>>> link would look like file+pdf:/document.pdf::4, and because the link
>>>> type starts with "file+", it will e.g. respect org-link-file-path-type
>>>> automatically).
>>>> What do you think?
>>>>
>>>
>> Because I no longer care about prompting for a page number, I no longer
>> care about this crazy idea of mine, too. Please go ahead and apply the
>> patch in its current state.
>>
>> Unfortunately, I won't have much time for programming for about a month
>>>> due to exams.
>>>>
>>>
>> This has also changed, I passed all three :)
>> Now that I again have time to code and Daniel M German's patches to
>> xournal and evince are functional, my next steps will be the two things
>> mentioned under "What's next?" in the initial patch description.
>>
>> If you have any further questions, just ask!
>> - Jan
>>
>>
>> PS:
>> On 27.01.2010 11:53, Carsten Dominik wrote:
>>
>>> It is in my list, and I will get to it....
>>>
>> When the author of org-mode says it's on his list, you know he will come
>> back to it and you don't have to add it to yours :)
>> <0001-Allow-regexps-in-org-file-apps-to-capture-link-param.patch>
>>
>
> - Carsten
>
>
>
>
>
> _______________________________________________
> 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
>
[-- Attachment #1.2: Type: text/html, Size: 6148 bytes --]
[-- Attachment #2: test.org --]
[-- Type: application/octet-stream, Size: 52 bytes --]
* Something
* [[file:other.org::*One][jump to one]]
[-- Attachment #3: other.org --]
[-- Type: application/octet-stream, Size: 34 bytes --]
* Hello
*** One
*** Two
*** Three
[-- Attachment #4: Type: text/plain, Size: 201 bytes --]
_______________________________________________
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups
2010-04-05 0:33 ` Luke Amdor
@ 2010-04-05 10:07 ` Jan Böcker
2010-04-05 10:50 ` Jan Böcker
0 siblings, 1 reply; 5+ messages in thread
From: Jan Böcker @ 2010-04-05 10:07 UTC (permalink / raw)
To: Luke Amdor; +Cc: org-mode Mode, Carsten Dominik
On 05.04.2010 02:33, Luke Amdor wrote:
> Hi guys, I believe I found one little thing that this patch broke. That
> is linking to either a text search or heading search in a different org
> file. I've attached two files which illustrate this. The first file
> test.org <http://test.org> contains a link to a heading search of "*
> Hello" in the other file (other.org <http://other.org>). Let me know if
> you need any more information. Thanks.
>
> Luke
>
Hi Luke,
this works for me. I saved both files to ~/tmp/, opened test.org, and
pressed RET while the cursor was on the link. This brought the cursor to
the * One heading in other.org (the link was
[[file:other.org::*One][jump to one]] ).
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups
2010-04-05 10:07 ` Jan Böcker
@ 2010-04-05 10:50 ` Jan Böcker
0 siblings, 0 replies; 5+ messages in thread
From: Jan Böcker @ 2010-04-05 10:50 UTC (permalink / raw)
To: Luke Amdor; +Cc: org-mode Mode, Carsten Dominik
On 05.04.2010 12:07, Jan Böcker wrote:
> On 05.04.2010 02:33, Luke Amdor wrote:
>> Hi guys, I believe I found one little thing that this patch broke. That
>> is linking to either a text search or heading search in a different org
>> file. I've attached two files which illustrate this. The first file
>> test.org <http://test.org> contains a link to a heading search of "*
>> Hello" in the other file (other.org <http://other.org>). Let me know if
>> you need any more information. Thanks.
>>
>> Luke
>>
>
> Hi Luke,
>
> this works for me.
> [snip]
I have looked into this some more.
Take a look at the variable org-file-apps and check if there is any
entry that matches your link and tells Org not to visit it in emacs. The
patch may make it a little easier to break things by misconfiguring
org-file-apps.
If you cannot get it to work, please post the contents of your
org-file-apps variable and describe what exactly happens when you follow
the link in test.org (nothing at all? some error message? anything
helpful in the *Messages* buffer?).
HTH, Jan
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-04-05 10:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4B600794.4010008@jboecker.de>
[not found] ` <BCA64EB7-792D-4D90-86AE-BCD77F09A22F@gmail.com>
[not found] ` <4BA630AD.1080901@jboecker.de>
2010-03-21 17:13 ` [PATCH] Allow regexps in org-file-apps to capture link parameters using groups Carsten Dominik
2010-04-05 0:33 ` Luke Amdor
2010-04-05 10:07 ` Jan Böcker
2010-04-05 10:50 ` Jan Böcker
2010-01-16 14:45 Jan Böcker
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.