[Top][All Lists]

[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

> 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

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)?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]