You are not logged in.
I've been using i3 with Caps_Lock as my modifier key for a while now. After running pacman, Caps_Lock is often is turned back on. I think this is best resolved with a pacman hook, and I'd appreciate a second look at what I'm doing.
On i3 startup, my user runs xmodmap on a file that contains
keycode 66 = Hyper_L NoSymbol NoSymbol NoSymbol
clear lock
clear mod4
add mod4 = Hyper_L
clear mod5
add mod5 = Super_L*edit, forgot to include the last two lines here, which also sets the Super key.
1) I've done this for years, so I think it's alright.
2) To revert changes, I'm considering the following pacman hook. Hopefully there aren't any gotchas I'm missing with this approach.
[Trigger]
Operation = Install
Operation = Upgrade
Operation = Remove
Type = Package
Target = *
[Action]
Description = Killing Caps_Lock with xmodmap...
When = PostTransaction
Exec = /usr/bin/sh -c 'xmodmap /path/to/file'Thank ye.
Last edited by bestfriend (2023-11-29 08:26:11)
Offline
If you ask for a purely technical opinion: given all the limitations below, in particular its unreliability, it may do what you expect it to do.
If you ask for a general opinion, then my opinion is: this is not the right solution. Neither pacman nor pacman hooks should (or directly can) modify per-user environment. Both pacman and its hooks are meant to do system-level management only.
This hook is either not going to work at all (xmodmap is going to miss required environment variables), or — if run with sudo from inside an X session — coincidentally receive the variables through sudo. But that is by no means reliable and depends entirely on the context in which pacman happens to be invoked.⁽¹⁾
Inside a specific setup, assuming that you would never distribute this hook,⁽²⁾ you may try building a Ruby Goldberg machine passing variables around. But IMO it would be better to determine, what causes the initial malfunction. For the same reason I find your solution wrong, the problem shouldn’t occur in the first place: pacman should not have this kind of an effect on your environment.
____
⁽¹⁾ I am actually a bit surprised that pacman even passes these variables to hooks.
⁽²⁾ The condition is due to reasons stated earlier: expectations about pacman and its hooks, as well as near impossibility to perform this properly in more complex setups.
Last edited by mpan (2023-11-29 03:15:24)
Paperclips in avatars? | Sometimes I seem a bit harsh — don’t get offended too easily!
Offline
This hook is either not going to work at all (xmodmap is going to miss required environment variables), or — if run with sudo from inside an X session — coincidentally receive the variables through sudo. But that is by no means reliable and depends entirely on the context in which pacman happens to be invoked.⁽¹⁾
Good points, thanks.
...the problem shouldn’t occur in the first place: pacman should not have this kind of an effect on your environment.
Looks like I have an XY problem. Note that pacman doesn't always cause this issue. It often occurs during a larger update, though, which makes it unclear what package is triggering the change.
Offline
Yes "should" …
https://bugs.archlinux.org/task/77789
On i3 startup, my user runs xmodmap on a file that contains
That's horrible ![]()
Does "setxkbmap -option caps:hyper" do what you want?
More things you can do with that key (personal favorite is as xcompose key):
grep -i caps /usr/share/X11/xkb/rules/baseThen hand yourself a https://wiki.archlinux.org/title/Xorg/K … tion_files so the configuration will automatically apply on every keyboard that appears anytime.
Offline