After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 107561 - Erasing Hebrew accents
Erasing Hebrew accents
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.2.x
Other other
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on: 114483
Blocks: 119891
 
 
Reported: 2003-03-04 17:01 UTC by Dov Grobgeld
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch that makes Backspace delete the last glyph of the last cluster (6.46 KB, patch)
2003-07-22 19:21 UTC, Dov Grobgeld
none Details | Review

Description Dov Grobgeld 2003-03-04 17:01:31 UTC
It should be possible to erase the Hebrew accents from the text widget
without erasing the associated character. I propose that erasing should
work as follows:

* Ctrl-d and Delete option should erase the whole cluster in front of it

* Ctrl-h and Backspace should erase the last char in the cluster.

This approach is consistent with how the Qt text widget currently handles
Hebrew accents. The current method where backspace erases the whole cluster
isn't reasonable.

Perhaps it is different for different languages.
Comment 1 Owen Taylor 2003-03-04 17:11:03 UTC
It's very much language dependent; Europeans
think of accented characters as a single character.

Also, note that the behavior should be independent
of the normalization of the text ... it shouldn't
matter if a character is encoded as precomposed
glyph, or as base + combining.

Other languages (Hindi? Korean? forget exactly
what gets grouped as a grapheme) are even more
badly affected by the delete-whole-grapheme rules
than Hebrew, because it occurs constantly for
normal text.

There have been extensive (inconclusive) discussions
of this on gtk-i18n-list, if I recall correctly.
Comment 2 Havoc Pennington 2003-03-04 17:41:25 UTC
Seems to me that if the Unicode spec is on crack and graphemes don't 
correspond to what should be erased, we definitely need to add 
another bit to PangoLogAttr which is the erase boundary. 
Then it's just a matter of implementation to get that bit set properly 
and used properly.
Comment 3 Owen Taylor 2003-03-04 17:52:07 UTC
I think the graphemes do correspond roughly to the 
keynav boundaries ... that is, you don't want to 
position the cursor between the base character and
the mark (deleting the base character and leaving
the mark would be bad) ... they just don't correspond
to the erase boundaries.
Comment 4 Owen Taylor 2003-06-05 14:12:10 UTC
Putting on 2.4.0 as an important issue for Indic/Hangul/etc;
help is definitely needed to get it done.
Comment 5 Dov Grobgeld 2003-07-22 19:21:02 UTC
Created attachment 18527 [details] [review]
Patch that makes Backspace delete the last glyph of the last cluster
Comment 6 Dov Grobgeld 2003-07-22 19:28:01 UTC
I just uploaded a patch that does the following:

* Adds a new setting property "gtk-backspace-delete-single-glyph".

* Added a new signal BACKSPACE_DELETE that is called when the
backspace is pressed.

* Made a signal handler function gtk_text_view_backspace_delete() that
if the setting is on, it deletes between the insert position and one
character back.

This is exactly the functionality that imho is needed for Hebrew, and
seems to be identical to the scheme employed by both OpenOffice and Qt.

Now I am taking cover in anticipation of the expected response about
what gtk design principles I broke in this patch. ;-)
Comment 7 Noah Levitt 2003-08-14 17:46:03 UTC
The patch kinda needs to be redone to use
PangoLogAttr.backspace_deletes_character now.

Also, should handle composed characters by decomposing then deleting
the last decomposed character.

Should we make bug #119891 a sort of tracker and make this the text
view bug, and file a similar text entry bug? Or should we mark this as
a dup?
Comment 8 Owen Taylor 2003-08-14 18:06:41 UTC
I don't think it matters much, but since 
"one patch per bug report" does make things easier, and 
GtkEntry/GtkTextView will be considerably different in
detail, I'll mark this as blocking 119891 rather a duplicate.
Comment 9 Owen Taylor 2004-03-01 21:47:47 UTC
Requires a semi-API addition of another binding signal; 
but since it's pretty important, I may try to streamline
this into GTK+-2.4.1 or GTK+-2.4.2.
Comment 10 Elijah Newren 2004-06-19 18:46:05 UTC
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as
Matthias said he was trying to do himself on IRC and was asking for help with. 
If you see this message, it means I was successful at fixing the borken-ness in
bugzilla :)  Sorry for the spam; just query on this message and delete all
emails you get with this message, since there will probably be a lot.
Comment 11 Matthias Clasen 2004-08-05 23:36:14 UTC
Is this still relevant now that 114483 has been fixed ?
Comment 12 Matthias Clasen 2004-11-24 03:54:26 UTC
Assuming it is covered by 114483