textadept-qt: strange behaviour in keypress events

[paaguti]

This happens with a freshly compiled textadept using Qt on Linux.

I add the following key handler in .textadept/init.lua

events.connect(events.KEYPRESS, function(code, shift, control, alt, cmd, caps)
   print(code, shift, control, alt, cmd, caps)
end)

I repeat the key sequence 'a', shift+'a':

Without caps lock, it prints:

65	false	false	false	false	nil
65	true	false	false	false	nil

With caps lock:

65	false	false	false	false	nil
65	true	false	false	false	nil

Apparently, the caps doesn't seem to be set at all

[orbitalquark]

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?

[paaguti]

Interesting... I'm using the hydra module and that will need to be reworked <hhhmmmm/>.

…

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 <#301 (comment)>, 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

[mhwombat]

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.

[orbitalquark]

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.

[paaguti]

@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>

[paaguti]

@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 ;-) ?

[mhwombat]

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.

[mhwombat]

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.

[orbitalquark]

I agree that work needs to be done here. I have not yet decided on whether to: * Create an API function that all `events.KEYPRESS` handlers can/should call to interpret inputs. * Create a new event that emits interpreted keypresses. * Repurpose `events.KEYPRESS` to emit interpreted keypresses. * ? I hope to have something in by the release on New Year's.

[paaguti]

IMvHO, the first is the least intrusive and add no migration woes (we have enough ;-) )

[orbitalquark]

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 :)

[orbitalquark]

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.

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.

[paaguti]

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 <0abbc29> . 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 <#301 (comment)>, 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