User talk:Uri/Bidi editing

--Eyalroz 11:20, 21 Aug 2005 (PDT) Eyal's ramblings the matter

Switching keyboard layout should indeed not affect caret position.

Uri mentioned several problems:

"system (even when fully implemented) does not ensure that the typed character will appear at the location of the caret" <

       jabc
       i  d
       hGFE

ok, that's a bit contrived but the point is that your options for where to place the typed character so as to be close to where the caret is visually are not always so well determined AFAICT, plus they can change if there's a 'reflow', i.e. if the layout changes for any reason. So I'm not at all sure this should even be supported. (To be fair one can say that logical positions may change also if the content changes dynamically.)

"In the case of deleting, when the caret is not adjacent to the to-be-deleted character, the system's solution is to not actually delete a character, but to move the caret (possibly a long distance!) to the position where the deletion would have taken place. This is likely not what the user expects. The user expects for a character visually adjacent to the caret to be deleted."

No! Unless the user knows for certain that everything is happening in logical order (in which case the previous issue is moot), he may not feel at all secure in his guess of which character the Del may affect. Deleting one of two characters according to some criteria means running the risk of deleting a character which the user did not intend to delete - and that's worse than failing to delete a character. I would even say that moving the caret to where the deletion would take place is not such a bad idea. Anyway, to me, backspace must mean deleteion of the previous character logically and Del must mean deleteion of the next character logically. I'm against making their meaning semi-visual or entirely visual (although again I don't mind anything being done as a pref).

Regarding semi-visual deletion: point taken. I amended the document so that delete will never be done non-logically. However, when two logical deletes are possible based on the visual caret position, my method allows to chose one of them Uri 10:48, 22 Aug 2005 (PDT)

"When switching keyboard layouts, the caret might move to a different position."

Yeah, that is a problem. Altohugh for some strange reason I haven't really noticed it before (too many other bugs I guess). This shouldn't happen.

Finally, as for having two position state modes (logical and visual), I'm rather hesitant - because it seems that's something which is independent of the abovementioned issues and is more like a suggested optimization of the solution. But it may be more trouble than it's worth. I also suspect mozilla may not be keeping record of how the logical text is layed out visually (there's that 'text transformer' thing which fills a buffer which is probably the visual ordering of the text, and one that's put on screen it's probably forgotten, although I don't know that for sure); this may also be the case for frames in general. If that's true than maintaining the 'visual position' means nothing except perhaps remembering which frame the caret is in at the moment, which is something that happens now.

--Roc

Generally I think Uri's discussion is very well written and makes a lot of sense. In particular the part about not explicitly tracking visual positions, but instead using a content position and a hint, is absolutely right. It's the only way to reliably maintain the caret position during reflows and style changes.

It's impossible for me to judge what the best UI alternative is, so that's entirely up to you guys. But my guess is that for platforms that have a consistent bidi editing UI, we should should emulate whatever it is ... even if it's suboptimal, consistency is a great virtue. That may require the use of hidden prefs to select which behaviour is desired.

Let's not worry about TBRL text :-). Any support for that in Gecko is very far away ... certainly won't happen in 1.9. In any case I believe "content position plus a forward/backward hint" would still quite sufficient for TBRL and even the junctions between TBRL and LTR/RTL.