Re: Links

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

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