superKey=mod1 oddity

[ghost]

When you set superKey to mod1, it seems to conflict or otherwise mess with, for instance, a terminal's readline bindings.

[AdaShoelace]

I think this might be one of the reasons i3 restrict superKey to either meta or ctrl. Perhaps that would be a reasonable way to solve the issue for hadlock as well?

[ghost]

I haven't used i3 and didn't know about the restriction. But mod1 works as expected with xmonad and spectrwm.

[ghost]

mod1 also works with sway

[AdaShoelace]

I haven't actually used neither xmonad nor spectrwm but do they have a seperate service for input and then send them to the wm via unix sockets using their own protocol? I have seen a lot of wm do it this way, berryWM for example.

[ghost]

No, and mod1 also works with dwm.

[AdaShoelace]

How would xmonad and dwm act if you were to bind a wm-action to eg Ctrl-a? Wouldn't that override the readline instruction if you're having a terminal open? And if this is the case perhaps the only reasonable option is to bind the wm-keys in a way that doesn't interfere with other applications?

I tried using both Ctrl and Alt as superKey and for the cases without an extra modifier Ctrl gave me problems in a terminal but Alt didn't. Was this what you meant initially?

[ghost]

After more testing, I'd say the issue isn't with mod1. In fact, the oddity happens with the default (superKey=super), too. If you have some binding like superKey+Shift+$ where $ can be anything in a-z, and you press superKey+$ (without Shift), then you get the odd effect. I cannot tell if the terminal and shell get the full code, but the shell reacts as if there was input and it didn't know what to do with it, so the terminal's cursor flashes.

The reason I first noticed this with superKey=mod1 is because I was trying to input mod1+d in the shell and was surprised to see a flashing cursor without any readline effect. I think it happens because I have a custom binding for superKey+Shift+d.

[AdaShoelace]

After more testing, I'd say the issue isn't with mod1. In fact, the oddity happens with the default (superKey=super), too. If you have some binding like superKey+Shift+$ where $ can be anything in a-z, and you press superKey+$ (without Shift), then you get the odd effect. I cannot tell if the terminal and shell get the full code, but the shell reacts as if there was input and it didn't know what to do with it, so the terminal's cursor flashes.

The reason I first noticed this with superKey=mod1 is because I was trying to input mod1+d in the shell and was surprised to see a flashing cursor without any readline effect. I think it happens because I have a custom binding for superKey+Shift+d.

This is very strange. I've investigated it further and realized that different terminals act differently in this aspect. Alacritty acts exactly as intended for me (alt + d deletes the rest of the line if not bound in hadlock). Xterm on the other hand acts strange in this scenario, it starts inserting umlaut letters eg åäö.

[ghost]

I saw flashing with Alacritty v0.3.3-310-g2b2b2bf and haven't tested other emulators yet. Is it conceivable that hadlock detects Mod1+d but mistakenly sends Mod1+Shift+d to the terminal?

[AdaShoelace]

Would you be able to paste the relevant parts of your config. I can't seem to recreate the issue.