Bug 44033 - Add option to map Caps to Shift_L (non-locking!)
Summary: Add option to map Caps to Shift_L (non-locking!)
Status: RESOLVED WONTFIX
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium enhancement
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-21 14:21 UTC by Erich Schubert
Modified: 2011-12-26 04:39 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Erich Schubert 2011-12-21 14:21:36 UTC
A rather obvious alternative mapping for the "dreaded" caps lock key is to make it another Shift_L key, without locking. (Actually, I'm just forwarding this request, after seeing that it is just a matter of a few rather obvious lines).

Why can it be mapped to Hyper_L and Super_L, but not e.g. to Shift_L, Meta_L and such? It can be switched with Control_L, too.

I can also imagine that some people would prefer to have it another "Tab" button, since that is also easy to hit instead.

On a side node, I was unable to understand the differences between:

caps:capslock
Caps Lock toggles normal capitalization of alphabetic characters

caps:shift
Caps Lock acts as Shift with locking. Shift "pauses" Caps Lock

caps:internal
Caps Lock uses internal capitalization. Shift "pauses" Caps Lock

These could be redundant, or may need further explanation.
Comment 1 Sergey V. Udaltsov 2011-12-24 12:59:39 UTC
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?
Comment 2 Erich Schubert 2011-12-24 13:48:09 UTC
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.
Comment 3 Sergey V. Udaltsov 2011-12-24 13:55:32 UTC
> 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?
Comment 4 Erich Schubert 2011-12-24 14:01:24 UTC
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.
Comment 5 Sergey V. Udaltsov 2011-12-24 14:10:46 UTC
You could try doing it with $HOME/.xmodmap file.
Comment 6 Erich Schubert 2011-12-24 14:21:37 UTC
We used to do it that way, before Gnome broke it.
Comment 7 Erich Schubert 2011-12-24 14:23:17 UTC
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.
Comment 8 Sergey V. Udaltsov 2011-12-24 14:25:23 UTC
> 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.
Comment 9 Erich Schubert 2011-12-24 14:50:17 UTC
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.
Comment 10 Sergey V. Udaltsov 2011-12-26 04:39:41 UTC
> 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).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.