[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [BUG] External unicode links without a description in ox-html
From: |
Michael Brand |
Subject: |
Re: [O] [BUG] External unicode links without a description in ox-html |
Date: |
Mon, 25 Jul 2016 22:33:52 +0200 |
Hi Nicolas
Your suggestions are so convincing in going so far, I hope I
understand them right. If yes it is just thinking in terms of "[[",
"][" and "]]" instead of single brackets that I got used to with the
current escaping and unescaping in Org.
On Mon, Jul 25, 2016 at 2:52 PM, Nicolas Goaziou <address@hidden> wrote:
> Michael Brand <address@hidden> writes:
>> There seems to be a related issue with an inconsistency between HTML
>> and other export formats in using org-link-unescape for the link
>> _destination_ part: With the Org file
>>
>> 1) https://duckduckgo.com/?q=Org+mode+%252B+Worg
>> 2) https://duckduckgo.com/?q=Org+mode+%2B+Worg
>>
>> org-open-at-point on link 1) opens a web browser with the search field
>> filled with "Org mode + Worg" as expected by me.
>
> This looks like an error to me.
>
> If I type https://duckduckgo.com/?q=Org+mode+%252B+Worg in my browser,
> I get
>
> "Org mode %2B Worg"
>
> as the search string. It should be the same when opening the link from
> an Org document. These URI are /not/ equivalent.
>
>> The same happens when using link 1) of the HTML export. But when
>> exporting to PDF (via LaTeX), ODT or ASCII (browse-url-at-point)
>> I have to use link 2) to get the same result. I think one should be
>> able to consistently use link 1) for all export formats.
>
> It looks as we're trying to paper over an Org problem here, which is the
> redundant link escaping that happens when calling `org-insert-link' (C-c
> C-l).
>
> AFAICT, there are two reasons for Org to escape a link: when the link
> contains either "]]" or multiple consecutive spaces. The former
> obviously breaks Org link syntax. The latter doesn't survive a call to
> `fill-paragraph'.
>
> Alas, Org handles it the wrong way, by using a mechanism that cannot be
> properly undone; you cannot possibly know how many times the desired URI
> has been encoded, if at all. Moreover, this mechanism isn't user
> friendly, i.e., you cannot reasonably ask a user to encode an URI on the
> fly when jolting notes.
I agree.
> I can see two ways out:
>
> 1. Do not escape anything.
>
> This prevent any link with a description to contain either "]]" or
... a single bracket at the border or a link destination part to
contain "][" or "]]" or a single bracket at the border or ...
> multiple spaces, but these requirements are so uncommon we probably
> shouldn't bother.
I never had such links and don't bother. If I am right these could
even be tweaked manually with %20, %5B and %5D to get working.
I can't tell for everyone but would happily adapt the escaped ones of
all my existing Org links accordingly if such a change happens in Org.
> 2. Use a different internal escape mechanism.
>
> By providing our own simple escape mechanism, e.g., \]\], we can
> solve the issues raised above.
In my opinion not necessary. Can be added later if really needed
anyway.
> In any case, Org should not create something as
>
> https://duckduckgo.com/?q=Org+mode+%252B+Worg
>
> if the real URI is
>
> https://duckduckgo.com/?q=Org+mode+%2B+Worg
>
> WDYT?
I agree.
Do I understand right that not escaping and unescaping would allow
: https://duckduckgo.com/?q=[dest]dest
: [[https://duckduckgo.com/?q=[dest]dest]]
: [[https://duckduckgo.com/?q=[dest]dest][desc[desc]desc]]
etc. and even the same with link abbreviations instead of http(s)?
Michael