Re: Caret

When I look at the old Oracle document (in fact initially from Sun for
Java) which uses unclear presentation, even if the reasons are well
explained, I have doubts about your statement that "all the problems are
defined away". It was not even written at a time where the UBA was well
defined, and this document looks more like an old proposal, which does not
even match the current implementation in Java.

You seem to insist in the term "rare" which is just what it means :
informal qualification about what many people (I don't everyone, and I've
also said explicitly that this did not include software implementrors which
have to take this "rare" event into account) will encounter in real life :
thy will encounter it, otherwise we wouldn't need to implement it. But
users certianly don't want to be exposed to such complication when it is
not needed because there's no ambiguity.

It's like if each time you computed "2+2" on a calculator, the calculator
displayed the result as "4 (i.e. 1+1+1+1)" when users just want to see "4"
which is not ambiguous. But if a calculator displays "10", and the
calculator can compute in various numeric bases, it should display the
actual base used in the result when it is not ten (the most commonly used
base). The calculator will then compute 4×4 to display only the result as
"16" (without having to display "16 _[10]" ou "16d"), or could display "10
_[16]" or "10h" to make sure that you understand it is displaying
hexadecimal : a convention is used there, where it is actually useful
because it is not the most commonly used case.

Only what is needed to distinguish the ambiguous cases is relevant.
Entering basic texts in an editor will not require the complexity of a dual
caret, unless the text is effectively bidirectional : to compose a full
book (or even just a full paragraph) it will not be a rare case, but the
number of occurences where you'll want the dual caret to be visible will be
very small compared to the number of cases where it won't be needed because
most character pairs in text are definitely not bi directional. We are
effectively extremely in far lower rates than 50%, even if rates will vary
across documents and authors.

And I really don't think this is just a "personnal interpretation". But
here you want to refocus the discussion only "among people actually
implementing bidi text editing". That is not fair because I excluded them
explicitly from the count: in the opposite, nearly 100% of people
implementing Bidi text editing will encounter this case, and should now
take it into account, better sooner than later. This does not mean that
they must not think about making the GUI interface as simple as possible
for the most frequent cases.

Also I've NOT commented things or cases that were documented correctly in
the UBA or in any document given here. So it cannot be obvious to everyone
(otherwise we would already see a dual caret appearing since long in
Notepad or in Internet Explorer, or Firefox, or on our smartphones, and
this is still not the case, after years tryng to develop the UBA and make
it standard, with some issues still to solve like the more recent UPA
extension proposed for parentheses and similar characters !)
Received on Tue Nov 13 2012 - 23:01:08 CST