Bug 184 - Entering non-ascii character deletes previous char if spell checking enabled
: Entering non-ascii character deletes previous char if spell checking enabled
Status: RESOLVED FIXED
: Sylpheed-Claws (GTK1)
User Interface/Compose Window
: 0.9.3
: PC Linux
: P1 major
Assigned To:
:
:
:
  Show dependency treegraph
 
Reported: 2003-06-07 08:53 by
Modified: 2003-07-29 18:05 (History)


Attachments
bad patch! (856 bytes, patch)
2003-07-03 22:52, Luke Plant
no flags Details | Diff
correct patch (904 bytes, patch)
2003-07-04 00:33, Luke Plant
no flags Details | Diff
improved patch (1.06 KB, patch)
2003-07-04 15:09, Luke Plant
no flags Details | Diff
Patch for that bug. (578 bytes, patch)
2003-07-17 15:21, Jens Oberender
no flags Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2003-06-07 08:53:54
In compose window:
If I enter a non-ascii char, (e.g. press AltGr-{ u to get ü (u umlaut), or
AltGr-1 to get superscript 1), two different behaviours (both wrong):
- if at very beginning of text widget, the character is inserted twice
- if anywhere else, the previous character is deleted before entering the character.

Locale: output of `locale` is everything =en_GB.UTF-8
(if I change to LANG=C etc the bug disappears )
Spelling checker:  enabled, and 'Check while typing' enabled.

Can someone confirm, or do I have some locale problems?

--------- more info ------------------------
The problem is in this code in gtkaspell.c
Line 0368

	/* We must insert ourselves the character so the
	 * color of the inserted character is the default color.
	 * Never mess with set_insertion when frozen.
	 */

	gtk_stext_freeze(gtktext);
	gtk_stext_backward_delete(GTK_STEXT(gtktext), len);
	gtk_stext_insert(GTK_STEXT(gtktext), NULL, NULL, NULL, newtext, len);

For the u umlaut, len=2 here (it is 2 utf-8 chars) which explains the observed
behaviour if the GtkSText is somehow storing the character in a single byte. I
don't know enough about how sylpheed works with utf-8 etc to know what is going
wrong here.
------- Comment #1 From 2003-06-10 08:12:12 -------
Seems like there should be an extra conversion. Can you play a little bit with 
the code and do something like what the "insert-text" cb does in src/undo.c? 
(Not working with UTF-8 code.) 
Thanks. 
 
 
------- Comment #2 From 2003-06-25 14:47:24 -------
Yep, I'll have a go, thanks for the pointer.
------- Comment #3 From 2003-07-03 22:52:58 -------
Created an attachment (id=70) [details]
Fix

I borrowed code from undo.c, as suggested.
Patch is against 0.9.0claws70
Apologies for not using cvs for the diff, can't get cvs to work at the mo.
------- Comment #4 From 2003-07-03 23:25:56 -------
Excellent: Can be committed. 
------- Comment #5 From 2003-07-04 00:33:31 -------
Created an attachment (id=71) [details]
correct patch

Sorry about the last patch, (it won't even compile!) I don't know how I managed
to do that. This one works.
------- Comment #6 From 2003-07-04 15:09:14 -------
Created an attachment (id=72) [details]
improved patch

improved patch from Melvin Hadasht. (just find the number of wide characters,
don't actually do the conversion).
------- Comment #7 From 2003-07-04 16:22:10 -------
Committed in 0.9.0claws79. Thanks.
------- Comment #8 From 2003-07-05 18:46:19 -------
*** Bug 138 has been marked as a duplicate of this bug. ***
------- Comment #9 From 2003-07-16 08:31:41 -------
Still exists in 0.9.3 release!
------- Comment #10 From 2003-07-16 08:35:37 -------
The behaviour in my case was:
- with active spellcheck umlauts deleted the last character but where not displayed
- without spellcheck the umlauts where just not displayed but nothing deleted

I think the bugfix just changed the bug.

I changed it to critical!

Backtrace:

#0  0x08173a73 in decrement_mark_n ()
#1  0x0816e3a4 in gtk_stext_forward_delete ()
#2  0x08167e9a in change_color ()
#3  0x0816422e in check_at ()
#4  0x08162c66 in entry_insert_cb ()
#5  0x4039521e in gtk_marshal_NONE__POINTER_INT_POINTER () from
/usr/lib/libgtk-1.2.so.0
#6  0x403cb7b3 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#7  0x403ca859 in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#8  0x403c8385 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#9  0x4036175b in gtk_editable_insert_text () from /usr/lib/libgtk-1.2.so.0
#10 0x080b3b6a in text_inserted ()
#11 0x4039521e in gtk_marshal_NONE__POINTER_INT_POINTER () from
/usr/lib/libgtk-1.2.so.0
#12 0x403cb7b3 in gtk_handlers_run () from /usr/lib/libgtk-1.2.so.0
#13 0x403ca9dd in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#14 0x403c8385 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#15 0x4036175b in gtk_editable_insert_text () from /usr/lib/libgtk-1.2.so.0
#16 0x08170d07 in gtk_stext_key_press ()
#17 0x40394ce4 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#18 0x403caa2d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#19 0x403c8385 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#20 0x40407be4 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#21 0x40410b33 in gtk_window_key_press_event () from /usr/lib/libgtk-1.2.so.0
#22 0x40394ce4 in gtk_marshal_BOOL__POINTER () from /usr/lib/libgtk-1.2.so.0
#23 0x403caa2d in gtk_signal_real_emit () from /usr/lib/libgtk-1.2.so.0
#24 0x403c8385 in gtk_signal_emit () from /usr/lib/libgtk-1.2.so.0
#25 0x40407be4 in gtk_widget_event () from /usr/lib/libgtk-1.2.so.0
#26 0x40394c86 in gtk_propagate_event () from /usr/lib/libgtk-1.2.so.0
#27 0x40393998 in gtk_main_do_event () from /usr/lib/libgtk-1.2.so.0
#28 0x404503d0 in gdk_event_dispatch () from /usr/lib/libgdk-1.2.so.0
#29 0x4060986b in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#30 0x40609ee8 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#31 0x4060a044 in g_main_run () from /usr/lib/libglib-1.2.so.0
#32 0x4039336f in gtk_main () from /usr/lib/libgtk-1.2.so.0
#33 0x08070fa7 in main ()
#34 0x401cd8ae in __libc_start_main () from /lib/libc.so.6
------- Comment #11 From 2003-07-16 10:12:27 -------
Obviously we need more UTF8 testers.

I cannot trigger the bug. I finally found that my only working UTF-8 locales
is ko_KR.UTF-8 which I cannot use at a daily base, so I cannot test it in real
life (unless someone sends me an URL explaining how to make Xlib recognize other
UTF-8 (libc is OK))

The patch changed the behaviour for the spell checking only, and only if
multibytes locales are selected. If you experience a change in behaviour while
the spellchecking is disabled (Common Preferences/Spell Checker..), then it is
another bug.

What is that backtrace? Did it crash?
------- Comment #12 From 2003-07-16 11:14:50 -------
And where / when did this crash happen? The backtrace can just point  
(again) at the infamous GtkSText. 
------- Comment #13 From 2003-07-16 12:24:11 -------
I now use a build with disabled aspell.
Umlauts aren't displayed!
It looks like a bug in my undo code.
When I enter some text including umlauts and then press Ctrl+z it removes some
entered characters till the last time I hit an umlaut.
When the last entered character was an umlaut Ctrl+z removes one characters ahead!!!
With aspell I crashed sylpheed complete.
Now you it doesn't crash.

I noticed that this behaviour isn't from the beginning it starts later.
Also some Menuentries disappear (I think those with umlauts). But that could
also something else.

Here some output of --debug:

undo.c:333:New: 1 Action: 0 Paste: 0
compose.c:6031:Set_undo.  UNDO:0  REDO:2
undo.c:306:undo_add(1)*2*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 2
undo.c:306:undo_add(1)*3*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 3
undo.c:306:undo_add(1)*4*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 4
undo.c:395:UNDO_ACTION_INSERT 4
compose.c:6031:Set_undo.  UNDO:2  REDO:0
undo.c:306:undo_add(1)*a*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:185:g_list_length(undostruct->undo): 11
undo.c:333:New: a Action: 0 Paste: 0
compose.c:6031:Set_undo.  UNDO:0  REDO:2
undo.c:306:undo_add(1)*1*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 1
undo.c:306:undo_add(1)*2*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 2
undo.c:306:undo_add(1)*3*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 3
undo.c:306:undo_add(1)*4*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 4
undo.c:306:undo_add(1)*ö*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: ö
undo.c:395:UNDO_ACTION_INSERT 6
compose.c:6031:Set_undo.  UNDO:2  REDO:0
undo.c:306:undo_add(1)*a*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:185:g_list_length(undostruct->undo): 11
undo.c:333:New: a Action: 0 Paste: 0
compose.c:6031:Set_undo.  UNDO:0  REDO:2
undo.c:306:undo_add(1)*1*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 1
undo.c:306:undo_add(1)*2*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 2
undo.c:306:undo_add(1)*3*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 3
undo.c:306:undo_add(1)*4*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: 4
undo.c:306:undo_add(1)*ö*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:283:Merged: ö
undo.c:306:undo_add(1)*ä*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:185:g_list_length(undostruct->undo): 12
undo.c:333:New: ä Action: 0 Paste: 0
compose.c:6031:Set_undo.  UNDO:0  REDO:2
undo.c:306:undo_add(1)*ü*
compose.c:6031:Set_undo.  UNDO:2  REDO:1
undo.c:185:g_list_length(undostruct->undo): 13
undo.c:333:New: ü Action: 0 Paste: 0
compose.c:6031:Set_undo.  UNDO:0  REDO:2
undo.c:395:UNDO_ACTION_INSERT 1
compose.c:6031:Set_undo.  UNDO:2  REDO:0

I will have a look this evening, when I find the time.
------- Comment #14 From 2003-07-17 15:18:42 -------
I found the bug in spamassassin.c.
Attached is a patch.
Reboot, could you please verify it.
------- Comment #15 From 2003-07-17 15:21:50 -------
Created an attachment (id=86) [details]
Patch for that bug.

Moved the setlocale(C) just in front of the filter call and set the locale back
in case that fails.
The reading of the file must not be in the C locale, or am I wrong?
------- Comment #16 From 2003-07-17 15:31:36 -------
sorry for complaining, but can you please use a unified diff next time?  
it's really hard to see what it does in the context of the surrounding  
code. 
------- Comment #17 From 2003-07-17 15:57:35 -------
The setlocale in spamassassin.c is no longer required. I reported the bug in
locale depending floating point handling in libspamc to the spamassassin
developers and they fixed it in libspamc. I just never verified that it works to
remove the setlocale. Doing that today...
------- Comment #18 From 2003-07-17 17:27:07 -------
in the libspamc.c copy in Sylpheed, there are comments dating from may 2003
that
they now use a workaround for the locales, by formatting the real numbers with
a
custom function. (It happens that aspell had the same problem, but they fixed
it.)
------- Comment #19 From 2003-07-17 18:10:58 -------
AS I said: "They fixed it", but I had no time to adjust sylpheed yet. And
currentl POP3 over SSL is broken in sylpheed what makes it rather complicated to
test it.
------- Comment #20 From 2003-07-17 18:42:07 -------
My fault, I thought I were helpful. Sorry.
------- Comment #21 From 2003-07-29 18:05:14 -------
Testing spamassassin without setlocale seems to work correctly

fixed in 0.9.3claws20

* src/plugins/spamassassin/spamassassin.c
        remove setlocale workaround (fixed in libspamc)