Bug 102366

Summary:	Dead keys delete selected text: sending IMStart with 0 chars
Product:	[Applications] kate	Reporter:	Elmar Krieger <elmar>
Component:	general	Assignee:	KWrite Developers <kwrite-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	pascal.letourneau
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	RedHat Enterprise Linux
OS:	Linux
Latest Commit:		Version Fixed In:

Description Elmar Krieger 2005-03-24 15:17:51 UTC

Version:           2.3  (using KDE KDE 3.3.0)
Installed from:    RedHat RPMs
OS:                Linux

Hi!

I'm still having trouble with randomly disappearing source code fragments (see also bug 94027).
Finally, I could reproduce another case:

- Configure your keyboard such that you have to press '^' (ASCII 94) twice before the character appears (I think that's called 'dead keys enabled').
- Choose Selection mode 'persistent'
- Select a text
- Go somewhere else.
- Press '^' twice.
- The selected text disappears.
- The following message appears in the console from where I started kate:
sending IMStart with 0 chars to 0x9819fb0
sending IMEnd with 1 chars to 0x9819fb0, text=^

BTW, same problem with the other dead keys.

Again, thanks for your help!

Elmar

Comment 1 Thomas Friedrichsmeier 2007-12-06 12:44:58 UTC

Confirming in 3.5.8 and trunk.

Comment 2 Hamish Rodda 2007-12-06 14:09:07 UTC

This would be easily fixed, but the Qt docs say to do exactly this when receiving an input method event (clear selected text), see QInputMethodEvent (under 'perform the following steps')

Is there a particular reason why this behaviour is wrong in this case?

Comment 3 Thomas Friedrichsmeier 2007-12-06 14:17:43 UTC

Well, I don't think the Qt docs were thinking about persistent selections. Usually, when you have a persistent selection and you enter some text (inside or outside the selection), the selection - and most importantly, the selected text - is preserved. But if you enter a composed character (potentially far outside the persistent selection) the selected text is removed. I'd call that a bit "surprising".

Comment 4 Hamish Rodda 2007-12-06 14:35:18 UTC

Ok, I'll change this for persistent selections only then?

Comment 5 Thomas Friedrichsmeier 2007-12-06 14:37:48 UTC

Sure, for normal selections the behavior is correct.