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 <[email protected]>
wrote:
> Bastien <[email protected]> writes:
>
> > Nicolas Goaziou <[email protected]> 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,
>
