Re: Bidirectional text and URLs

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden,
>     address@hidden
> Date: Tue, 02 Dec 2014 03:32:07 +0900
> 
> Eli Zaretskii writes:
> 
>  >  . modify the way the relevant directional controls are displayed to
>  >    make them prominently apparent
> 
> -0 I don't think this will help enough, especially for the users who
> would most benefit from Emacs's automated paranoia (ie, those who read
> bidi but not RFCs).

This alternative makes the least changes on display.

> Note that RFC 3987 specifies that bidirectional IRIs must *always* be
> displayed with the UBA, and as if in an LRE embedding.  I'm not sure
> how you would enforce it, but I believe this would defang larsi's
> example (ie, at the start of the URI proper in logical order insert a
> LRE, and at the end a PDF -- any directional format characters between
> those points are nonconforming to RFC 3987, section 4.1, last
> paragraph).

Using an LRE..PDF embedding is a possibility, but it can be defeated:
the UBA mandates that any embeddings above some predefined fixed depth
are to be ignored.  So a malicious code could insert a large enough
number of RLOs such that any LRE would be ignored.

That's one of the reasons why I prefer not to poke the text with
additional directional controls.

>  >  . replace the relevant directional controls with percent-hex encoded
>  >    representation, which will as result disable the reordering
> 
> -1  If they're outside of the IRI, this will just make things ugly.

Ugly, yes.  But if these cases are sufficiently rare, that ugliness is
useful, I think, as it will attract attention.

> If they're inside the IRI, they're non-conforming and therefore bogus,
> and would be caught by the tooltip.

Yes, but tooltips could be overlooked (or even disabled globally by
the user).

>  >  . cover the relevant directional controls with a display property
>  >    (e.g., with a display string " "), which will also disable
>  >    reordering
> 
> -0 This is just a specific implementation of the first option above, right?

No, it also disables reordering, whereas the first one doesn't.