[Top][All Lists]

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

Re: single-key-description no good for Japanese and Chinese chars

From: Stefan Monnier
Subject: Re: single-key-description no good for Japanese and Chinese chars
Date: Fri, 22 Sep 2006 13:43:36 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> My question is this: Why do these keys have as their binding
>> `self-insert-command'?

>     Because that is the binding for all characters of that group.

> That sounds like "because that's the way it is".  Care to elaborate? The
> question is not how it is done, but why it is done that way.

When someone enters such a character (typically via XIM or quail), he/she
presumably wants to insert it, so it seems eminently natural to bind all
those chars to self-insert-command.

> So what? Binding thousands of characters is something computers are good at.
> Or are you saying that that would affect performance in an unacceptable way?

What would be the benefit of binding each char individually?
I don't think it's terribly important which way it's done, but the current
way at least has the advantage of being less inefficient.

> If so, what's special about `self-insert-command' - why not bind them all to
> a different command, `foobar', which does what is needed, so they don't get
> in the way of the normal, simple, straightforward relations between
> `self-insert-command', `single-key-description', and `read-kbd-macro'?

I see no relation between self-insert-command and the other two.

> A program might well expect `self-insert-command' to do what it says
> straightforwardly: insert the key as a character.

What makes you think it doesn't do exactly that?

> My program did, and this new feature has hardly been released yet (AFAIK,
> it's new in Emacs 22).

I don't think this is was significantly changed since Emacs-21 (or probably
even Emacs-20.4).  So the cause of your problem might be somewhere else.
Please then tell us exactly what is the behavior you used to see compared to
what you see now.


reply via email to

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