From the old X.Org/X Consortium bug records - no patch was given though.
[An excellent starter project for someone wanting to get started working on
Date: Wed, 12 Jul 1995 14:58:52 EST
From: "Kaleb S. KEITHLEY" <email@example.com>
Subject: xmodmap: look up modifiers using the keysyms they're bound to.
### bug number: 7513
### area: xmodmap
### severity: enhancement
### priority: low
R6, public-patch-12, all fix-trackers to date
CLIENT MACHINE and OPERATING SYSTEM:
Look up modifiers using the keysyms they're bound to.
Enhance the language to look up modifiers by the keysym they are bound
to, e.g. if Mod1Mask is bound to Alt_L and Alt_R, allow references to
"Alt_L" or "Alt_R" to substitute for "mod1". Nominally this would only
be useful for the 'clear' and possibly the 'remove' operation. As an
example, given the following modifier map:
xmodmap: up to 2 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x1a), Shift_R (0x61)
lock Caps_Lock (0x1c)
control Control_L (0x19), Control_R (0x60)
mod1 Alt_L (0x21), Alt_R (0x41)
mod2 Num_Lock (0x7e)
mod3 Scroll_Lock (0x67)
Something someone might want to do is clear all the keysyms from mod1,
so they'd issue an 'xmodmap -e "clear mod1"'; Perhaps they would do this
because they want to assign a different modifier to the Alt keys, and
to do this they have to have explicit knowledge that the Alt keys are
bound, in this case, to mod1. Ideally what they'd really like to do is
is: 'xmodmap -e "clear Alt_L"' (or even just 'xmodmap -e "clear Alt"')
or 'xmodmap -e "clear Num_Lock"' and have xmodmap do a lookup to find
that Alt_L is bound to mod1 and then perform an equivalent 'xmodmap -e
"clear mod1"'. In a 'xmodmap -e "remove Alt_R"' it would look up the
modifier using "Alt_R" and then perform the equivalent 'xmodmap -e
"remove mod1 = Alt_R"'.
In some respects this has some similarities to the way that 'xmodmap
-e "keysym = ..."' looks up the keycode for the keysym and then does
a keycode operation.
Doing this would make xmodmap a little more flexible in that it doesn't
require knowledge about the specific or current state of the modifier
map. Then more generic .xmodmaprc scripts could be written that would
work with any modifier map that a particular vendor might be shipping
or that any user might be using.
I'm not sure this is worthwhile. It seems like it will allow for
misconceptions and further confusion about input.
Alan, do you have any strong feelings about this?
I honestly can't see how this would really help anyone.
(In reply to comment #1)
> Alan, do you have any strong feelings about this?
No, I was just passing it on from the old bug db.
on Jan 21, 2017 at 08:29:21.
(provided by the Example extension).