Links

Links

[Fabrice Popineau]

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

Hi,

I think I need some refresh on what's valid and what is not.

Assume the following file :

#+TITLE: Foo
#+DATE: 2014-11-19 01:10:58

* FOO
[2015-06-16 mar. 13:58]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam tristique diam non turpis. Cras placerat accumsan
nulla. Nullam rutrum. Nam vestibulum accumsan nisl.

* BAR
[2015-06-16 mar. 13:58]
** First link
[2015-06-16 mar. 13:58]

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit
tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et,
mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis
dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae
dolor. Nullam tristique diam non turpis. Cras placerat accumsan
nulla. Nullam rutrum. Nam vestibulum accumsan nisl.

** Second link
[2015-06-16 mar. 13:58]

- [[First%20link][First link]]
- [[file:sample.org][sample.org]]
- [[http://www.google.com][Google]]

The exporter fails to resolve the (fuzzy) link "First%20link".
However, if I click on the link, I jump to the right heading.

Am I missing something or should this be made consistent ?

Fabrice

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

Re: Links

[Nicolas Goaziou]

Hello,

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> Assume the following file :

[...]

> ** First link

[...]

> ** Second link
> [2015-06-16 mar. 13:58]
>
> - [[First%20link][First link]]

[...]

> The exporter fails to resolve the (fuzzy) link "First%20link".
> However, if I click on the link, I jump to the right heading.
>
> Am I missing something or should this be made consistent ?

You are not missing something, but making it consistent is not as
trivial as it sounds.

The problem is that, AFAIK, we cannot tell if a given string is
url-encoded or not. Also, url-encoding is not idempotent.

So, export process doesn't url-decode links, and cannot handle the link
above. OTOH, `org-open-at-point' assumes links are url-encoded (and they
are if you stored them with `org-store-link') so it url-decodes the link
above and is able to follow it.

I think it would be a mistake to expect all links to be url-encoded as
it is a pain when you enter most of your internal links manually.
However, forbidding url-encoding for internal links is also a mistake
because some of them cannot be expressed otherwise (e.g., headlines
containing square brackets). The current situation is also problematic,
of course. Well.

At this point, it seems that all is left are cheesy approaches. E.g,
when a path matches "%[A-Za-z0-9]\\{2\\}", decode it during export. This
leaves pathological cases (e.g., when you really meant, for some very
good reason, to have a headline called "* %25"), though. That's not
great either.

WDYT?

Regards,

-- 
Nicolas Goaziou

Re: Links

[Fabrice Popineau]

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

2015-06-16 14:50 GMT+02:00 Nicolas Goaziou <mail@nicolasgoaziou.fr>:

> Hello,
>
>
> So, export process doesn't url-decode links, and cannot handle the link
> above.


This is what I was missing :-)


> At this point, it seems that all is left are cheesy approaches. E.g,
> when a path matches "%[A-Za-z0-9]\\{2\\}", decode it during export. This
> leaves pathological cases (e.g., when you really meant, for some very
> good reason, to have a headline called "* %25"), though. That's not
> great either.
>
> WDYT?
>

I don't know what is realistic. I see the tradeoffs are tight.

Ideally, url encoded links should have been prefixed with some kind of uri
syntax.
This way, you could know what to decode and what not.

Now, I guess the heuristic you propose would be fine in most cases.
I don't see that people will put a lot of percentages in their links.

Thanks for the explanations !

Fabrice


> Regards,
>
> --
> Nicolas Goaziou
>

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

Re: Links

[Nicolas Goaziou]

Fabrice Popineau <fabrice.popineau@gmail.com> writes:

> Ideally, url encoded links should have been prefixed with some kind of uri
> syntax.
> This way, you could know what to decode and what not.

The encoded link could be copied from somewhere else. Also, there are
numerous links in the wild without this prefix.

> Now, I guess the heuristic you propose would be fine in most cases.
> I don't see that people will put a lot of percentages in their links.

I pushed something along these lines in master. It should solve your
initial issue.

Thank you.

Regards,

Re: Links

[Suvayu Ali]

Hi Nicolas, Fabrice,

On Tue, Jun 16, 2015 at 11:30:06PM +0200, Nicolas Goaziou wrote:
> Fabrice Popineau <fabrice.popineau@gmail.com> writes:
> 
> > Ideally, url encoded links should have been prefixed with some kind of uri
> > syntax.
> > This way, you could know what to decode and what not.
> 
> The encoded link could be copied from somewhere else. Also, there are
> numerous links in the wild without this prefix.

Would it make sense to "promote" these kind of encoded links to almost
their own sub-types?  I would guess, almost no one enters these encoded
links by hand.  It's either via copy paste in the prompt from
org-insert-link, or by entering [[encoded-link][description]] by hand.
I think it is a reasonable inconvenience to ask the user to prefix it
with something like uri:.  I mostly see advantages for a minor
inconvenience.  

Although, you still have to handle the ambiguous case for existing Org
files.  Unless this double maintenance is cumbersome, I would vote for
introducing such a scheme.

What do others think?

-- 
Suvayu

Open source is the future. It sets us free.

Re: Links

[Nicolas Goaziou]

Hello,

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> Would it make sense to "promote" these kind of encoded links to almost
> their own sub-types?  I would guess, almost no one enters these encoded
> links by hand.  It's either via copy paste in the prompt from
> org-insert-link, or by entering [[encoded-link][description]] by hand.
> I think it is a reasonable inconvenience to ask the user to prefix it
> with something like uri:.  I mostly see advantages for a minor
> inconvenience.

I don't think we should go as far as changing link syntax for this.

Actually, the problem lies in internal links, since external ones are
expected to be url-encoded when necessary.

Internal links only require url-encoding when they contain square
brackets. So, we can make a guess: if a string either doesn't contain
"%5B" or "%5D", or contains any character in `org-link-escape-chars'
(with the exception of the percent sign), it cannot be encoded.

Otherwise, we can assume it is encoded. In this case, there are false
positives, but those are sufficiently rare (i.e., an internal link with
either "%5B" or "%5D" and no space in it) this should not be a problem
in practice.

There is an important drawback however, as in the prefix proposal:
currently encoded internal links (e.g. "Headline%201") will break.

> Although, you still have to handle the ambiguous case for existing Org
> files.  Unless this double maintenance is cumbersome, I would vote for
> introducing such a scheme.

The double maintenance is not possible. Either we take into
consideration the prefix or the heuristic rule above, and some links are
going to break, or we allow to bypass it and it doesn't improve the
situation.


Regards,

-- 
Nicolas Goaziou

Re: Links

[Suvayu Ali]

On Wed, Jun 17, 2015 at 11:47:38AM +0200, Nicolas Goaziou wrote:

 [... description of the issues trimmed ...]

> > Although, you still have to handle the ambiguous case for existing Org
> > files.  Unless this double maintenance is cumbersome, I would vote for
> > introducing such a scheme.
> 
> The double maintenance is not possible. Either we take into
> consideration the prefix or the heuristic rule above, and some links are
> going to break, or we allow to bypass it and it doesn't improve the
> situation.

This is tricky indeed.  I guess the heuristic is the safest bet when it
comes to compatibility.

-- 
Suvayu

Open source is the future. It sets us free.