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 wrote: > Bastien writes: > > > Nicolas Goaziou 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, >