Bug 44033

These options are more of historic interest than practical use.

About non-blocking Shift_L: it is really obvious, but is there actual demand? Who and why would make Caps extra Shift_L, if "real" Shift_L is just below it?

In fact I added this on my dads PC. He complained that he keeps hitting Caps Lock when he meant to hit Shift. Mapping it to "none" didn't yet make him entirely happy.

It's not so much about adding functionality for "pro" users, but about avoiding certain errors, such as hitting the adjacent key.

> In fact I added this on my dads PC. He complained that he keeps hitting Caps
> Lock when he meant to hit Shift. Mapping it to "none" didn't yet make him
> entirely happy.
> 
> It's not so much about adding functionality for "pro" users, but about avoiding
> certain errors, such as hitting the adjacent key.
I am not sure this exotic case is worth making available for everybody (upstream). And why is "none" bad for your dad?

Well, he meant to get "shift", not "nothing".

Is there any easy way to add such an option locally without modifiying the existing rules files? I didn't find an easy way to add the local modification so it shows up in Gnome except by modifying around 5 files, and those changes are likely to be overwritten on the next system update... and I don't want to redefine the entire keyboard, just override this single keybinding, in a way that is reliable with Gnome.

You could try doing it with $HOME/.xmodmap file.

We used to do it that way, before Gnome broke it.

Ideally, xkb should provide an extension mechanism. After all, you are supposed to be able to switch between keyboard configurations (in particular different language layouts) on the fly, and these might need different such modifications. So the user should have a way to add custom modifications without completely redoing full keyboard layouts himself.

> Ideally, xkb should provide an extension mechanism. After all, you are supposed
> to be able to switch between keyboard configurations (in particular different
> language layouts) on the fly, and these might need different such
> modifications. So the user should have a way to add custom modifications
> without completely redoing full keyboard layouts himself.
Formally, xkb does provide that. There is -I option in xkbcomp and setxkbmap utilities. But DEs do not support that.

Even then you will need to duplicate the complete rules file to just add a single option, won't you?
I had tried to copy evdev.lst, evdev.xml, evdev, and the capslock files from /usr/share/X11/xkb to /etc/xkb, but it seems that only the first path is searched. And still, this is around 260kb of files to copy (and eventually resync with the next version!), just for a 100 bytes (500 bytes with the XML metadata) addition to it.

But we're trailing off the original proposal of adding a "map caps to shift_l" option.

> Even then you will need to duplicate the complete rules file to just add a
> single option, won't you?
As I said, "formally". In reality this is not usable, I totally agree. You can file a separate bug against xkbcomp or xorg (Input/Keyboard) around that. If it does not exist.

> But we're trailing off the original proposal of adding a "map caps to shift_l"
> option.
I am not inclined to add that option just for a single person.

What about xmodmap way? How did gnome broke it? Is there an open bug? It should be fixed (and I am more willing to help you with that bug - because it is my code in libxklavier).