Regression: org-translate-link doesn't work correctly in Org 8.3

Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Hi!

I'm the maintainer of the toc-org (https://github.com/snosov1/toc-org)
package. With 8.3 I have noticed a regression in how org-translate-link
function works.

In this package, toc-org, I use org-link-translation-function variable to
make C-c C-o (org-open-at-point) work with GitHub-style links. To do this,
I set the aforementioned org-link-translation-function variable to a
function that translates GitHub-style links back to Org-style.

It was working fine in Org 8.2, but it doesn't work in Org 8.3.

I believe the root cause is the following. Here's the code of the
org-translate-link function:

(defun org-translate-link (s)
  "Translate a link string if a translation function has been defined."
  (if (and org-link-translation-function
  (fboundp org-link-translation-function)
  (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s))
      (progn
(setq s (funcall org-link-translation-function
(match-string 1 s) (match-string 2 s)))
(concat (car s) ":" (cdr s)))
    s))

Consider that we're trying to follow the link [[#about][About]]

In Org 8.2 org-translate-link function is called with s equal to
"thisfile:#about". So, (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
returns true and the call to the function stored in
org-link-translation-function follows.

In Org 8.3 org-translate-link function is called with s equal to simply
"#about" (no "thisfile:" in the beginning). Thus, the string-match call
NEVER succeeds (because there's no colon).

Please, let me know, what would be the solution to this issue.

--
Best regards,
       Sergei Nosov

[-- Attachment #2: Type: text/html, Size: 3832 bytes --]

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Bastien]

Hi Sergei,

wild guess: what if you simply make the ":" optional like this:

(string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)

(string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
                                 ^^^

?

-- 
 Bastien

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Hi Sergei,
>
> wild guess: what if you simply make the ":" optional like this:
>
> (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
>
> (string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
>                                  ^^^
>
> ?

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.

Regards,

-- 
Nicolas Goaziou

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

> wild guess: what if you simply make the ":" optional like this:

I believe, the preceding text should be made optional as well (i.e. +
should be *, like (string-match "\\([a-zA-Z0-9]*\\):?\\(.*\\)" s))

But anyway, it doesn't seem to work, because for some reason (I just
noticed this) - the org-translate-link function doesn't seem to be called
at all, when C-c C-o is executed. It is called only
in org-element-link-parser.

Also, org-translate-link tries to return the link in the "<type>:<link>"
format (exactly the way it expects the input parameter to be). So, simply
modifying the regexp shouldn't work because of this as well.

So, I suppose, something like what Nicolas suggests should be done about it
(i.e. providing the type and the link in the "new format").

Also, org-translate-link should probably be called somewhere
in org-open-at-point again.



--
Best regards,
       Sergei Nosov

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

> Hello,
>
> Bastien <bzg@gnu.org> writes:
>
> > Hi Sergei,
> >
> > wild guess: what if you simply make the ":" optional like this:
> >
> > (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)" s)
> >
> > (string-match "\\([a-zA-Z0-9]+\\):?\\(.*\\)" s)
> >                                  ^^^
> >
> > ?
>
> 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.
>
> Regards,
>
> --
> Nicolas Goaziou
>

[-- Attachment #2: Type: text/html, Size: 3891 bytes --]

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Bastien]

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.

-- 
 Bastien

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

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,

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4134 bytes --]

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

Sergei Nosov <sergei.nosov@gmail.com> writes:

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

What doesn't work? I.e., what is produced and what did you expect
instead?

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

Fixed. Thank you.

> 2. When those fixes will be available in MELPA?

IIUC MELPAe they should already be available.


Regards,

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Sergei Nosov]

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

> What doesn't work? I.e., what is produced and what did you expect
instead?
​
The jump via C-c C-o didn't work for me. But I figured it out in a
meanwhile - supposedly, what was previously called "thisfile" link type is
now called "fuzzy".​ Thanks.

> IIUC MELPAe they should already be available.

Sorry, I meant, Org ELPA (http://orgmode.org/elpa/) not MELPA (org is not
published on MELPA at all). The last published package seem to be
http://orgmode.org/elpa/org-20150817.tar which doesn't contain the fix. So,
my question is - when the next package (that contains the fix) will be
published? Or, alternatively, what's the Org policy for publishing new
packages to ELPA?


--
Best regards,
       Sergei Nosov

On Fri, Aug 21, 2015 at 3:11 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Sergei Nosov <sergei.nosov@gmail.com> writes:
>
> > 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?
>
> What doesn't work? I.e., what is produced and what did you expect
> instead?
>
> > 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))
>
> Fixed. Thank you.
>
> > 2. When those fixes will be available in MELPA?
>
> IIUC MELPAe they should already be available.
>
>
> Regards,
>

[-- Attachment #2: Type: text/html, Size: 3504 bytes --]

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Nicolas Goaziou]

Sergei Nosov <sergei.nosov@gmail.com> writes:

> The jump via C-c C-o didn't work for me. But I figured it out in a
> meanwhile - supposedly, what was previously called "thisfile" link type is
> now called "fuzzy".​ Thanks.

fuzzy are for text search, targets and NAME keywords. I'm not sure what
was the exact definition of "thisfile", since it doesn't appear in the
manual. However, I guess it encompassed custom-id, fuzzy, radio and
coderef link types.

> Sorry, I meant, Org ELPA (http://orgmode.org/elpa/) not MELPA (org is not
> published on MELPA at all). The last published package seem to be
> http://orgmode.org/elpa/org-20150817.tar which doesn't contain the fix. So,
> my question is - when the next package (that contains the fix) will be
> published? Or, alternatively, what's the Org policy for publishing new
> packages to ELPA?

I think Org ELPA's release is updated at least every week.

Regards,

Re: Regression: org-translate-link doesn't work correctly in Org 8.3

[Achim Gratz]

Nicolas Goaziou writes:
> I think Org ELPA's release is updated at least every week.


The last update was published with a wrong version number (that package
manager will not consider as an update) and no further updates will be
published at all I suspect unless the version header in org.el gets
properly done.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds