Closed paaguti closed 1 year ago
Qt does not have the ability to detect if caps lock is on or off. Therefore the caps
flag is GTK-only. (It doesn't work in curses either.) I need to update the documentation. Do you have a particular need for caps lock state?
Interesting...
I'm using the hydra module and that will need to be reworked
On Sun, 4 Dec 2022 at 16:50, orbitalquark @.***> wrote:
Qt does not have the ability to detect if caps lock is on or off. Therefore the
caps
flag is GTK-only. (It doesn't work in curses either.) I need to update the documentation. Do you have a particular need for caps lock state?— Reply to this email directly, view it on GitHub https://github.com/orbitalquark/textadept/issues/301#issuecomment-1336448983, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZKU4C24SNYOX7S5UWELG3WLS4VJANCNFSM6AAAAAASTNKHPQ . You are receiving this because you authored the thread.Message ID: @.***>
-- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler
Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet
So I understand that Qt cannot detect if caps lock is on or off. But surely there is some way to distinguish between the inputs 'a' and 'A'?
For me personally, I can live without uppercase key bindings. But as the author of textadept-hydra, I'd like to make this work if it's possible.
You can simply check the shift
argument to distinguish between a lowercase vs. uppercase character. (Do be aware that Qt always gives key codes in upper-case form.) See https://github.com/orbitalquark/textadept/blob/8fdad81a16cb7c3fca54a47dc10024ef756ac2c5/core/keys.lua#L169-L171
The lack of Caps Lock detection means that recognized keys will be inverted if Caps Lock is on, but you can still distinguish between cases.
@mhwombat: I have come up with the following work-aroud:
-- Qt has no caps-lock :(
key = code >= 32 and code < 256 and string.char(code) or keys.KEYSYMS[code]
if not key then
return
end
-- Translate code -- shift not pressed means lowercase
if code >= 65 and code <= 90 then
key = string.char(code + (shift and 0 or 32))
shift=false
end
<hmm>but that ignores the caps-lock </hmm>
@orbitalquark: Maybe if we had a standard way of translating key pressed to beautified strings à la 'ctrl+A' in textadept, many modules like hydra might benefit...
Just an idea... so I isolated the code in core/keys.lua and provided a function called key_sequence()
. This makes the hydra module code much cleaner:
events.connect(events.KEYPRESS, function(code, shift, control, alt, cmd, caps)
--
-- If textadept provided a common key_sequence() translation:
--
local key_seq = keys.key_sequence(code, shift, control, alt, cmd, caps)
if not key_seq then return end
-- print(code, keys.KEYSYMS[code], shift, control, alt, cmd, caps)
-- ui.statusbar_text = key_seq
return handle_key_seq(key_seq)
end, 1)
Isn't that clean ;-) ?
I was thinking along the same lines as @paaguti; it would be best if textadept provided a way to determine what key was pressed that is independent of whether it was built with GTK or QT or whatever.
Even apart from the QT/GTK differences, I was thinking that it would be very beneficial to factor the keypress interpretation logic out of events.connect
into a separate function, and provide that in the API. Otherwise every module that handles keyboard events has to replicate it.
I agree that work needs to be done here. I have not yet decided on whether to:
events.KEYPRESS
handlers can/should call to interpret inputs.events.KEYPRESS
to emit interpreted keypresses.I hope to have something in by the release on New Year's.
IMvHO, the first is the least intrusive and add no migration woes (we have enough ;-) )
It is, but after auditing all use of events.KEYPRESS in Textadept, having to change them all to call another function doesn't seem very efficient. The 11-12 transition provides an opportunity to make these types of breaking changes. Believe me, adding to the migration guide is something I'd like to avoid :)
I have changed events.KEYPRESS
to emit only the string representation of the key pressed, e.g. ctrl+a
, ctrl+A
, ctrl+alt+a
, etc.: https://github.com/orbitalquark/textadept/commit/0abbc29f3f99580c724ff91eb1d2ca5dccc17a0f.
This change simplified Textadept's internal key handling code in many places, and greatly simplified emitting keys in the unit tests, so I felt it was a worthwhile change.
I am sorry in advance for any inconvenience this change causes. Let me know if I can be of any assistance in migrating old event handlers.
Don't worry. It is worthwhile :-) THANKS A TON, /PA
On Wed, 28 Dec 2022 at 16:56, orbitalquark @.***> wrote:
I have changed events.KEYPRESS to emit only the string representation of the key pressed, e.g. ctrl+a, ctrl+A, ctrl+alt+a, etc.: 0abbc29 https://github.com/orbitalquark/textadept/commit/0abbc29f3f99580c724ff91eb1d2ca5dccc17a0f .
This change simplified Textadept's internal key handling code in many places, and greatly simplified emitting keys in the unit tests, so I felt it was a worthwhile change.
I am sorry in advance for any inconvenience this change causes. Let me know if I can be of any assistance in migrating old event handlers.
— Reply to this email directly, view it on GitHub https://github.com/orbitalquark/textadept/issues/301#issuecomment-1366752920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZKU4DUXJUAEP6IDMNEJZDWPRPL5ANCNFSM6AAAAAASTNKHPQ . You are receiving this because you were mentioned.Message ID: @.***>
-- Fragen sind nicht da um beantwortet zu werden, Fragen sind da um gestellt zu werden Georg Kreisler
Headaches with a Juju log: unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet
This happens with a freshly compiled textadept using Qt on Linux.
I add the following key handler in .textadept/init.lua
I repeat the key sequence 'a', shift+'a':
Without caps lock, it prints:
With caps lock:
Apparently, the caps doesn't seem to be set at all