Hello, Fabrice Popineau <fabrice.popin...@gmail.com> 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