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