[Geany-devel] Unicode code entry

Enrico Tröger enrico.troeger at xxxxx
Sun Sep 27 14:54:22 UTC 2009


On Fri, 25 Sep 2009 11:12:07 +1000, Lex wrote:

>2009/9/25 Enrico Tröger <enrico.troeger at 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

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20090927/6129a019/attachment.pgp>


More information about the Devel mailing list