1 |
Okay, have been playing with this problem (ctrl+shift consumes |
2 |
characters) for the last three hours or so (it's been driving me crazy), |
3 |
and I now have a solution. Posting here in case others run into the |
4 |
problem and need to know how to disable this little mis-feature. |
5 |
|
6 |
Problem summary: |
7 |
|
8 |
The microsoft(natural) keyboard mapping, by default, maps shift+ctrl |
9 |
to "Multi_key", which is a "chording" composition mechanism that |
10 |
allows for entering extended character codes via a set of defined |
11 |
mappings. For instance type shift+ctrl, then 'co' produces a |
12 |
copyright symbol. This particular choice of keys, however, means |
13 |
that simple editing operations involving shift and control can wind |
14 |
up entering the chording-key mode. |
15 |
|
16 |
Problem source: |
17 |
|
18 |
Turns out that this is an XWindows "feature" which was enabled by |
19 |
the (AFAIK automatically generated) configuration options in my |
20 |
xorg.conf keyboard section: |
21 |
|
22 |
Section "InputDevice" |
23 |
Identifier "Keyboard0" |
24 |
Driver "keyboard" |
25 |
Option "XkbModel" "microsoftpro" |
26 |
Option "XkbLayout" "us" |
27 |
Option "XkbVariant" "winkeys" |
28 |
EndSection |
29 |
|
30 |
winkeys doesn't actually appear to be defined anywhere, which leaves |
31 |
the definition as the "normal" microsoftpro layout (leaving out |
32 |
winkeys, or defining any other unrecognised variant has the same |
33 |
effect, effectively selecting "basic"). |
34 |
|
35 |
Solution 1: |
36 |
|
37 |
Switch the XkbVariant setting to "nodeadkeys". This eliminates all |
38 |
of the undesirable features of the mapping, but also eliminates a |
39 |
number of the commonly useful key-mappings such as the Windows keys, |
40 |
the "Menu" key, etceteras. |
41 |
|
42 |
Solution 2: |
43 |
|
44 |
Leave XkbVariant setting as "basic" (or "winkeys" if you prefer). |
45 |
Create a file like this in your home directory: |
46 |
|
47 |
8<_____ .xmodmap.rc ___________ |
48 |
|
49 |
keycode 115 = Super_L Multi_key |
50 |
keycode 116 = Super_R Multi_key |
51 |
keycode 109 = Control_R |
52 |
|
53 |
and add the following line to your .xinitrc file (you may not have a |
54 |
.xinitrc file yet, if not, read up on what to put in it, at the very |
55 |
least you'll want a call to startkde in it, read this *before* |
56 |
editing the file, as a messed up .xinitrc can prevent you from |
57 |
logging in (annoying if you're using xdm for your login manager)): |
58 |
|
59 |
xmodmap .xmodmaprc |
60 |
|
61 |
This file maps the "compose key" (multi-key) mode to |
62 |
shift+WindowsKey (either one), and eliminates the control-with-shift |
63 |
as a multi-key mapping. |
64 |
|
65 |
If someone has a better approach, that would be cool to know about too. |
66 |
Adding the xmodmap call to .xinitrc means that the whole system operates |
67 |
as-desired wrt this feature, but if I'm reading correctly xmodmap is not |
68 |
the "proper" way to do this kind of thing any more. |
69 |
|
70 |
Enjoy yourselves, |
71 |
Mike |
72 |
|
73 |
Mike C. Fletcher wrote: |
74 |
|
75 |
> This is probably going to seem trivial, but it is driving me a little |
76 |
> buggy. I'm a programmer, so I spend almost my whole day editing code, |
77 |
> including a large amount of cutting, copying and pasting. So I do a |
78 |
> lot of key-sequences where I'm holding down shift(+ctrl)+arrows to |
79 |
> select, then depressing control to start a ctrl+c or a ctrl+x sequence. |
80 |
> |
81 |
... <snip> |
82 |
________________________________________________ |
83 |
Mike C. Fletcher |
84 |
Designer, VR Plumber, Coder |
85 |
http://www.vrplumber.com |
86 |
http://blog.vrplumber.com |
87 |
|
88 |
|
89 |
-- |
90 |
gentoo-desktop@g.o mailing list |