From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sergei Nosov Subject: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 12:58:52 +0300 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0103defaff9122051da714c0 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS091-0005Ou-N4 for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 05:58:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS090-0005o9-Iu for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 05:58:55 -0400 Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]:32953) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS090-0005nI-9Y for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 05:58:54 -0400 Received: by wijp15 with SMTP id p15so121985476wij.0 for ; Wed, 19 Aug 2015 02:58:52 -0700 (PDT) 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: emacs-orgmode@gnu.org --089e0103defaff9122051da714c0 Content-Type: text/plain; charset=UTF-8 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 --089e0103defaff9122051da714c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

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

In this package, toc-org, I use=C2=A0org-link-translation-fu= nction 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 v= ariable 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.= =C2=A0

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

(defu= n org-translate-link (s)
=C2=A0 "Tra= nslate a link string if a translation function has been defined."
=C2=A0 (if (and org-link-translation-function=
=C2=A0 (fboundp org-link-translation-function)
=C2=A0 (string-match "\\([a-zA-Z0-9]+\\):\\(.*\= \)" s))
=C2=A0 =C2=A0 =C2=A0 (progn<= /div>
(setq s (funcall org-link-translation-function
(match-string 1 s) (match-string 2 s)))
(concat (car s) ":" (cdr s)))
=C2=A0 =C2=A0 s))

Consider that we're trying to follow the lin= k [[#about][About]]

In Org 8.2= =C2=A0org-translate-link=C2=A0function is called with s equal to "this= file:#about". So, (string-match "\\([a-zA-Z0-9]+\\):\\(.*\\)"= ; s) returns true and the call to the function stored in org-link-translati= on-function follows.

In Org 8.3 org-translate-link=C2=A0function is ca= lled with s equal to simply "#about" (no "thisfile:" in= the beginning). Thus, the string-match call NEVER succeeds (because there&= #39;s no colon).

Please, let me know, what would be the solution to th= is issue.

--
Best regards,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0Sergei Nosov
--089e0103defaff9122051da714c0-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 12:25:15 +0200 Message-ID: <87bne3mv78.fsf@gnu.org> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS0Yb-0006MP-MU for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:25:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS0YX-0004vm-Jx for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:25:21 -0400 Received: from so1.mailgun.net ([198.61.254.11]:56596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS0YX-0004vT-Fv for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:25:17 -0400 In-Reply-To: (Sergei Nosov's message of "Wed, 19 Aug 2015 12:58:52 +0300") 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: Sergei Nosov Cc: emacs-orgmode@gnu.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 12:39:12 +0200 Message-ID: <877fora7fz.fsf@nicolasgoaziou.fr> References: <87bne3mv78.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS0kT-0006Cg-6h for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:37:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS0kS-0001oh-8d for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:37:37 -0400 In-Reply-To: <87bne3mv78.fsf@gnu.org> (Bastien's message of "Wed, 19 Aug 2015 12:25:15 +0200") 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 Cc: Sergei Nosov , emacs-orgmode@gnu.org Hello, Bastien 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 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 13:53:30 +0300 Message-ID: References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e011771a966681a051da7d86f Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS0zt-0005eq-Im for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:53:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS0zs-0001Th-5m for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:53:33 -0400 In-Reply-To: <877fora7fz.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 --089e011771a966681a051da7d86f Content-Type: text/plain; charset=UTF-8 > 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 ":" 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 wrote: > Hello, > > Bastien 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 > --089e011771a966681a051da7d86f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0wild guess: what if you simply make the ":" = optional like this:

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

<= /span>
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=C2=A0org-ele= ment-link-parser.=C2=A0

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

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

Also,=C2=A0org-translate-link s= hould probably be called somewhere in=C2=A0org-open-at-point again.


--=
Best regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Sergei Nosov

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

Bastien <bzg@gnu.org> writes:

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

I think `org-translate-link' should be updated to provide correc= t type,
including internal ones, to `org-link-translation-function'. E.g.,

=C2=A0 = http://orgmode.org =3D> "http"
=C2=A0 #something=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> "custom-id&= quot;
=C2=A0 (ref:line)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> "coderef&qu= ot;
=C2=A0 whatever=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D> "fuzzy= "

At least, this would be consistent with the parser.

Regards,

--
Nicolas Goaziou

--089e011771a966681a051da7d86f-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 12:55:49 +0200 Message-ID: <87pp2jtumi.fsf@gnu.org> References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS129-0006m4-39 for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:55:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS128-00030Z-5P for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:55:52 -0400 Received: from so1.mailgun.net ([198.61.254.11]:34728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS128-0002pV-2S for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 06:55:52 -0400 In-Reply-To: <877fora7fz.fsf@nicolasgoaziou.fr> (Nicolas Goaziou's message of "Wed, 19 Aug 2015 12:39:12 +0200") 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: Nicolas Goaziou Cc: Sergei Nosov , emacs-orgmode@gnu.org 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. -- Bastien 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Wed, 19 Aug 2015 15:28:18 +0200 Message-ID: <87r3mz8l1p.fsf@nicolasgoaziou.fr> References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZS3O8-0002Lb-8C for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 09:26:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZS3O7-0005Ta-Ge for emacs-orgmode@gnu.org; Wed, 19 Aug 2015 09:26:44 -0400 In-Reply-To: <87pp2jtumi.fsf@gnu.org> (Bastien's message of "Wed, 19 Aug 2015 12:55:49 +0200") 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 Cc: Sergei Nosov , emacs-orgmode@gnu.org 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, From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Fri, 21 Aug 2015 14:11:18 +0200 Message-ID: <87r3mwon89.fsf@nicolasgoaziou.fr> References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> <87r3mz8l1p.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46456) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSl8h-0004ZK-6F for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 08:09:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSl8g-0005XT-B6 for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 08:09:43 -0400 In-Reply-To: (Sergei Nosov's message of "Wed, 19 Aug 2015 16:55:04 +0300") 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: Sergei Nosov Cc: Bastien , emacs-orgmode@gnu.org Sergei Nosov 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, 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: Fri, 21 Aug 2015 15:48:10 +0300 Message-ID: References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> <87r3mz8l1p.fsf@nicolasgoaziou.fr> <87r3mwon89.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0103defa24aebb051dd1ae87 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:57558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSljy-0003Rd-2S for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 08:48:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSljw-0005QJ-HJ for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 08:48:14 -0400 In-Reply-To: <87r3mwon89.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: Sergei Nosov , Bastien , emacs-orgmode@gnu.org --089e0103defa24aebb051dd1ae87 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > What doesn't work? I.e., what is produced and what did you expect instead? =E2=80=8B 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".=E2=80=8B 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 wrote: > Sergei Nosov 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, > --089e0103defa24aebb051dd1ae87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0What doesn't work? I.e., what is produced and what= did you expect
in= stead?
=E2=80=8B
The jump via C-c C-o didn't work for me. But I f= igured it out in a meanwhile - supposedly, what was previously called "= ;thisfile" link type is now called "fuzzy".=E2=80=8B Thanks.=

>=C2=A0IIUC MELPAe they should already be available.

Sorry, I meant, Org ELPA (http://orgmode.org/elpa/) not MELPA (org is n= ot published on MELPA at all). The last published package seem to be=C2=A0<= a href=3D"http://orgmode.org/elpa/org-20150817.tar">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, alt= ernatively, what's the Org policy for publishing new packages to ELPA?<= /div>


--
Be= st regards,
=C2=A0 =C2=A0 =C2=A0 =C2=A0Sergei Nosov

On Fri, Aug 21, 2015 at 3:11 PM, Nicolas Goa= ziou <mail@nicolasgoaziou.fr> wrote:
Sergei Nosov <sergei.nosov@gmail.com> writes:

> 1. Previously, the type of the link was "thisfile", now it&#= 39;s "custom-id"
> and also, the leading hash is removed from the link. Let's conside= r
> the [[#about][About]]
> example once again. Previously, I was given ("thisfile" . &q= uot;#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 expec= t
instead?

> BTW, there's a line (require 'ord-id) in org-open-at-point fun= ction 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,

--089e0103defa24aebb051dd1ae87-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Fri, 21 Aug 2015 15:04:40 +0200 Message-ID: <87bne0okrb.fsf@nicolasgoaziou.fr> References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> <87r3mz8l1p.fsf@nicolasgoaziou.fr> <87r3mwon89.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSlyS-0002yZ-Cg for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 09:03:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSlyM-0004ik-Lb for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 09:03:12 -0400 In-Reply-To: (Sergei Nosov's message of "Fri, 21 Aug 2015 15:48:10 +0300") 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: Sergei Nosov Cc: Bastien , emacs-orgmode@gnu.org Sergei Nosov 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".=E2=80=8B 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. S= o, > 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, From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: Regression: org-translate-link doesn't work correctly in Org 8.3 Date: Fri, 21 Aug 2015 20:44:47 +0200 Message-ID: <874mjsbhwg.fsf@Rainer.invalid> References: <87bne3mv78.fsf@gnu.org> <877fora7fz.fsf@nicolasgoaziou.fr> <87pp2jtumi.fsf@gnu.org> <87r3mz8l1p.fsf@nicolasgoaziou.fr> <87r3mwon89.fsf@nicolasgoaziou.fr> <87bne0okrb.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSrJF-0000my-SJ for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 14:45:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZSrJC-0002f5-NT for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 14:45:01 -0400 Received: from plane.gmane.org ([80.91.229.3]:33374) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZSrJC-0002eS-Gh for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 14:44:58 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZSrJA-0001eX-9g for emacs-orgmode@gnu.org; Fri, 21 Aug 2015 20:44:56 +0200 Received: from p54b4725e.dip0.t-ipconnect.de ([84.180.114.94]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2015 20:44:56 +0200 Received: from Stromeko by p54b4725e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 21 Aug 2015 20:44:56 +0200 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: emacs-orgmode@gnu.org 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