On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:
2009/9/25 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 23 Sep 2009 09:35:32 +1000, Lex wrote:
Hi,
I am having difficulty with Unicode code point insertion. Basically it doesn't work and I can't see how it could as described in the manual.
I have control-Shift-u undefined, but since on_key_press_event catches keybindings before they get to GTK, all control-shift keybindings for hex characters (a-f) must be undefined. This means many of the find
Ouch. I guess I never noticed it as I use always Ctrl-Shift-Alt-u for some reason, not sure whether it worked only this way long time or whether it is because I could never remember the exact key combo and so just pressed all :).
Perfectly reasonable, but unfortunately that doesn't work for me either :-(
Regarding a solution, two things come to my mind: a) we add some more super magic to the keypress handler function trying to detect if the user is currently at inserting an unicode sequence and then ignore other keybindings until finished b) we mention in the manual that Ctrl-Shift-Alt is preferred as it prevents unintentional triggering of defined shortcuts
But well, b) is only of limit use as it still would trigger shortcuts defined as Ctrl-Shift-Alt-[a-f]. a) might be a solution but has some potential to get quite hacky.
Does anyone has an idea for a solution c)? :)
keybindings must be undefined. But even then, with control-shift held digits are seen as !@#$%^&*() and rejected.
Can't reproduce this here, even with Ctrl-Shift pressed, digits are still digits.
Hmmm, weirder & weirder I uncommented the geany debug in key_press_event & typed into an empty document (not entering Unicode, just typing) got the following, # comments are mine
** INFO: 65507 (65507) 0 (16) # Press & hold Ctrl ** INFO: 65505 (65505) 4 (20) # Press & hold shift ** INFO: 33 (33) 5 (21) # Press 1 keycode 33 is ! state 5 is Ctrl&Shift shows as ! ** INFO: 64 (64) 5 (21) # Press 2 keycode 64 is @ state 5 is Ctrl&Shift but does not show anything !!!!!!!!!! ** INFO: 35 (35) 5 (21) # Press 3 keycode 35 is # state 5 is Ctrl&Shift shows # ** INFO: 36 (36) 5 (21) # Press 4 keycode 36 is $ state 5 is Ctrl&Shift shows $ ** INFO: 37 (37) 5 (21) # Press 5 keycode 37 is % state 5 is Ctrl&Shift shows % ** INFO: 94 (94) 5 (21) # Press 6 keycode 94 is ^ state 5 is Ctrl&Shift but does not show anything !!!!!!!!!!!!!!! ** INFO: 38 (38) 5 (21) # Press 7 keycode 38 is & state 5 is Ctrl&Shift shows & ** INFO: 42 (42) 5 (21) # Press 8 keycode 42 is * state 5 is Ctrl&Shift shows * ** INFO: 40 (40) 5 (21) # Press 9 keycode 40 is ( state 5 is Ctrl&Shift shows ( ** INFO: 41 (41) 5 (21) # Press 0 keycode 41 is ) state 5 is Ctrl&Shift shows )
So there is no way that they could be interpreted as digits, they are all punctuation keycodes??? Could the difference be due to different keyboard maps because you have a European keyboard and I have a US ASCII keyboard?? And why arn't @ and ^ inserted into the file??
The above list is the same as I get on my system, so far so good. E.g. if I press Ctrl-Shift-5 I get the same as you, keycode 37 and state 21, cleaned 5. The difference is that if I press Ctrl-Shift-u before and then pressing 5 while holding Ctrl-Shift I still get keycode 37 but it is inserted as 5 as part of the Unicode string. So, apart from the triggering of other keybindings, this is what I'd expect. Can you confirm this behaviour so far?
PS Found a workaround for entering Unicode using the Gnome character map, but its very invasive.
Yeah, I don't see this as any alternative, not even a workaround.
Regards, Enrico