<thatOT>
Helloo guys, I'm trying to get foot's window title to be named after the current path/running command. So it looks cool in somebar. My shell is bash. foot 1.16.2 -pgo +ime +graphemes -assertions
thatOT has quit [Quit: Client closed]
rrogalski has quit [Ping timeout: 264 seconds]
h-erectus has joined #foot
<dnkl>
qyliss: just complete all paths. I doubt anything else is worth the trouble
<dnkl>
rjarry: guessing kitty doesn't query xkb for consumed modifiers, but either hardcodes shift, or kitty is using middleware that hardcodes it.
<dnkl>
I'm also on libxkbcommon 1.6.0, arch Linux. Could be interesting to test on other compositors. I'm on River
cbb has joined #foot
<dnkl>
rjarry: I see the same thing as you, if I set the layout to "us", or "us,se". But not when I set it to "se", or "se,us". "fr" also misbehaves
<dnkl>
so, it's the keymap
h-erectus has quit [Ping timeout: 260 seconds]
hspak has quit [Ping timeout: 246 seconds]
<dnkl>
rjarry: looking through the keymap files, I believe the issue is that the default mapping for space is single-level only. You can see this in /usr/share/X11/xkb/symbols/pc, near the top.
hspak has joined #foot
<dnkl>
the "se" layout overrides this definition, and adds four modifier levels to the space key
<dnkl>
neither the "us" nor the "fr" layout does this, but instead relies on the defaults from "pc"
<dnkl>
also, we can compare with the backspace key - it has two levels defined in "pc". It behaves as expected - shift is consumed.
<dnkl>
whether or not this should be seen as a layout bug, or if this is intended behavior - 🤷
<dnkl>
also no idea why/how NumLock affects it
<dnkl>
but I guess I could be wrong about all the above 😂
<dnkl>
guess one way forward would be to define a custom layout, based on "us", but that overrides the space key to have two modifiers levels
<dnkl>
yeah, that's it. It's though to define a new layout based on "us(basic)", and copy SPCE from the "se(se)" layout. shift+space then behaves as expected
<dnkl>
s/it's though/it's enough/
<dnkl>
and, to bring it all the way home; you don't need all four levels from the "se" layout. Just two is enough (i.e similar to the default definition of backspace in "pc")
<rjarry>
dnkl: i began to suspect something like this but you beat me to the RCA :)
<rjarry>
but can we assume that xkb layouts will not change ?
<rjarry>
shouldn't foot do something to produce consistent sequences regardless of xkb layout quirks?
<dnkl>
they won't change unless someone brings it to their attention? I.e maybe try to figure out why the backspace definition has two levels, but not space. Must be a reason for that
<dnkl>
I really don't want to start assuming things in foot. So no, I'm not going to add quirks. Remember, foot can't see if your using one of the default layouts, or a custom one. We add a quirk, it'll apply to *all* keymaps
<dnkl>
rjarry: from what I can see, backspace was extended for reasons *very* similar to what we're discussing
<dnkl>
it's not the same; the backspace issue was the XKB didn't map backspace at all when combined with shift
<dnkl>
but it's at least similar
<dnkl>
if you really want this fixed, I think it would be worth trying to report it to the xkeyboard-config project. That's where all the definitions are (libxkbcommon just parses them)
<rjarry>
ok, in the meantime, I'll have a look at changing my layout to mimick what the se layout does
<rjarry>
surprisingly, there are some fr layouts with multi level space key definitions
<rjarry>
for example altgr+space produces non-breaking space
<rjarry>
I override this in my layout because it is very annoying when writing code
<dnkl>
there are some us-based layouts as well. Just not the default one...