Re: Another --> Re: GtkMovementStep of GtkTextView

[Havoc Pennington <hp redhat com>]

Chookij Vanatham <chookij thestork eng Sun COM> writes:
> I'd like to point out that, it's just only the position of I-beam is subtly
> different,at least for Thai. Unfortunately, since the computer has been used
> in Thai market, users will hit that key only 1 time to move to next cluster.
> I don't think that we can force Thai users to the new behavior (graphems)
> for the applications which has the cursor look liked "I-beam" even at least,
> I-beam is moving a little little litte bit and it's hard to see if I-beam
> is in between clusters or within cluster.

The unicode spec implies that a grapheme is simply what the user in a
particular culture will see as the logical unit for text editing -
that is, by definition it's the cursor position. That's why
PangoLogAttr::is_cursor_position is currently computed via the Unicode
grapheme boundary algorithm.

See for example p. 126 (section 5.15) of the Unicode 3.0 book. The
book also says that the general-purpose grapheme algorithm will
properly handle Indic/Tibetan clusters. Assuming I've implemented it
correctly, maybe the standard is_cursor_position algorithm (in
break.c) is already doing the right thing for Thai.
 
> I think that "GTK_MOVEMENT_LOGICAL_POSITIONS" is moving based on "grapheme"
> and not "cluster". So, it shouldn't be used for this case, either.

PangoLogAttr::is_cursor_position should reflect whatever the correct
cursor positions are for a script, and then we should make
GTK_MOVEMENT_LOGICAL_POSITIONS use is_cursor_position.
 
If grapheme boundaries are useful for something other than cursor
positions, maybe we can separate the cursor position attribute from
the grapheme boundary concept and have
PangoLogAttr::is_grapheme_boundary in addition. (Reading the Unicode
spec, however, I don't think that's the case; their grapheme algorithm
is designed to compute the locations where you can place the cursor,
selection boundary, and so on.)

But for sure, the is_cursor_position attribute should accurately
reflect where cursors should go. The Thai language engine should
update this attribute as appropriate to make cursors work correctly in
Thai.

If cursors should always go between clusters, then the Thai engine
could simply set is_cursor_position to TRUE for all cluster boundaries
and FALSE otherwise.

This assumes the generic Unicode algorithm in pango_default_break()
(described in section 5.15 of the Unicode spec) does not work for
Thai; again, assuming it is properly implemented, it might already
work for Thai.

> I haven't seen this piece of code involving for the action of
> "GTK_MOVEMENT_VISUALLY_POSITIONS" yet. May be, I might miss
> something.

You aren't missing anything, I just haven't implemented it yet:
 http://bugzilla.gnome.org/show_bug.cgi?id=50247

Once we implement this, then Thai may already work. If not, we need to
either fix bugs in pango_default_break(), or add code to the Thai
language module so that it sets the is_cursor_position attributes to
the correct values.

Havoc