Re: [O] Escaping links

[Nicolas Goaziou]

Hello,

Fabrice Popineau <address@hidden> writes:

> Are links to a file whose name already holds (url-)escaped chars supported?
>
> If I have a directory named "c:/temp/foo bar/"
> and files in this directory named
> foo.txt
> foo bar.txt
> foo%2Fbar.txt
>
> I can create links in an Org buffer by using `insert' but I find the
> situation a bit confusing.
>
> #+LINK: temp file:c:/temp/%s
>
> 1. [[temp:foo bar/foo bar.txt]]
> 2. [[temp:foo%20bar/foo bar.txt]]
> 3. [[temp:foo bar/foo%20bar.txt]]
> 4. [[temp:foo%20bar/foo%20bar.txt]]
>
>
> All of these links seem to work the same way.
>
> 5. [[temp:foo bar/foo%2Fbar.txt]]
> 6. [[temp:foo bar/foo%252Fbar.txt]]
> 7. [[temp:foo%20bar/foo%252Fbar.txt]]
>
> Link 5 does not work.
>
> Link 6 and 7 do work: as long as I press enter on the link, I visit the
> file.
>
> Unfortunately, if I edit these links with 'C-c C-l', doing nothing
> (return), Org replaces the escaped chars and unescape them.
>
> I have grabbed files whose name hold such %2F %3A and so on escaped chars.
> Do I have any option to make a link point at them or should I rename
> them?

You might get around it by not using link abbreviation.

Anyway, the core problem here is that:

  1. Org uses percent escaping to get around its own limitations (e.g., no
     square brackets allowed in a link);
  2. it's not possible to know if a string is percent-encoded or not;
  3. percent-encoding is not idempotent.

Using a different escaping mechanism to solve 1 and never ever
percent-decode an URL could put an end to the link mess.

Finding an escaping mechanism that also solves 2 is yet to be done.


Regards,

-- 
Nicolas Goaziou