<dnkl>
that's what I'm seeing, and I get the expected output (text only), but *only on the MR, not the master branch*
<dnkl>
Arnavion: done
<dnkl>
rjarry: alternatively, if you really are on the right branch, the issue is that your keymap is reporting shift as enabled, but not consumed. That too would explain what you're seeing
<dnkl>
130 (in the kitty kbd) isn't num-lock only, but shift+num-lock
<dnkl>
something that perhaps _should_ be changed in foot is that we currenly report locked modifiers as enabled modifiers, if there are other active, non-consumed, modifiers (e.g. alt, or ctrl)
<dnkl>
kitty does the same however
<dnkl>
perhaps we should change foot to only consider "pressed" keys when reporting kitty modifiers
<dnkl>
that would fix another issue I'm seeing; numlock+space (that is, *holding* num-lock), for example, doesn't report as an escape sequence. It probably should
<dnkl>
not sure if that would mess up e.g. sticky keys though...
<dnkl>
or maybe reporting locked keys is how the protocol is supposed to work... leave it up to the application to decode
<Arnavion>
Thanks
luca has quit [Remote host closed the connection]
luca has joined #foot
<dnkl>
so, the kitty kbd specification says this: "The modifiers optional parameter encodes any modifiers pressed for the key event".
<rjarry>
dnkl: I am positive that I am on the correct branch
<dnkl>
rjarry: alright... but as long as your keymap doesn't report shift as being consumed, there's nothing foot can do
<rjarry>
:(
<rjarry>
am I testing this correctly ? do I need to enable kitty magic keyboard protocol before pressing shift+space ?
<dnkl>
you'll obviously want to enable the kitty keyboard protocol if you want to see how foot encodes the key-press in the kitty protocol
<dnkl>
but it won't change how modifiers are reported by xkb (and thus logged by foot)
<rjarry>
that was my question yes
<rjarry>
I have no idea why is xkb reporting this
<rjarry>
maybe because I disabled caps lock ?
<dnkl>
no idea either
<dnkl>
I pushed another commit on the kitty-is-text branch; it changes how we look at the modifiers, from all modifiers being enabled, to only those being depressed.
<dnkl>
I don't think it'll change what you're seeing rjarry , since it shouldn't affect the consumed state of shift
<dnkl>
but might be worth testing anyway
<rjarry>
dnkl: I will have a look later, thanks !
<dnkl>
while I believe the last commit implements the spec, I'm not it's what the specification *intended*
<dnkl>
alright, he updated the specification to be more clear - we should be reporting *enabled* modifiers. Not just pressed
<dnkl>
he also admitted kitty wasn't following the specification 100%. So we shouldn't blindly follow kitty's implementation
<dnkl>
I'll revert the last commit, and try to follow the specification more closely
<dnkl>
this means you *will* get escape sequences whenever e.g caps or NumLock are enabled
<dnkl>
rjarry: see comments above (i.e not much point in testing the last commit since it'll be reverted)
<dnkl>
rockorager: this is probably something you'd like to take notice of too: the kitty spec was just updated to clarify locked modifiers
<dnkl>
locked modifiers _should_ always cause the corresponding bit in the kitty key event to be set. When *enabled*. I.e. not just when they are pressed
<dnkl>
this means having num-lock enabled will cause *all* key events to be escape sequence based, rather than text based
<dnkl>
same is true for caps-lock
<dnkl>
alright, just pushed another commit to kitty-is-text, with updated behavior for locked modifiers
Biolunar has quit [Quit: brb]
Biolunar has joined #foot
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #foot
jmcantrell has quit [Quit: WeeChat 4.2.1]
jmcantrell_ is now known as jmcantrell
bookworm has quit []
<dnkl>
PR rebased onto latest master, and PR description updated