capslock changes control characters?

capslock changes control characters?

[Chris Moore]

I tried to insert a TAB into a C++ mode buffer by typing:

  C-q C-i

I got an error:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p 33554441)
  insert-and-inherit(33554441)
  quoted-insert(1)
  call-interactively(quoted-insert nil nil)

Turns out I had capslock on.  This is reproducible in "emacs -Q" in
the default *scratch* buffer.

$ emacs -Q
[ turn on capslock]
C-q C-i

Re: capslock changes control characters?

[Richard Stallman]

Would someone please DTRT and ack?

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	bh=RPUQW6ffWncPFrTfAXlFMPICwOhciplksuvNI3Gb+pc=;
	b=XbmYZo8fHpDLziB73TB3r8yHK5AYhx/bRpyTATYaqW4nmtJrscewGg93La8Zk4p2MBy7BmjlxySQKe+KvyR8CdWrri+YMwK28Be0gc23drOx12LFuaQ2S5urEF63f5bSzFPq4+2RIhkJe24oO51JFO5vtPH4G2LeAODj/V7tKvM=
Message-ID: <a9691ee20802181045w576d4130g556577a58c645dcd@mail.gmail.com>
Date: Mon, 18 Feb 2008 19:45:01 +0100
From: "Chris Moore" <christopher.ian.moore@gmail.com>
To: emacs-pretest-bug@gnu.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Cc: 
Subject: capslock changes control characters?

I tried to insert a TAB into a C++ mode buffer by typing:

  C-q C-i

I got an error:

Debugger entered--Lisp error: (wrong-type-argument char-or-string-p 33554441)
  insert-and-inherit(33554441)
  quoted-insert(1)
  call-interactively(quoted-insert nil nil)

Turns out I had capslock on.  This is reproducible in "emacs -Q" in
the default *scratch* buffer.

$ emacs -Q
[ turn on capslock]
C-q C-i

Re: capslock changes control characters?

[David Reitter]

On 3 Mar 2008, at 10:08, Chris Moore wrote:

>
> C-q C-i
>
> I got an error:
>
> Turns out I had capslock on.  This is reproducible in "emacs -Q" in
> the default *scratch* buffer.


Would is also be nice if Emacs converted keys bound to normal commands  
back to their lower-case variant when Caps Lock is active?

For instance, I've got C-x B bound to another function (switch-to- 
buffer-here). When Caps Lock is on, Emacs reads C-x B even though I  
did not use the shift key. While this is logical from a programmer's  
perspective, as a user I often have Caps Lock on by mistake, causing  
regular mixups.

(You may criticize the useless Caps Lock key, you may comment on the  
poor choice of the C-x B key-binding (it's only an example), but one  
has little control over these things one for various reasons.)

Re: capslock changes control characters?

[Stefan Monnier]

> (You may criticize the useless Caps Lock key, you may comment on the poor
> choice of the C-x B key-binding (it's only an example), but one  has little
> control over these things one for various reasons.)

`xmodmap' will quickly and effectively get you rid of the caps-lock pest
and replace it with the much more useful `control' key.


        Stefan

Re: capslock changes control characters?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (You may criticize the useless Caps Lock key, you may comment on the poor
>> choice of the C-x B key-binding (it's only an example), but one  has little
>> control over these things one for various reasons.)
>
> `xmodmap' will quickly and effectively get you rid of the caps-lock pest
> and replace it with the much more useful `control' key.

Or add ctrl:nocaps to your XKB options.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: capslock changes control characters?

[Chris Moore]

On Mon, Mar 3, 2008 at 3:49 PM, Andreas Schwab <schwab@suse.de> wrote:

>  Or add ctrl:nocaps to your XKB options.

I don't want to disable the capslock key, I just want it to work properly.

When capslock is on, the letters a-z should become A-Z, but that's
all.  I don't expect 1 to become ! (shifted 1), and I don't expect C-q
to become C-S-q.  Capslock should only act on regular letters, not on
control keys.

Another example:  in a *shell* buffer, I expect M-p to take me to a
previous command in the shell history.  If capslock is on, it just
inserts a p into the buffer.  I don't know why it inserts a lowercase
'p' (capslock is on, after all), but this is what C-h k tells me:

  p (translated from M-P) runs the command self-insert-command, which is
  an interactive built-in function in `C source code'.

Chris.

Re: capslock changes control characters?

[Kenichi Handa]

In article <E1JTPMO-0000WA-5C@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> [I sent this message a week ago but did not get a response.]
> Would someone please DTRT and ack?
[...]
> From: "Chris Moore" <christopher.ian.moore@gmail.com>
> To: emacs-pretest-bug@gnu.org
> Subject: capslock changes control characters?

> I tried to insert a TAB into a C++ mode buffer by typing:

>   C-q C-i

> I got an error:

> Debugger entered--Lisp error: (wrong-type-argument char-or-string-p 33554441)

I've just installed a fix.  It required changes to several
places, and among them I'm not sure the following changes
are ok.

2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>

	* lread.c (Fread_char): Resolve modifiers.
	(Fread_char_exclusive): Likewise.

Previously (read-char) returned 33554441 when you type C-I
(i.e. C-S-i).  I changed it to return 9 (i.e. C-i).  It is
also changed to return 233 upon M-i instead of 134217833.
They still return a code containing unresolvable modifiers.

The algorithm of resolving modifiers is implemented in
char_resolve_modifier_mask as below:

int
char_resolve_modifier_mask (c)
     int c;
{
  /* A non-ASCII character can't reflect modifier bits to the code.  */
  if (! ASCII_CHAR_P ((c & ~CHAR_MODIFIER_MASK)))
    return c;

  /* For Meta, Shift, and Control modifiers, we need special care.  */
  if (c & CHAR_SHIFT)
    {
      /* Shift modifier is valid only with [A-Za-z].  */
      if ((c & 0377) >= 'A' && (c & 0377) <= 'Z')
	c &= ~CHAR_SHIFT;
      else if ((c & 0377) >= 'a' && (c & 0377) <= 'z')
	c = (c & ~CHAR_SHIFT) - ('a' - 'A');
      /* Shift modifier for control characters and SPC is ignored.  */
      else if ((c & ~CHAR_MODIFIER_MASK) <= 0x20)
	c &= ~CHAR_SHIFT;
    }
  if (c & CHAR_CTL)
    {
      /* Simulate the code in lread.c.  */
      /* Allow `\C- ' and `\C-?'.  */
      if ((c & 0377) == ' ')
	c &= ~0177 & ~ CHAR_CTL;
      else if ((c & 0377) == '?')
	c = 0177 | (c & ~0177 & ~CHAR_CTL);
      /* ASCII control chars are made from letters (both cases),
	 as well as the non-letters within 0100...0137.  */
      else if ((c & 0137) >= 0101 && (c & 0137) <= 0132)
	c &= (037 | (~0177 & ~CHAR_CTL));
      else if ((c & 0177) >= 0100 && (c & 0177) <= 0137)
	c &= (037 | (~0177 & ~CHAR_CTL));
    }
  if (c & CHAR_META)
    {
      /* Move the meta bit to the right place for a string.  */
      c = (c & ~CHAR_META) | 0x80;
    }

  return c;
}

---
Kenichi Handa
handa@ni.aist.go.jp

Re: capslock changes control characters?

[Stefan Monnier]

> 2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>

> 	* lread.c (Fread_char): Resolve modifiers.
> 	(Fread_char_exclusive): Likewise.

> Previously (read-char) returned 33554441 when you type C-I
> (i.e. C-S-i).  I changed it to return 9 (i.e. C-i).  It is
> also changed to return 233 upon M-i instead of 134217833.
> They still return a code containing unresolvable modifiers.

It looks ok, but I have some comments/questions:

1 - Why both with the mapping of meta?  AFAIK this is only ever used
    when manipulating keymaps using keysequences represented as strings
    rather than vectors.  So I don't think it's needed here.

2 - why is this needed now.  It seems like this was already working fine
    before the unicode merge without this function, so what is the change
    that caused the problem in the first place (or in other words, how
    did it work before)?


-- Stefan


> The algorithm of resolving modifiers is implemented in
> char_resolve_modifier_mask as below:

> int
> char_resolve_modifier_mask (c)
>      int c;
> {
>   /* A non-ASCII character can't reflect modifier bits to the code.  */
>   if (! ASCII_CHAR_P ((c & ~CHAR_MODIFIER_MASK)))
>     return c;

>   /* For Meta, Shift, and Control modifiers, we need special care.  */
>   if (c & CHAR_SHIFT)
>     {
>       /* Shift modifier is valid only with [A-Za-z].  */
>       if ((c & 0377) >= 'A' && (c & 0377) <= 'Z')
> 	c &= ~CHAR_SHIFT;
>       else if ((c & 0377) >= 'a' && (c & 0377) <= 'z')
> 	c = (c & ~CHAR_SHIFT) - ('a' - 'A');
>       /* Shift modifier for control characters and SPC is ignored.  */
>       else if ((c & ~CHAR_MODIFIER_MASK) <= 0x20)
> 	c &= ~CHAR_SHIFT;
>     }
>   if (c & CHAR_CTL)
>     {
>       /* Simulate the code in lread.c.  */
>       /* Allow `\C- ' and `\C-?'.  */
>       if ((c & 0377) == ' ')
> 	c &= ~0177 & ~ CHAR_CTL;
>       else if ((c & 0377) == '?')
> 	c = 0177 | (c & ~0177 & ~CHAR_CTL);
>       /* ASCII control chars are made from letters (both cases),
> 	 as well as the non-letters within 0100...0137.  */
>       else if ((c & 0137) >= 0101 && (c & 0137) <= 0132)
> 	c &= (037 | (~0177 & ~CHAR_CTL));
>       else if ((c & 0177) >= 0100 && (c & 0177) <= 0137)
> 	c &= (037 | (~0177 & ~CHAR_CTL));
>     }
>   if (c & CHAR_META)
>     {
>       /* Move the meta bit to the right place for a string.  */
>       c = (c & ~CHAR_META) | 0x80;
>     }

>   return c;
> }

> ---
> Kenichi Handa
> handa@ni.aist.go.jp

Re: capslock changes control characters?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>
>
>> 	* lread.c (Fread_char): Resolve modifiers.
>> 	(Fread_char_exclusive): Likewise.
>
>> Previously (read-char) returned 33554441 when you type C-I
>> (i.e. C-S-i).  I changed it to return 9 (i.e. C-i).  It is
>> also changed to return 233 upon M-i instead of 134217833.
>> They still return a code containing unresolvable modifiers.
>
> It looks ok, but I have some comments/questions:
>
> 1 - Why both with the mapping of meta?  AFAIK this is only ever used
>     when manipulating keymaps using keysequences represented as strings
>     rather than vectors.  So I don't think it's needed here.
>
> 2 - why is this needed now.  It seems like this was already working fine
>     before the unicode merge without this function, so what is the change
>     that caused the problem in the first place (or in other words, how
>     did it work before)?

(read-char) has always returned 33554441 for C-S-i.  I think the
difference is that it is no longer considered a valid character by
char-or-string-p (ie. CHARACTERP).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: capslock changes control characters?

[Kenichi Handa]

In article <jefxv5qfni.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>
> >
>>> * lread.c (Fread_char): Resolve modifiers.
>>> (Fread_char_exclusive): Likewise.
> >
>>> Previously (read-char) returned 33554441 when you type C-I
>>> (i.e. C-S-i).  I changed it to return 9 (i.e. C-i).  It is
>>> also changed to return 233 upon M-i instead of 134217833.
>>> They still return a code containing unresolvable modifiers.
> >
> > It looks ok, but I have some comments/questions:
> >
> > 1 - Why both with the mapping of meta?  AFAIK this is only ever used
> >     when manipulating keymaps using keysequences represented as strings
> >     rather than vectors.  So I don't think it's needed here.
> >
> > 2 - why is this needed now.  It seems like this was already working fine
> >     before the unicode merge without this function, so what is the change
> >     that caused the problem in the first place (or in other words, how
> >     did it work before)?

> (read-char) has always returned 33554441 for C-S-i.  I think the
> difference is that it is no longer considered a valid character by
> char-or-string-p (ie. CHARACTERP).

Yes.

I think the current Emacs doesn't have a clear view about
when and how to resolve modifiers.  For instance, S-i is
resolved to `I' by XLookupString, C-i is resolved to 9 in
make_ctrl_char.  Then I think C-S-i should also be resolved
somewher before it's given to Lisp, at least before it's
given to Lisp as character.

So I resolved the modifiers in those functions than in, for
instance, char-to-string or insert.

Resolving of M-i is surely questionable, but as Emacs has
accepeted M-i upon (insert (read-char)) for long, I resolved
them too for backward compatibility.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: capslock changes control characters?

[Stefan Monnier]

> I think the current Emacs doesn't have a clear view about
> when and how to resolve modifiers.  For instance, S-i is
> resolved to `I' by XLookupString, C-i is resolved to 9 in
> make_ctrl_char.  Then I think C-S-i should also be resolved
> somewher before it's given to Lisp, at least before it's
> given to Lisp as character.

It should still be possible to distinguish key-bindings to C-i
(i.e. TAB) and C-S-i (i.e. S-TAB), provided the underlying terminal
allows it, obviously.
Does your code still allow this distinction?

> So I resolved the modifiers in those functions than in, for
> instance, char-to-string or insert.

Agreed.  `insert' and `char-to-string' have no business messing
with keys.

> Resolving of M-i is surely questionable, but as Emacs has
> accepeted M-i upon (insert (read-char)) for long, I resolved
> them too for backward compatibility.

I think this was just an accidental misfeature and would should not
preserve this kind of backward compatibility.  I can't imagine how it
could break any existing elisp package, and if a user used that in the
past, there are plenty of alternative ways to get the same result in
a saner way.


        Stefan

Re: capslock changes control characters?

[Kenichi Handa]

In article <jwvskz2m990.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I think the current Emacs doesn't have a clear view about
> > when and how to resolve modifiers.  For instance, S-i is
> > resolved to `I' by XLookupString, C-i is resolved to 9 in
> > make_ctrl_char.  Then I think C-S-i should also be resolved
> > somewher before it's given to Lisp, at least before it's
> > given to Lisp as character.

> It should still be possible to distinguish key-bindings to C-i
> (i.e. TAB) and C-S-i (i.e. S-TAB), provided the underlying terminal
> allows it, obviously.
> Does your code still allow this distinction?

No.  If one needs such distinction, he should use
read-event.

> > Resolving of M-i is surely questionable, but as Emacs has
> > accepeted M-i upon (insert (read-char)) for long, I resolved
> > them too for backward compatibility.

> I think this was just an accidental misfeature and would should not
> preserve this kind of backward compatibility.  I can't imagine how it
> could break any existing elisp package, and if a user used that in the
> past, there are plenty of alternative ways to get the same result in
> a saner way.

Ok.  But, currently Emacs allows this kind of string "\M-i"
(same as "\351", note that "\H-i" signales the error
"Invalid modifier in string").  It seems that this is also a
misfeature.  If we disallow M-i upon (insert (read-char)),
shouldn't we disallow "\M-i" too?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: capslock changes control characters?

[Stefan Monnier]

>> > I think the current Emacs doesn't have a clear view about
>> > when and how to resolve modifiers.  For instance, S-i is
>> > resolved to `I' by XLookupString, C-i is resolved to 9 in
>> > make_ctrl_char.  Then I think C-S-i should also be resolved
>> > somewher before it's given to Lisp, at least before it's
>> > given to Lisp as character.

>> It should still be possible to distinguish key-bindings to C-i
>> (i.e. TAB) and C-S-i (i.e. S-TAB), provided the underlying terminal
>> allows it, obviously.
>> Does your code still allow this distinction?

> No.  If one needs such distinction, he should use
> read-event.

I mean, can we usefully handle

  (define-key map [?\t] 'foo)
  (define-key map [?\S-\t] 'bar)

because I think it's important that we can distinguish them.
But now that I look at it, the matter is more complex than that: on X11
hitting shift+tab send something like S-iso-lefttab which is then
mapped to `backtab'.  Under an xterm I get an escape sequence that gets
decoded directly into `backtab'.  So I guess it's not that important to
preserve the ?\S-\t key.

>> > Resolving of M-i is surely questionable, but as Emacs has
>> > accepeted M-i upon (insert (read-char)) for long, I resolved
>> > them too for backward compatibility.

>> I think this was just an accidental misfeature and would should not
>> preserve this kind of backward compatibility.  I can't imagine how it
>> could break any existing elisp package, and if a user used that in the
>> past, there are plenty of alternative ways to get the same result in
>> a saner way.

> Ok.  But, currently Emacs allows this kind of string "\M-i"
> (same as "\351", note that "\H-i" signales the error
> "Invalid modifier in string").

Again, this is just an old feature that made sense back in the 7/8bit
tty days.  It's still accepted because a fair amount of code passes such
strings to define-key.  Any other use would count as a bug for me.

> It seems that this is also a misfeature.

Yes.  But one that's still used.

> If we disallow M-i upon (insert (read-char)), shouldn't we disallow
> "\M-i" too?

I don't think so.  One is used in elisp code, the other is used by
manual typing only.  So removing one will break elisp packages, while
removing the other will only make previously working key presses not
work as before, but with various alternative key-presses available.


        Stefan

Re: capslock changes control characters?

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> I've just installed a fix.  It required changes to several
> places, and among them I'm not sure the following changes
> are ok.
>
> 2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>
>
> 	* lread.c (Fread_char): Resolve modifiers.
> 	(Fread_char_exclusive): Likewise.

You forgot to commit the changelog entry.  Would you please make it up?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: capslock changes control characters?

[Kenichi Handa]

In article <je63vnhvws.fsf@sykes.suse.de>, Andreas Schwab <schwab@suse.de> writes:

> > 2008-03-05  Kenichi Handa  <handa@ni.aist.go.jp>
> >
> > 	* lread.c (Fread_char): Resolve modifiers.
> > 	(Fread_char_exclusive): Likewise.

> You forgot to commit the changelog entry.  Would you please make it up?

Oops, sorry.  Just committed.

---
Kenichi Handa
handa@ni.aist.go.jp