Re: Caret

> From: Philippe Verdy <verdy_p_at_wanadoo.fr>
> Date: Tue, 13 Nov 2012 05:55:53 +0100
> Cc: Jeff Senn <senn_at_maya.com>, Unicode Mailing List <unicode_at_unicode.org>
>
> Thanks for admitting this. But I used an informal adjective on purpose, to
> avoid having to display any numeric statistics.

Mine is also informal, but its being an annoyance, it's "frequent
enough" in my book. It means users will want that double caret
feature -- or any other feature that would disambiguate the results of
the next editing command.

> Even in the case of digits+letters, this will likely concerns only
> measurement (including dates and time stamps) and it will remain rare to
> find these using Euro-Arabic digits associated with Arabic or Hebrew
> letters without an intermediate directionnally weak space. As soon as there
> will be some space (or hyphen, sjamsh or punctuation) separation between
> the numeric value and the Hebrew/Arabic word or abbreviation, the editor
> behavior does not need to use dual carets. In addition, most measurements
> should use international unit symbols which are not written with RTL
> letters.

Sorry, I don't follow: how can space or hyphen or any other weak or
neutral character alleviate the problem? In my experience, these make
the problem worse, because they tend to jump when some strong
character is entered, depending on its directionality.

As an example, consider the following well-known gotcha. Logical
order:

    HEBREW-a

Visual order:

    WERBEH-a
           ^

Now, as soon as you type X, a strong RTL character, at the caret
(making the logical order HEBREW-Xa), you get this on the screen:

    X-WERBEHa

IOW, weak and neutral characters make the problem worse because they
_extend_ the range of positions where such surprising effects take
place. E.g., try a string of dashes, commas, etc. -- they will all
"jump" and reverse their order once a single strong RTL character
follows them. (I'm sure I'm not saying anything you didn't already
know, btw.)

> Anyway, such specification describing the problem more compltely should be
> documented in the UBA, explaining the recommanded solution for the case of
> caret positioning and visual hints about the direction of insertion.

I'd welcome that. Although the reality flies in the face of user
requirements in this case: most bidi-aware editors, including my own
work in Emacs, don't have 2 carets, for some reason. Maybe the
developers didn't consider that important enough, or maybe it's just
too darn hard...
Received on Tue Nov 13 2012 - 06:56:39 CST