From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Nosov Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 16:55:04 +0300 Message-ID: References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> <87r3mz8l1p.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b87381abc95b2051daa61f1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS3pf-0001AS-9J for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 09:55:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS3pa-0003Ib-2q for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 09:55:11 -0400 In-Reply-To: <87r3mz8l1p.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien , Sergei Nosov , emacs-orgmode@gnu.org --047d7b87381abc95b2051daa61f1 Content-Type: text/plain; charset=UTF-8 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, > --047d7b87381abc95b2051daa61f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 consi= der the=C2=A0[[#about][About]]= example once again. Previously, I was given ("thisfile" . "= #about") and I changed this to ("thisfile" . "About&quo= t;), which then worked like a charm. Now, I'm given ("custom-id&qu= ot; . "about"), which I don't know how I should translate. Ne= ither of ("custom-id" . "About") or ("id" . &= quot;About") work. What should it be?

BTW, there's a line=C2=A0(require '= ord-id) in=C2=A0org-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,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0Sergei Nosov

On Wed, Aug 19, 2015 at 4:28 PM, Nicolas Goa= ziou <mail@nicolasgoaziou.fr> wrote:
Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <mail@nic= olasgoaziou.fr> writes:
>
>> I think `org-translate-link' should be updated to provide corr= ect type,
>> including internal ones, to `org-link-translation-function'. E= .g.,
>>
>>=C2=A0 =C2=A0http://orgmode.org =3D> "http"
>>=C2=A0 =C2=A0#something=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> &q= uot;custom-id"
>>=C2=A0 =C2=A0(ref:line)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> &q= uot;coderef"
>>=C2=A0 =C2=A0whatever=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D&g= t; "fuzzy"
>>
>> At least, this would be consistent with the parser.
>
> Agreed.

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

=C2=A0 [[foobar:something]]

is seen as ("fuzzy" "foobar:something") by
`org-link-translation-function', not ("foobar" "somethin= g"), 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 type= s but
handle conflicting link types. In any case, in the example above, one
can always use

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

in `org-link-translation-function'.

Regards,

--047d7b87381abc95b2051daa61f1--