GNU bug report logs - #1580
zap-to-char too raw, or document

Previous Next

Full log

Message #19 received at 1580 <at> debbugs.gnu.org (full text, mbox):

From: "Stephen J. Turnbull" <turnbull <at> sk.tsukuba.ac.jp>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 1580 <at> debbugs.gnu.org, emacs-devel <at> gnu.org, jidanni <at> jidanni.org
Subject: Re: zap-to-char too raw, or document
Date: Sun, 17 Jul 2011 09:23:21 +0900

Lars Magne Ingebrigtsen writes:

 > Should there be an interactive spec that allows reading one character,
 > but allows input methods?  Or does that make no sense?

Yes, there should be such a spec.  Personally, I would expect "c" to
be that spec.  This does make sense both conceptually and
implementation-wise because input methods conceptually operate as a
"preedit" stage.  And of course if your input method is implemented in
the OS rather than Emacs you already can input non-ASCII characters to
the "c" interactive spec.

However, many input methods can return non-trivial strings (in
Japanese it's quite common to compose whole sentences in the input
method before the input method returns any characters), and IIRC the
XIM spec explicitly says a string is returned.  In cases of phonetic
input methods for Asian languages, it is often convenient to convert a
whole word then delete unneeded characters to get a specific
character.  My recommendation would be for "c" to read either a
character or a string, characters being used directly, and otherwise
extracting the first character from the string read.  An empty string
would be an error.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.