Re: Bidirectional text and URLs

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <address@hidden>
> Cc: address@hidden
> Date: Sat, 29 Nov 2014 19:33:47 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > I think instead of removing them it is better to display them
> > prominently, e.g., by changing their entry in the
> > glyphless-char-display char-table.  The advantage is that you don't
> > accidentally harm the display where these controls are used
> > legitimately, and OTOH make their presence acutely evident.
> 
> Yeah, isn't that a bit too intrusive if done generally?

I didn't suggest to do that generally, just in Web pages.  These
format controls are discouraged in Web pages anyway; the use of HTML
bidi markup dir="rtl" etc. is advised instead.

> If we display these markers very visibly, then buffers where they
> are legitimately used would be kinda ugly.

I don't know why it would be "ugly".  The text will still be displayed
correctly, so it will be as legible as with our current bidi display.

> And I don't think users would necessarily know that the URL is
> displayed the wrong way around just because there's an ugly control
> character displayed before or after the URL...

I think the existence of a strange unprintable character in or around
a URL should attract attention, which is all we need to accomplish.

> >> But currently Emacs doesn't really have a mechanism for querying the
> >> directionality of a buffer region, I think?
> >
> > What do you mean by "directionality of a buffer region"?  At least
> > under some definitions of that, I can think of a very easy
> > implementation.
> 
> When hitting RET on an URL, the function that handles that could ask
> Emacs "is the http://domain.com bit displayed RTL or LTR"?  If it's RTL,
> then that function could "are you sure?" the user.

You just replaced one not well-defined term with another.  So now my
question becomes what do you mean by "displayed RTL or LTR"?  And mind
you: the "domain" part can legitimately consist of RTL characters, if
my reading of the respective RFCs is correct.