emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: capslock changes control characters?


From: Kenichi Handa
Subject: Re: capslock changes control characters?
Date: Mon, 10 Mar 2008 09:54:42 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Stefan Monnier <address@hidden> 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
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]