DeltaEscher / editra

Automatically exported from code.google.com/p/editra
Other
0 stars 0 forks source link

Accented characters stops working after char deletion #507

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Delete any char (backspace or delete).
2. Type accented letter (tested with čćžšđ).
3.

What is the expected output? What do you see instead?
No letter is shown.
After pressing any other key (even metakeys) accented chars can be typed again.
This is manifested with the cyrillic letters too.

IMPORTANT!!! Please answer these questions for any and ALL bug reports

What version of the product are you using? On what operating system?
Platform Info: (linux2, python 2.6.4,wxGTK 2.8.10.1, unicode, gtk2,
wx-assertions-off, SWIG-1.3.29)

What method of install was your version installed with (Binary/Source)?
Current svn revision.

Original issue reported on code.google.com by igor.dejanovic@gmail.com on 21 Apr 2010 at 8:04

GoogleCodeExporter commented 8 years ago
Hello,

Is the delete part of your steps actually required to manifest this issue?

I can't reproduce this on my machine, what kind of keyboard do you have? Do you 
enter
accented characters with Alt+<SOME KEY> or does your keyboard have an Alt-Gr 
key on
it for accentuated character entry?

Thanks

Original comment by CodyPrec...@gmail.com on 25 Apr 2010 at 1:58

GoogleCodeExporter commented 8 years ago
Hello Cody,

Sorry for misinformation. Actually, those are not accented letters but foreign
letters. They are typed just by pressing a single key, no combination or 
sequence is
required. I have noticed this bug using Serbian keyboard layout. After char 
delete
operation, letters ćčđšž stop working. If I press any other key first I 
can type
those letters again. The same happens with cyrillic layouts (tested with 
Serbian,
Russian, Bugarian).
Weird thing is that with some layouts it works for some chars but not for the 
other.
For example with Hungarian layout I don't have any problems with letters 
éáú, but I
do with letter ő. Also, with German layout everything seems to work ok.
And yes, deleting any character triggers this bug.
This might be a platform specific issue but I don't have any Mac or Win machine 
at
hand to test it. 
I get this bug on current svn version on both of my linux machines (different 
distros).
Both machines are laptops with regular US keyboard.
Here is platform info for those machines:
First: python 2.6.4,GNOME 2.28.1, wxGTK 2.8.10.1, unicode, gtk2, 
wx-assertions-off
Second: python 2.6.5,GNOME 2.30.0, wxGTK 2.8.10.1, unicode, gtk2, 
wx-assertions-off 

Regards,
Igor

Original comment by igor.dejanovic@gmail.com on 25 Apr 2010 at 9:58

GoogleCodeExporter commented 8 years ago
Hi,

Sorry for the late reply finally getting around to investigate this again.

If possible could you add some debug printing to ed_stc.EditraStc.OnChar?

It would be interesting to see what key codes / meta keys are being sent in the 
different keyboard layouts. Its possible that the Serbian layout is sending 
some additional meta key that Editra is then getting confused about in the 
special key handling.

If possible add something like the following to the start ofthe OnChar method

{{{
print "KEYCODE:", evt.GetKeyCode(), "Alt:", evt.AltDown(), "Cmd:", 
evt.CmdDown(), "Shift:", evt.ShiftDown()
}}}

For regular key processing the code should fall into the last 'else' block in 
that method if it is not reaching there then some other code above is trapping 
the event.

Thanks,

Cody

Original comment by CodyPrec...@gmail.com on 8 Jun 2010 at 2:14

GoogleCodeExporter commented 8 years ago
Hello Cody,

I did as you suggested.
In OnChar I have 
{{{
        print "[OnChar] UNICODE:", evt.GetUnicodeKey() , "KEYCODE:", evt.GetKeyCode(), "Alt:", evt.AltDown(), "Cmd:", evt.CmdDown(), "Shift:", evt.ShiftDown()
}}}
at the beginning, right under the "key_code = evt.GetKeyCode()" line.
I have also inserted same line in OnKeyDown (with "OnKeyDown" prefix).
At the end of both functions (in the last else block) I am printing "UNHANDLED".

The event sequence is as follows:
1) Empty document openned.
2) Pressed "е" (letter is printed)
3) Pressed "д" (letter is printed)
4) Pressed backspace. (letter "д" is deleted).
5) Pressed "д" (noting happens).
6) Pressed shift.
7) Pressed "д" (letter is printed).

Here is the output of print commands.

[OnChar] UNICODE: 1077 KEYCODE: 0 Alt: False Cmd: False Shift: False
[OnChar] UNHANDLED
[OnChar] UNICODE: 1076 KEYCODE: 0 Alt: False Cmd: False Shift: False
[OnChar] UNHANDLED
[OnKeyDown] UNICODE: 8 KEYCODE: 8 Alt: False Cmd: False Shift: False
[OnKeyDown] : UNHANDLED
[OnChar] UNICODE: 1076 KEYCODE: 0 Alt: False Cmd: False Shift: False
[OnChar] UNHANDLED
[OnKeyDown] UNICODE: 306 KEYCODE: 306 Alt: False Cmd: False Shift: False
[OnKeyDown] : UNHANDLED
[OnChar] UNICODE: 1076 KEYCODE: 0 Alt: False Cmd: False Shift: False
[OnChar] UNHANDLED

Regards,
Igor

Original comment by igor.dejanovic@gmail.com on 9 Jun 2010 at 12:49

GoogleCodeExporter commented 8 years ago
Hmm, very strange problem. Its also weird that you don't get any keydown events 
before the OnChars for the letters and only for the control keys.

Will try some debugging.

Thanks for the additional info.

Cody

Original comment by CodyPrec...@gmail.com on 9 Jun 2010 at 1:32