Great! Thanks!

2 questions, though.

1. Previously, the type of the link was "thisfile", now it's "custom-id" and also, the leading hash is removed from the link. Let's consider the [[#about][About]] example once again. Previously, I was given ("thisfile" . "#about") and I changed this to ("thisfile" . "About"), which then worked like a charm. Now, I'm given ("custom-id" . "about"), which I don't know how I should translate. Neither of ("custom-id" . "About") or ("id" . "About") work. What should it be?

BTW, there's a line (require 'ord-id) in org-open-at-point function in master. Probably, it's a typo (should be (require 'org-id))

2. When those fixes will be available in MELPA?

--
Best regards,
Sergei Nosov

On Wed, Aug 19, 2015 at 4:28 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> I think `org-translate-link' should be updated to provide correct type,
>> including internal ones, to `org-link-translation-function'. E.g.,
>>
>> http://orgmode.org => "http"
>> #something => "custom-id"
>> (ref:line) => "coderef"
>> whatever => "fuzzy"
>>
>> At least, this would be consistent with the parser.
>
> Agreed.

Done. There is one foreseeable incompatible change however. When link
type is unknown to Org, it is reported as fuzzy, e.g.:

[[foobar:something]]

is seen as ("fuzzy" "foobar:something") by
`org-link-translation-function', not ("foobar" "something"), unless
"foobar" belong to `org-link-types'.

In practice I don't think it matters because
`org-link-translation-function' isn't meant to create new link types but
handle conflicting link types. In any case, in the example above, one
can always use

(when (and (string= type "fuzzy")
(string-match "\\(.*?\\):\\(.*\\)" path))
(cons (match-string 1) (match-string 2)))

in `org-link-translation-function'.

Regards,