bug#1580: zap-to-char too raw, or document

bug#1580: zap-to-char too raw, or document

[jidanni]

M-z runs the command zap-to-char.
Its docstring should mention how to zap to e.g., C-g.
You see the problem is that it eats the C-q before you have a chance
to type C-q C-g.
Therefore it should say that you will have to use eval-expression
etc., unless it is tamed...

bug#1580: zap-to-char too raw, or document

[Lars Magne Ingebrigtsen]

jidanni@jidanni.org writes:

> M-z runs the command zap-to-char.
> Its docstring should mention how to zap to e.g., C-g.
> You see the problem is that it eats the C-q before you have a chance
> to type C-q C-g.
> Therefore it should say that you will have to use eval-expression
> etc., unless it is tamed...

I think `C-g' is the only character you can't zap to.  Well, or any
character that requires an input method.

Should there be an interactive spec for reading a character that allows
using `C-q' for quoting, and that allows using the current input method?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1580: zap-to-char too raw, or document

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think `C-g' is the only character you can't zap to.  Well, or any
> character that requires an input method.
>
> Should there be an interactive spec for reading a character that allows
> using `C-q' for quoting, and that allows using the current input method?

(Cc-ing to emacs-devel, since it's a slightly more general problem.)

We have the "c" interactive spec that's used in commands like
`zap-to-char'.  The "c" spec doesn't seem to allow using input methods,
or to use `C-q'.

So it's pretty difficult to zap to 日.  

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

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1580: zap-to-char too raw, or document

[Stephen J. Turnbull]

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.

bug#1580: zap-to-char too raw, or document

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

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

Apart from zap-to-char, is there anything that might need this?  It's
generally not worth it to add interactive codes for every conceivable
operation.  In this case, I think using read-char in the interactive
form should work.

bug#1580: zap-to-char too raw, or document

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> It's generally not worth it to add interactive codes for every
>> conceivable operation.  In this case, I think using read-char in the
>> interactive form should work.
>
> Will `read-char' allow zapping to `C-g'?  It doesn't seem to be
> possible to say `C-q C-g'...

I don't think it allows `C-q C-g', but it would allow using the input
method, which is probably a more common need.  I don't support any
changes in this area until after the release, tho.

bug#1580: zap-to-char too raw, or document

[Glenn Morris]

For the ctrl-g bit, just suggest

M-: (zap-to-char 1 ?\C-g)

in the doc-string and be done with it (nobody else is ever going to care
about this).

Otherwise the next bug report will be "I can't quit zap-to-char".

bug#1580: zap-to-char too raw, or document

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> For the ctrl-g bit, just suggest
>
> M-: (zap-to-char 1 ?\C-g)
>
> in the doc-string and be done with it (nobody else is ever going to care
> about this).
>
> Otherwise the next bug report will be "I can't quit zap-to-char".

Well, they can quit by just not saying `C-q' before the `C-g'.  :-)

But I think just allowing input methods, and not allowing `C-q' would be
the best solution.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1580: zap-to-char too raw, or document

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> But I think just allowing input methods, and not allowing `C-q' would be
> the best solution.

I've now altered `zap-to-char' to use `read-char' inheriting input
methods.  I don't think it's worth mentioning in the NEWS file.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1580: zap-to-char too raw, or document

[jidanni]

LMI> Should there be an interactive spec for reading a character that allows
LMI> using `C-q' for quoting, and that allows using the current input method?

Maybe say how to enter the char in octal, etc.