all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* capslock changes control characters?
@ 2008-02-18 18:45 Chris Moore
  2008-02-24 22:30 ` Richard Stallman
  0 siblings, 1 reply; 15+ messages in thread
From: Chris Moore @ 2008-02-18 18:45 UTC (permalink / raw)
  To: emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-02-18 18:45 capslock changes control characters? Chris Moore
@ 2008-02-24 22:30 ` Richard Stallman
  2008-03-03 10:38   ` David Reitter
  2008-03-05  5:13   ` Kenichi Handa
  0 siblings, 2 replies; 15+ messages in thread
From: Richard Stallman @ 2008-02-24 22:30 UTC (permalink / raw)
  To: Chris Moore; +Cc: emacs-pretest-bug

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







^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-02-24 22:30 ` Richard Stallman
@ 2008-03-03 10:38   ` David Reitter
  2008-03-03 14:02     ` Stefan Monnier
  2008-03-05  5:13   ` Kenichi Handa
  1 sibling, 1 reply; 15+ messages in thread
From: David Reitter @ 2008-03-03 10:38 UTC (permalink / raw)
  To: emacs-pretest-bug

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.)





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-03 10:38   ` David Reitter
@ 2008-03-03 14:02     ` Stefan Monnier
  2008-03-03 14:49       ` Andreas Schwab
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2008-03-03 14:02 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-pretest-bug

> (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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-03 14:02     ` Stefan Monnier
@ 2008-03-03 14:49       ` Andreas Schwab
  2008-03-04 13:15         ` Chris Moore
  0 siblings, 1 reply; 15+ messages in thread
From: Andreas Schwab @ 2008-03-03 14:49 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: David Reitter, emacs-pretest-bug

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."




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-03 14:49       ` Andreas Schwab
@ 2008-03-04 13:15         ` Chris Moore
  0 siblings, 0 replies; 15+ messages in thread
From: Chris Moore @ 2008-03-04 13:15 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: David Reitter, Stefan Monnier, emacs-pretest-bug

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.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-02-24 22:30 ` Richard Stallman
  2008-03-03 10:38   ` David Reitter
@ 2008-03-05  5:13   ` Kenichi Handa
  2008-03-05 16:18     ` Stefan Monnier
  2008-03-16  9:15     ` Andreas Schwab
  1 sibling, 2 replies; 15+ messages in thread
From: Kenichi Handa @ 2008-03-05  5:13 UTC (permalink / raw)
  To: rms; +Cc: emacs-pretest-bug, christopher.ian.moore

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-05  5:13   ` Kenichi Handa
@ 2008-03-05 16:18     ` Stefan Monnier
  2008-03-05 16:50       ` Andreas Schwab
  2008-03-16  9:15     ` Andreas Schwab
  1 sibling, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2008-03-05 16:18 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-pretest-bug, christopher.ian.moore, rms

> 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





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-05 16:18     ` Stefan Monnier
@ 2008-03-05 16:50       ` Andreas Schwab
  2008-03-06 11:20         ` Kenichi Handa
  0 siblings, 1 reply; 15+ messages in thread
From: Andreas Schwab @ 2008-03-05 16:50 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: emacs-pretest-bug, christopher.ian.moore, rms, Kenichi Handa

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."




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-05 16:50       ` Andreas Schwab
@ 2008-03-06 11:20         ` Kenichi Handa
  2008-03-07 23:04           ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Kenichi Handa @ 2008-03-06 11:20 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-pretest-bug, christopher.ian.moore, monnier, rms

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-06 11:20         ` Kenichi Handa
@ 2008-03-07 23:04           ` Stefan Monnier
  2008-03-10  0:54             ` Kenichi Handa
  0 siblings, 1 reply; 15+ messages in thread
From: Stefan Monnier @ 2008-03-07 23:04 UTC (permalink / raw)
  To: Kenichi Handa
  Cc: Andreas Schwab, christopher.ian.moore, rms, emacs-pretest-bug

> 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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-07 23:04           ` Stefan Monnier
@ 2008-03-10  0:54             ` Kenichi Handa
  2008-03-10  3:26               ` Stefan Monnier
  0 siblings, 1 reply; 15+ messages in thread
From: Kenichi Handa @ 2008-03-10  0:54 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: schwab, christopher.ian.moore, rms, emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-10  0:54             ` Kenichi Handa
@ 2008-03-10  3:26               ` Stefan Monnier
  0 siblings, 0 replies; 15+ messages in thread
From: Stefan Monnier @ 2008-03-10  3:26 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: schwab, christopher.ian.moore, rms, emacs-pretest-bug

>> > 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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-05  5:13   ` Kenichi Handa
  2008-03-05 16:18     ` Stefan Monnier
@ 2008-03-16  9:15     ` Andreas Schwab
  2008-03-17  0:48       ` Kenichi Handa
  1 sibling, 1 reply; 15+ messages in thread
From: Andreas Schwab @ 2008-03-16  9:15 UTC (permalink / raw)
  To: Kenichi Handa; +Cc: emacs-pretest-bug

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."




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: capslock changes control characters?
  2008-03-16  9:15     ` Andreas Schwab
@ 2008-03-17  0:48       ` Kenichi Handa
  0 siblings, 0 replies; 15+ messages in thread
From: Kenichi Handa @ 2008-03-17  0:48 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: emacs-pretest-bug

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2008-03-17  0:48 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-18 18:45 capslock changes control characters? Chris Moore
2008-02-24 22:30 ` Richard Stallman
2008-03-03 10:38   ` David Reitter
2008-03-03 14:02     ` Stefan Monnier
2008-03-03 14:49       ` Andreas Schwab
2008-03-04 13:15         ` Chris Moore
2008-03-05  5:13   ` Kenichi Handa
2008-03-05 16:18     ` Stefan Monnier
2008-03-05 16:50       ` Andreas Schwab
2008-03-06 11:20         ` Kenichi Handa
2008-03-07 23:04           ` Stefan Monnier
2008-03-10  0:54             ` Kenichi Handa
2008-03-10  3:26               ` Stefan Monnier
2008-03-16  9:15     ` Andreas Schwab
2008-03-17  0:48       ` Kenichi Handa

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.