Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups

Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups

[Carsten Dominik]

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

Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups

[Luke Amdor]

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

Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups

[Jan Böcker]

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

Re: Re: [PATCH] Allow regexps in org-file-apps to capture link parameters using groups

[Jan Böcker]

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