GNOME Bugzilla – Bug 631508
[Indic] Find/Replace Box has problem with halant, Backspace is not working if halant is used
Last modified: 2015-06-16 08:40:46 UTC
Description of problem: While pressing backspace in gedit's Find/find & Replace box and if halant (U+ 094D of Hindi), it is not working anyway. Version-Release number of selected component (if applicable): gedit-2.30.4-1.fc14.x86_64 How reproducible: Everytime Steps to Reproduce: 1. run gedit 2. type or copy paste (क्प) 3. Backspace two times Actual results: first backsapace will work, but 2nd will not Expected results: with halant (094d), it is should work Additional info: 1) Delete is working as expected 2) supposed to problem for all Indic locales, which has halant 3) it is working gedit.
Created attachment 189801 [details] [review] proposed patch Even if the insert-text signal is invoked for the text targeting less than what it contains, gedit_utils_escape_search_text() ignores it. so the second backspace is also simply ignored then. the proposed patch respects the length giving by insert-text signal.
I can still see this issue on gedit-3.0.2 and confirmed a fix with the above patch.
Can you explain under which condition insert-text signal is emitted with a lenght param that does not match the text? Is this related to a specific input method? Maybe it is a bug in gtk that should truncate the string to the lenght specified
you could see this issue after simply copy-and-paste क्प to the search box and press the backspace key twice there. 2nd key press won't delete anything as it described at the original report. nothing special. it's easy to reproduce that.
Ok, but my question stands: why does in that case gtk report a different lenght different from strlen(string)? It still looks like a gtk bug to me...
I don't have the certain answer for that because it's not my design... but that sounds like you are questioning why gtk_editable_insert_text has the length as the parameter. anyway, API says: * @new_text_length: the length of the new text, in bytes, * or -1 if new_text is nul-terminated That simply allows us to insert the non-null-terminated text if the certain number of the length is given. Hopes that help.
ping?
mmm, not sure I totally understand this. To me as paolo said this is a gtk+ bug.
I have no idea to explain more than the above. please feel free to reassign this to gtk+ or anywhere else you think better to deal with this. this is important for Indic anyway, so hope we will get fixed soon.
Paolo, that's part of the API, gedit should respect the length. My guess is that the text is coming from this code: gtk_entry_backspace(): gtk_editable_delete_text (editable, prev_pos, priv->current_pos); if (len > 1) { gint pos = priv->current_pos; gtk_editable_insert_text (editable, normalized_text, g_utf8_offset_to_pointer (normalized_text, len - 1) - normalized_text, &pos); gtk_editable_set_position (editable, pos); }
With gedit 3.14, when I press the first time backspace I get the character क्, when I press another time backspace I get क, and then another backspace removes the character. So I need 3 backspaces to empty the search field. In summary: क्प -> क् -> क -> empty. In firefox I get the same behavior, so I guess the bug is fixed. Feel free to reopen the bug if you can still reproduce it with a recent version of gedit.