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/

Re: 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/

Re: 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.

Re: zap-to-char too raw, or document

[David Kastrup]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

> 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.

I have my reservations about that.  When reading a single character, you
don't get to use backspace and other methods of amelioration, so c is
often more useful for things like answering questions than editing.

When I answer a y/n style question, I would not want to have a
latin-1-postfix input method waiting in order to figure out whether I
want to adorn my n with a ~ in order to get ñ.

For zap-to-char, things look different.  So I am with Lars in that there
should be different interactive specs for with and without input
methods, like we have s (without input method) and M (with current input
method).

-- 
David Kastrup

Re: zap-to-char too raw, or document

[Andreas Röhler]

>
> When I answer a y/n style question, I would not want to have a
> latin-1-postfix input method waiting in order to figure out whether I
> want to adorn my n with a ~ in order to get ñ.
>

Where is the problem? User specifying a simple char will not notice the 
extended capability.


> For zap-to-char, things look different.  So I am with Lars in that there
> should be different interactive specs

it was said "but allows", not "make different".
Better keeping things simple.

Andreas

  for with and without input
> methods, like we have s (without input method) and M (with current input
> method).
>

Re: zap-to-char too raw, or document

[Andreas Schwab]

Andreas Röhler <andreas.roehler@online.de> writes:

>> When I answer a y/n style question, I would not want to have a
>> latin-1-postfix input method waiting in order to figure out whether I
>> want to adorn my n with a ~ in order to get ñ.
>>
>
> Where is the problem? User specifying a simple char will not notice the
> extended capability.

How do you know the user doesn't want to input ñ as n~?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: zap-to-char too raw, or document

[Andreas Röhler]

Am 17.07.2011 13:18, schrieb Andreas Schwab:
> Andreas Röhler<andreas.roehler@online.de>  writes:
>
>>> When I answer a y/n style question, I would not want to have a
>>> latin-1-postfix input method waiting in order to figure out whether I
>>> want to adorn my n with a ~ in order to get ñ.
>>>
>>
>> Where is the problem? User specifying a simple char will not notice the
>> extended capability.
>
> How do you know the user doesn't want to input ñ as n~?
>
> Andreas.
>

IIUC its upon changing the API so it would recognise an prefix-argument 
like C-u.

Calling that a " y/n style question" already has been misleading IMHO.

Andreas

Re: zap-to-char too raw, or document

[Stephen J. Turnbull]

David Kastrup writes:

 > When I answer a y/n style question, I would not want to have a
 > latin-1-postfix input method waiting in order to figure out whether I
 > want to adorn my n with a ~ in order to get ñ.

Emacs methods won't "be waiting"; they're buffer-, including
minibuffer-, specific.  You will have to turn on the input method
explicitly.  (At least, you would in XEmacs, I'm not 100% sure Emacs
works precisely the same way here.)

However, on second thought I'm not sure what the use case for a single
character via input method is, vs a one-character string via input
method.  As you point out, it's a big deal to type even one extra
keystroke in a y-or-n-p context, but it's hardly a big deal to type
one extra RET after typing something like "C-\ i t i SPC SPC RET" to
get U+4E00 (the Chinese character for "one" as pronounced by
Japanese).

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.

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

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> Apart from zap-to-char, is there anything that might need this?

Perhaps not.  We could just let that command read characters
specially...

> 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'...

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

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.

Re: 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/

Re: 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/

Re: 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

[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

[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

[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.