Hi and thanks for paying attention to my patch.

Bastien <bzg@altern.org> writes:

> I allowed myself to fix this, with a somewhat smaller patch:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?h=maint&id=14ffe2

This is indeed a good way to fix the uncaught error problem.

Nonetheless, the patch I provided was intended to also correct a
functional problem (to my mind) about the consistency of the behavior of
org-open-at-point relatively to plain links. Let me explain what I mean:

* First test: with bracket links

  Imagine you have the following line (I placed a _ to indicate
  the position of the cursor)

╭────
│  some non r_elevant text [[id:some-id]]
╰────

  Within that situation, launching org-open-at-point would follow the
  id:some-id link.

  In the following situation (with the cursor inside the link)

╭────
│  some non relevant text [[id:so_me-id]]
╰────

  org-open-at-point will also open the link. That one seems obvious but I
  think it is worth keeping in mind though.

* Second test: with plain links
  Now, imagine the same scenarios with plain links

╭────
│  some non relevant text id:so_me-id
╰────

  With the cursor inside the link, org-open-at-point follows the
  link. Then with the cursor before the link:

╭────
│  some non r_elevant text id:some-id
╰────

  org-open-at-point results in an error (now caught thanks to Bastien)
  while I (and I stress it is my personal opinion) think that it should
  also follow the link, like in the case of a bracket link.

As suggested by Nicolas, I provided tests in attachment to show the 4
use cases I just explained.

The initial patch I provided was meant to enhance the implementation of
org-open-at-point to make those use cases work.

What do you think? Should we enhance the function that way. I use the
patched version for some time now and I often launch org-open-at-point
(C-c C-o) before plain links.

Thanks again for your answers.

-- 
Konubinix
GPG Key    : 7439106A
Fingerprint: 5993 BE7A DA65 E2D9 06CE  5C36 75D2 3CED 7439 106A