Re: Caret

One bad thing of this scheme is that a user that is counting the character
graphemes manually by pressing only the RIGHT key from the start of the
line up to the end of the line may count an extra position each time the
UBA-resolved direction changes on the line.

Another solution for the editor in that case is to still display the two
carets, but if they cannot be displayed both at the same time in the same
rendered view of the text, it can split the view area in two equal-width
halves : a left view and a right view (with an explicit view separator
appearing, each one possibly having its own horizontal bar), where each
view will show a correctly positioned caret, each one showing the correct
UBA-resolved direction of each context.

The splitted views should not be used if both carets can be displayed in
the same view without having to scroll it horizontally.

In a WYSIWYG edited document, where the editing view can show BOTH the left
and right margin of the intended page (or where automatic linewraps are
generated, such as most HTML pages in a web browser that displays an
editable text field), and where no horizontal scrollbar is needed for the
editable field view, all lines of the paragraph are completely displayed,
the UBA algorithm is applied line by line, and the two carets are always on
the same rendered line. They can always be made BOTH visible at the same
time on that line, each one showinf its correct direction (with their arrow
head).

The splitted dual view (left part and right part) of the same edited text
will only appear for editing ling lines that don't fit in the edit view
area and on which the two carets are too far away on the line to be both
visible at the same time (that view should already have the horizontal bar
for this case, but here the horizontal scrollbar may be splitted below each
part).

2012/11/15 Philippe Verdy <verdy_p_at_wanadoo.fr>

> One of the issues caused by the two carets is that sometmes you won"t be
> able to have them BOTH visible at the same time in the screen area. This
> adds another complecity : how do you locate the second caret if it's not
> visible ?
>
> Do you need to design a new key to switch easily between both to make the
> other blinking position visible ? Do you need to scroll the display and
> where do you scroll up or down to to display enough contents ?
>
> Note that the text input area may be very narrow, much narrower than the
> text you input there, and it is not always easy to navigate here (you
> already have the left/right arrow keys to position the logical insertion
> point, but if you position the localical insertion point, then you have two
> visual positions (one for the BEFORE context, and the other for the AFTER
> context).
>
> Many editors don't offer the choice, and will just display the BEFORE
> context (when working in insert mode), or the AFTER context (when working
> in overwrite mode) using then a single caret. This does not remove for them
> the possibility of displaying the associated UBA-resolved direction of this
> context.
>
> Another solution is simply to switch between the BEFORE and AFTER context
> by just pressing the same LEFT or RIGHT move function key without actually
> moving the insertion point, as if there was a zero-width character
> (invisible on screen and absent from the encoded text) present at the
> logical insertion point :
> * the editor knows that the insertion point is at a logical position
> where the resolved UBA direction is changing
> * the editor knows if it is currently showing the BEFORE direction or the
> AFTER direction with a boolean state
>
> if you type a character or press BACKSPACE or DELETE after switching the
> context, the insertion or deletion performed will be exactly the same. But
> when you switch between the BEFORE and the AFTER context, not only you'll
> see the visual position altered but the caret will also change its form
> showing the reverse direction.
>
>
> But If the BEFORE text is LTR and the AFTER text is RTL (e.g. you are ar
> the logical position indicated by the bar in "lati|nARABIC". and the
> paragraph default forward position starts from the LEFT, then the RIGHT
> arrow key will move throughout the paragraph in the FOREWARD (AFTER)
> direction. Then:
> * at the current position (in Latin) both the BEFORE and AFTER contexts
> are in the LTR direction, so you don't need any dual caret, the RIGHT key
> will just skip immediately to the NEXT grapheme cluster, i.e. to the RIGHT.
> * at this point it reaches the point where the direction will change. Two
> caret positions are possible for the same logical position. However as you
> have just pressed the RIGHT key, the editors knows that you are going
> foreward, and should show the BEFORE context (the before context is still
> in latin which is RTL, so the caret will be positioned immediately to the
> right of the Latin text, showing the LTR direction on arrow head of the
> caret glyph, the display will be:
> latin_CIBARA
> * if you press the RIGHT key a second time, the editor knows that you are
> already showing the BEFORE context, so it switch to display the AFTER
> context and the caret is positioned to the right of the ARABIC word and it
> displays the caret at the new position with the caret glyph showing an
> arrow head reversed to the LEFT direction (the logical insertion point has
> NOT changed, the encoded text has also NOT changed):
> latinCIBARA^
> * if you press agains the RIGHT (FOREWARD) key a third time, the editor
> knows that it is still at a direction-changing displaying logical position
> but that it is currently showingf the AFTER context. In that case it can
> effectively continue moving in the FOREWARD direction and will skip the
> first ARABIC letter. At this point it is no longer at a direction-changing
> logical position, and a single caret is enough. The display becomes:
> latinCIBAR|A
> (if the "|" single caret shows a directional arrow head, it points to the
> right : it should be made visible in this case because it shows the
> FOREWARD direction is not to the RIGHT but to the LEFT, and to continue to
> the foreward direction, the key to use is still the RIGHT arrow key), so
> the display should better be:
> latinCIBAR^A
>
> Once again, I used the notation where "|" uses the glyph for a single
> caret that does not needing to display the UBA-resolved direction, "^" is
> the caret used to display the arrow head to the LEFT, and "_" is the caret
> that display the caret with an arrow head to the RIGHT.
>
> This operatinig mode can work in plain-text terminals with a single caret
> (except that arrowheads may possibly not be displayed; but instead the
> caret may still be a half-block positioned at the TOP of the character cell
> oe at the bottom, when the normal caret is a thinner block usually below,
> or a full block. It could work in Emacs.
>
> In other words, you can still create a coherent editor that will display
> only one caret at a time, even if it handles the dual visual positions
> associated to a single logical position where the UBA-resolved direction
> changes.
>
>
Received on Thu Nov 15 2012 - 01:38:09 CST