Caps Lock affects Ctrl+keys

Caps Lock affects Ctrl+keys

[Yuri Khan]

Hello list,

I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
behave as if I pressed Ctrl+Shift+letter. My expectation is that Caps
Lock should not affect any control modifiers (Ctrl, Meta, Super,
Hyper), but should affect normal character input (no modifiers or just
Shift) and might affect higher levels input (Level3, Level5 and any
combinations thereof with or without Shift).

$ emacs -Q

M-: (read-key) RET
press Ctrl+z
# 26 (#o32, #x1a)
(so far so good)

M-: (read-key) RET
press Ctrl+Shift+z
# 33554458 (#o200000032, #x200001a)
(ok)

M-: (read-key) RET
press Caps Lock to turn it on
press Ctrl+z
# 33554458 (#o200000032, #x200001a)
(expected: 26 (#o32, #x1a))

M-: (read-key) RET
with Caps Lock still on
press Ctrl+Shift+z
# 26 (#o32, #x1a)
(expected: 33554458 (#o200000032, #x200001a))

This is on GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2),
in Ubuntu 13.10, GUI mode. (In -nw mode, I get 26 no matter whether
Shift is pressed and/or Caps is on, which is understandable because in
that mode the terminal emulator handles all keyboard input.)

Does anybody else observe this? Should I report a bug? Is there an
easy workaround?

Re: Caps Lock affects Ctrl+keys

[Jude DaShiell]

On Mon, 20 Jan 2014, Yuri Khan wrote:

> Hello list,
> 
> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
> behave as if I pressed Ctrl+Shift+letter. My expectation is that Caps
> Lock should not affect any control modifiers (Ctrl, Meta, Super,
> Hyper), but should affect normal character input (no modifiers or just
> Shift) and might affect higher levels input (Level3, Level5 and any
> combinations thereof with or without Shift).
> 
> $ emacs -Q
> 
> M-: (read-key) RET
> press Ctrl+z
> # 26 (#o32, #x1a)
> (so far so good)
> 
> M-: (read-key) RET
> press Ctrl+Shift+z
> # 33554458 (#o200000032, #x200001a)
> (ok)
> 
> M-: (read-key) RET
> press Caps Lock to turn it on
> press Ctrl+z
> # 33554458 (#o200000032, #x200001a)
> (expected: 26 (#o32, #x1a))
> 
> M-: (read-key) RET
> with Caps Lock still on
> press Ctrl+Shift+z
> # 26 (#o32, #x1a)
> (expected: 33554458 (#o200000032, #x200001a))
> 
> This is on GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2),
> in Ubuntu 13.10, GUI mode. (In -nw mode, I get 26 no matter whether
> Shift is pressed and/or Caps is on, which is understandable because in
> that mode the terminal emulator handles all keyboard input.)
> 
> Does anybody else observe this? Should I report a bug? Is there an
> easy workaround?
> 
No, the problem is in the Linux kernel emacs is by no means unique in 
this behavior.
> 

jude <jdashiel@shellworld.net>

Re: Caps Lock affects Ctrl+keys

[Yuri Khan]

On Mon, Jan 20, 2014 at 9:47 PM, Jude DaShiell <jdashiel@shellworld.net> wrote:
>>
>> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
>> behave as if I pressed Ctrl+Shift+letter.
>>
> No, the problem is in the Linux kernel emacs is by no means unique in
> this behavior.

Kernel? I don’t think so. xev(1) reports different output when I press
Ctrl+Shift+Z and Ctrl+Z with Caps on. Firefox opens a new tab on
Ctrl+T (and restores the last closed tab on Ctrl+Shift+T), no matter
if Caps is on or off.

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> No, the problem is in the Linux kernel emacs is by
>> no means unique in this behavior.
>
> Kernel? I don't think so. xev(1) reports different
> output when I press Ctrl+Shift+Z and Ctrl+Z with Caps
> on. Firefox opens a new tab on Ctrl+T (and restores
> the last closed tab on Ctrl+Shift+T), no matter if
> Caps is on or off.

Some information on this, see if you can figure it out:

In keymaps(5), there is some information what to do
with caps:

> Which of the actions bound to a given key is taken
> when it is pressed depends on what modifiers are in
> effect at that moment.  The keyboard driver supports
> 9 modifiers. These modifiers are labeled (completely
> arbitrarily) Shift, AltGr, Control, Alt, ShiftL,
> ShiftR, CtrlL, CtrlR and CapsShift.  Each of these
> modifiers has an associated weight of power of two
> according to the following table:

              > modifier             weight
              > Shift                     1
              > AltGr                     2
              > Control                   4
              > Alt                       8
              > ShiftL                   16
              > ShiftR                   32
              > CtrlL                    64
              > CtrlR                   128
              > CapsShift               256

# swap control and caps
keycode  58 = Control
keycode  29 = Caps_Lock

# always enable on caps, disable on either shift
keycode  42 = Uncaps_Shift # left shift
keycode  54 = Uncaps_Shift # right shift
keycode  58 = Caps_On      # caps

Note: Get the keycodes with 'showkey', then update
changes to the remap file with 'sudo loadkeys'. If
'showkey' complains it can't get access to the console
it means you are running it for example in tmux, if so
use 'sudo showkey' (every time) or 'sudo chmod u+s
/usr/bin/showkey' to make it work ever since.

With 'showkey -s', it doesn't seem to be possible to
get what you describe.

--
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Jude DaShiell]

On Mon, 20 Jan 2014, Yuri Khan wrote:

> On Mon, Jan 20, 2014 at 9:47 PM, Jude DaShiell <jdashiel@shellworld.net> wrote:
> >>
> >> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
> >> behave as if I pressed Ctrl+Shift+letter.
> >>
> > No, the problem is in the Linux kernel emacs is by no means unique in
> > this behavior.
> 
> Kernel? I don?t think so. xev(1) reports different output when I press
> Ctrl+Shift+Z and Ctrl+Z with Caps on. Firefox opens a new tab on
> Ctrl+T (and restores the last closed tab on Ctrl+Shift+T), no matter
> if Caps is on or off.
> 
I'm using linux-speakup over here and I don't use g.u.i. stuff on Linux I 
have to do that at work and shouldn't have to at home.  The only way I 
found to clear this state was to reboot the amd64 k8 athelon and that 
cleared it.  If I don't do that, I have to hit shift and hold shift down 
for each lower case letter otherwise even if capslock is off and I am not 
holding the shift key down, the only thing that comes out is uppercase 
letters when I type letters and I first noticed this in another linux 
application having nothing to do with emacs.

> 

jude <jdashiel@shellworld.net>

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Jude DaShiell <jdashiel@shellworld.net> writes:

> I'm using linux-speakup

Did you try that for this particular problem or do you
use it habitually? I have been experimenting with stuff
like that, notably emacspeak (a script that starts
Emacs with a TTS extension), only it won't shut up
because it is intended for blind people. While I can't,
uh, visualize their situation(s), even to a blind
person that's a lot of noise. Problem was that I
couldn't configure it without having it loaded, and
that made me crazy after just a few keystrokes and
cursor movements. So I checked it out with 'aptitude
show' and found that it was based on espeak, which is
available in the Debian repos as a stand-alone-tool,
and so I wrote

es () {
	espeak -s 130 -k 20 -v en -f $1 -w `basename $1 .txt`.wav
}

to create sound files from text, and it should be a
small task to setup defuns to interact with it.

For a sound file example (and the text file used as
input), check out [1]. I don't know if it can replace
reading. It will certainly not be as enjoyable. But
what do you do? All tricks to compensate for the loss
of information intake should be explored...

> over here and I don't use g.u.i. stuff on Linux I
> have to do that at work and shouldn't have to at
> home.

Right on!

> The only way I found to clear this state was to
> reboot the amd64 k8 athelon and that cleared it.

What? :)

[1] http://user.it.uu.se/~embe8573/espeak_demo/

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Yuri Khan]

On Tue, Jan 21, 2014 at 12:23 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
>
> Some information on this, see if you can figure it out:
>
> In keymaps(5), there is some information what to do
> with caps:
>
[…]
>
> Note: Get the keycodes with 'showkey', then update
> changes to the remap file with 'sudo loadkeys'.

I’m in X, I thought I was clear enough. Why or how are
keymaps(5)/showkey(1)/loadkeys(1) relevant?

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> Some information on this, see if you can figure it
>> out: In keymaps(5), there is some information what
>> to do with caps:
>
> I'm in X, I thought I was clear enough. Why or how
> are keymaps(5)/showkey(1)/loadkeys(1) relevant?

If you read the keymaps man page, it sure looks like it
is impossible (the "CapsShift") - this of course does
not imply that the kernel cannot do it in principle, it
just doesn't (what I can read) in that case. How X does
its I/O, and how this relates to the kernel, I don't
know.

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Yuri Khan]

On Mon, Jan 20, 2014 at 6:57 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> I notice that, when I turn on Caps Lock, all Ctrl+letter combinations
> behave as if I pressed Ctrl+Shift+letter.

OK, I looked at the code.

In xterm.c, function handle_one_xevent, a KeyPress event is received,
with state == 0x06 (LockMask | ControlMask) and keycode == 52 (<AB01>
according to xkb/keycodes/evdev). Then, XmbLookupString is called on
this event, producing keysym == 0x5a ('Z') and storing a single 0x1a
character to copy_bufptr. The latter is ignored because the “if
(keysym >= 32 && keysym < 128)” branch is taken, producing an event
{kind: ASCII_KEYSTROKE_EVENT, code: 0x5a, modifiers: ctrl_modifier}.
The LockMask bit is lost at this point.

Then, under the “done:” label, the kbd_buffer_store_event_hold
function from keyboard.c is called, which in turn calls
make_ctrl_char, which sees 0x5a and sets the shift_modifier.

After this, no further processing, in Lisp or in C, can detect that
the Shift key was not in fact pressed.


The problem stems from the concept that keyboard input is a stream of
(extended) characters and any modifier keys just add modifier bits to
those characters. I do not think it can be fixed or worked around
without a significant rethinking of the input model.


This is unfortunate because, as a user, I expect Caps Lock to only
affect character input, not command bindings. As it is, turning on
Caps Lock upsets any key bindings that involve Shift. This includes
cua-mode’s C-x and C-c, and any user-defined bindings (in my case,
C-S-z = redo and C-S-u = insert-char).

Related: When I switch XKB groups (e.g. activate Russian layout), I
lose all C-letter and M-letter bindings, because they then produce
Cyrillic letters with the respective modifiers. E.g. with US English
QWERTY as primary and Russian ЙЦУКЕН as secondary, pressing Ctrl+W
produces C-ц instead of C-w. I work around this with an ugly
key-translation-map hack.

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> OK, I looked at the code.

OK, great job!

> The LockMask bit is lost at this point.

Can you see a reason for this? Are there too few bits?
Or isn't it needed, the what it is now, having
"uppercased" the letter, its job done?

> Then, under the “done:” label, the
> kbd_buffer_store_event_hold function from keyboard.c
> is called, which in turn calls make_ctrl_char, which
> sees 0x5a and sets the shift_modifier.

OK, so the problem is, shift isn't shift because the
shift *key* is pressed, shift is shift because the char
is *uppercase*?

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> This is unfortunate because, as a user, I expect Caps
> Lock to only affect character input, not command
> bindings. As it is, turning on Caps Lock upsets any
> key bindings that involve Shift. This includes
> cua-mode’s C-x and C-c, and any user-defined bindings
> (in my case, C-S-z = redo and C-S-u = insert-char).

Just thought of one thing, there is a caps-mode.el,
written by a man on this list, which is great, because
it gives you caps lock functionality, but *buffer
local* (and thus obviously contained to Emacs). All
mistakes with caps is when you set it, type (in caps),
then move to somewhere else, and type something else,
and for some reason you always think it won't stick,
but it does. So it is great to have that mode and I
think it won't influence shift, because what it does is
substitute-key-definition on the self-insert-command
chars, so shift should float a parallel
current. Because I see you are a C programmer, you
might even want to check out a post on that I wrote
some time ago, with some modifications to caps-mode,
where it auto-disables after one word, so you can write
a #define MONEY 0 with just one press of the caps key
(preferably bounded to invoke caps-mode, not bothering
with the physical keyboard state).

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Yuri Khan]

On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
>
> Just thought of one thing, there is a caps-mode.el,
> written by a man on this list, which is great, because
> it gives you caps lock functionality, but *buffer
> local* (and thus obviously contained to Emacs).

Nice. I had to s/last-command-char/last-command-event/ in
github:emacsmirror/caps-mode version, but otherwise it works and
preserves control combinations. It even works with Cyrillic letters,
thanks to the use of [remap self-insert-command] and (upcase
last-command-event).

This is a bit clumsy because I have to have different keys to turn on
caps in Emacs and in the rest of my environment, but will do for a
while.

> Because I see you are a C programmer, you
> might even want to check out a post on that I wrote
> some time ago, with some modifications to caps-mode,
> where it auto-disables after one word, so you can write
> a #define MONEY 0 with just one press of the caps key
> (preferably bounded to invoke caps-mode, not bothering
> with the physical keyboard state).

Actually in C++ we prefer preprocessor macros to be hard to type ;]
Anyway, I’d better bind an easy key to “upcase symbol to the left of
point”.

In fact I am working with a file where I need caps in some of the
columns but not in others. I might take the idea of caps-mode and add
a condition, so that it does the right thing for my case.

Re: Caps Lock affects Ctrl+keys

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> Nice. I had to
> s/last-command-char/last-command-event/ in
> github:emacsmirror/caps-mode version, but otherwise
> it works and preserves control combinations. It even
> works with Cyrillic letters, thanks to the use of
> [remap self-insert-command] and (upcase
> last-command-event).

That's interesting. I wonder if the programmers thought
of that of if it is a consequence of good design on
multiple parts.

> This is a bit clumsy because I have to have different
> keys to turn on caps in Emacs and in the rest of my
> environment, but will do for a while.

That's always the drawback when you solve things that
you wish system-wide on the application level.

But that's where Emacs is somewhat a special case,
because you can do so many things with Emacs, so
setting things up in Emacs (not trivial but perhaps not
the most difficult thing in the world) can pay off big
if one's Emacs use propagates to still new fields of
activity.

When I setup caps-mode.el, I thought it wouldn't matter
otherwhere because I only type otherwise in zsh, and
there I wouldn't need uppercased words. But that proved
to be incorrect:

* The computer world is filled with acronyms: gui, cpu,
  smtp, dram, mud, mmorpg, irc, ... though I could get
  used to it, they don't look the same.

* Also, while I prefer readme.txt, some old-schoolers
  say that files intended for humans should look like
  README instead.

* And, not the least, the env vars - HOME, PATH, etc.

So I wonder if something like caps-mode.el can be found
and setup on the terminal/multiplexer/shell level. I
have already rerouted the caps key to produce a goofy
Unicode char, which Emacs fetches and evaluates to
activating the caps mode, and when I hit that key in
tty/tmux/zsh, that char appears (or actually a diamond,
as it is U+0111, which apparently is stretching it for
the poor driver, or perhaps it isn't even printable) -
but anyway it appears, so what's saying I can't do the
same dance once again? To do it there (the shell, or on
top of whatever) would be feasible, but to do it like
20 times if you use that many applications and cannot
solve it at a lower level, then you have to use the
caps key a whole lot to make it worth it :)

-- 
underground experts united:
http://user.it.uu.se/~embe8573

Re: Caps Lock affects Ctrl+keys

[Yuri Khan]

On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote:

> Just thought of one thing, there is a caps-mode.el,
> written by a man on this list, which is great, because
> it gives you caps lock functionality, but *buffer
> local* (and thus obviously contained to Emacs).

Does anyone happen to know what is the canonical repository for
caps-mode? I’d like to submit a couple of patches that fix the
following:
* the use of obsolete last-command-char variable,
* caps-mode ignores the state of overwrite-mode and always inserts.

Re: Caps Lock affects Ctrl+keys

[Dan Espen]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Tue, Jan 21, 2014 at 9:10 AM, Emanuel Berg <embe8573@student.uu.se> wrote:
>
>> Just thought of one thing, there is a caps-mode.el,
>> written by a man on this list, which is great, because
>> it gives you caps lock functionality, but *buffer
>> local* (and thus obviously contained to Emacs).
>
> Does anyone happen to know what is the canonical repository for
> caps-mode? I’d like to submit a couple of patches that fix the
> following:
> * the use of obsolete last-command-char variable,
> * caps-mode ignores the state of overwrite-mode and always inserts.

Don't know, but I changed my copy to use last-command-event.
Right now I have a need to use caps-mode in XEmacs.
It runs without complaint but doesn't work, I get lower case
regardless of the mode.

I haven't looked in detail yet to find the issue with XEmacs.

-- 
Dan Espen

Re: Caps Lock affects Ctrl+keys

[Stefan Monnier]

> Does anyone happen to know what is the canonical repository for
> caps-mode? I’d like to submit a couple of patches that fix the
> following:
> * the use of obsolete last-command-char variable,
> * caps-mode ignores the state of overwrite-mode and always inserts.

FWIW I've been using the following hack occasionally.  Never bothered to
distribute it.


        Stefan


(defvar caps-lock-commands
  '(self-insert-command isearch-printing-char)
  "List of commands that are subject to `caps-lock-mode'.")

(define-minor-mode caps-lock-mode
  "Make self-inserting keys invert the capitalization."
  :global t
  (if caps-lock-mode
      (add-hook 'pre-command-hook #'caps-lock--pch)
    (remove-hook 'pre-command-hook #'caps-lock--pch)))

(defun caps-lock--pch ()
  (when (memq this-command caps-lock-commands)
    (setq last-command-event
          (condition-case nil
              (let ((up (upcase last-command-event)))
                (if (eq up last-command-event)
                    (downcase last-command-event)
                  up))
            (error last-command-event)))))