[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bidirectional text and URLs

From: Eli Zaretskii
Subject: Re: Bidirectional text and URLs
Date: Mon, 01 Dec 2014 21:34:46 +0200

> Date: Mon, 01 Dec 2014 14:15:41 -0500
> From: Richard Stallman <address@hidden>
> CC: address@hidden, address@hidden
> 1. A way for a Lisp program to get, for a specified region, a
> short description of the outside bidi context that affects bidi
> treatment of that region.
> The result should be a small amount of data, computed solely from the
> text outside the specified region.  The result should encapsulate
> everything about the text outside the specified region that can
> possibly affect the bidi treatment of whatever text might be inside
> the region.
> Thus, any change in the text outside the specified region, which gives
> the same encapsulated data, will not affect bidi treatment of text
> inside the region.
> Ideally, this data should have a transparent documented format.
> It could be called 'bidi-context'.
> If this can't be done in a way that is independent of the text inside
> the specified region, as a fallback it could be done in a way that
> works only for the current text inside that region.
> 2. Given such encapsulated context data, a straightforward way to
> create an equivalent bidi context in the current buffer.  I expect it
> would work by inserting some magic bidi characters.  (Can all such
> contexts be replicated by inserting some magic bidi characters?)
> It could be called 'replicate-bidi-context'.
> Are these feasible to implement?

The first one sounds pretty complicated.  I need to think about its
feasibility.  It could require analysis of a very large chunk of
buffer text, at least in theory.  What's more, the UBA specifies how
to reorder text given the contents, but not how to do the reverse.

Anyway, what's more important: you can have 2 without 1.  The trick is
to capture the visual order of the text you want to copy (can be done
by looking at the current glyph matrix), and then create a string
whose logical order is identical to the captured visual order, and
embed that string in LRO..PDF, which will ensure the visual order will
not change on display.

The disadvantage of this is that you recreate the order, but not the
reordering, so e.g. cursor motion will be different -- you won't see
the jumps as in the URL phishing example.

reply via email to

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