Re: capslock changes control characters?

[Kenichi Handa <handa@m17n.org>]

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