* bug#1580: zap-to-char too raw, or document
@ 2008-12-14 15:28 jidanni
2011-07-10 14:26 ` Lars Magne Ingebrigtsen
2011-07-10 19:37 ` jidanni
0 siblings, 2 replies; 21+ messages in thread
From: jidanni @ 2008-12-14 15:28 UTC (permalink / raw
To: bug-gnu-emacs
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...
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2008-12-14 15:28 bug#1580: zap-to-char too raw, or document jidanni
@ 2011-07-10 14:26 ` Lars Magne Ingebrigtsen
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-10 19:37 ` jidanni
1 sibling, 2 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-10 14:26 UTC (permalink / raw
To: jidanni; +Cc: 1580
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2008-12-14 15:28 bug#1580: zap-to-char too raw, or document jidanni
2011-07-10 14:26 ` Lars Magne Ingebrigtsen
@ 2011-07-10 19:37 ` jidanni
1 sibling, 0 replies; 21+ messages in thread
From: jidanni @ 2011-07-10 19:37 UTC (permalink / raw
To: larsi; +Cc: 1580
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-10 14:26 ` Lars Magne Ingebrigtsen
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
@ 2011-07-16 18:21 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-16 18:21 UTC (permalink / raw
To: jidanni; +Cc: 1580, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-10 14:26 ` Lars Magne Ingebrigtsen
@ 2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-17 0:23 ` bug#1580: " Stephen J. Turnbull
` (2 more replies)
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
1 sibling, 3 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-16 18:21 UTC (permalink / raw
To: jidanni; +Cc: 1580, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
@ 2011-07-17 0:23 ` Stephen J. Turnbull
2011-07-17 0:23 ` Stephen J. Turnbull
2011-07-20 15:02 ` bug#1580: " Chong Yidong
2 siblings, 0 replies; 21+ messages in thread
From: Stephen J. Turnbull @ 2011-07-17 0:23 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, jidanni, emacs-devel
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-17 0:23 ` bug#1580: " Stephen J. Turnbull
@ 2011-07-17 0:23 ` Stephen J. Turnbull
2011-07-17 8:01 ` David Kastrup
2011-07-20 15:02 ` bug#1580: " Chong Yidong
2 siblings, 1 reply; 21+ messages in thread
From: Stephen J. Turnbull @ 2011-07-17 0:23 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, emacs-devel, jidanni
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-17 0:23 ` Stephen J. Turnbull
@ 2011-07-17 8:01 ` David Kastrup
2011-07-17 9:34 ` Andreas Röhler
2011-07-18 13:39 ` Stephen J. Turnbull
0 siblings, 2 replies; 21+ messages in thread
From: David Kastrup @ 2011-07-17 8:01 UTC (permalink / raw
To: emacs-devel
"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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-17 8:01 ` David Kastrup
@ 2011-07-17 9:34 ` Andreas Röhler
2011-07-17 11:18 ` Andreas Schwab
2011-07-18 13:39 ` Stephen J. Turnbull
1 sibling, 1 reply; 21+ messages in thread
From: Andreas Röhler @ 2011-07-17 9:34 UTC (permalink / raw
To: emacs-devel
>
> 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).
>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-17 9:34 ` Andreas Röhler
@ 2011-07-17 11:18 ` Andreas Schwab
2011-07-17 17:36 ` Andreas Röhler
0 siblings, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2011-07-17 11:18 UTC (permalink / raw
To: Andreas Röhler; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-17 11:18 ` Andreas Schwab
@ 2011-07-17 17:36 ` Andreas Röhler
0 siblings, 0 replies; 21+ messages in thread
From: Andreas Röhler @ 2011-07-17 17:36 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: zap-to-char too raw, or document
2011-07-17 8:01 ` David Kastrup
2011-07-17 9:34 ` Andreas Röhler
@ 2011-07-18 13:39 ` Stephen J. Turnbull
1 sibling, 0 replies; 21+ messages in thread
From: Stephen J. Turnbull @ 2011-07-18 13:39 UTC (permalink / raw
To: David Kastrup; +Cc: emacs-devel
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).
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-17 0:23 ` bug#1580: " Stephen J. Turnbull
2011-07-17 0:23 ` Stephen J. Turnbull
@ 2011-07-20 15:02 ` Chong Yidong
2011-07-20 20:09 ` Lars Magne Ingebrigtsen
2 siblings, 1 reply; 21+ messages in thread
From: Chong Yidong @ 2011-07-20 15:02 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, jidanni, emacs-devel
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#1580: zap-to-char too raw, or document
2011-07-20 15:02 ` bug#1580: " Chong Yidong
@ 2011-07-20 20:09 ` Lars Magne Ingebrigtsen
2011-07-21 16:19 ` Chong Yidong
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-20 20:09 UTC (permalink / raw
To: Chong Yidong; +Cc: 1580, emacs-devel, jidanni
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-20 20:09 ` Lars Magne Ingebrigtsen
@ 2011-07-21 16:19 ` Chong Yidong
2011-07-21 19:16 ` Glenn Morris
2011-07-21 19:16 ` Glenn Morris
2 siblings, 0 replies; 21+ messages in thread
From: Chong Yidong @ 2011-07-21 16:19 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, jidanni, emacs-devel
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-20 20:09 ` Lars Magne Ingebrigtsen
2011-07-21 16:19 ` Chong Yidong
@ 2011-07-21 19:16 ` Glenn Morris
2011-07-21 19:16 ` Glenn Morris
2 siblings, 0 replies; 21+ messages in thread
From: Glenn Morris @ 2011-07-21 19:16 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, Chong Yidong, emacs-devel
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".
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#1580: zap-to-char too raw, or document
2011-07-20 20:09 ` Lars Magne Ingebrigtsen
2011-07-21 16:19 ` Chong Yidong
2011-07-21 19:16 ` Glenn Morris
@ 2011-07-21 19:16 ` Glenn Morris
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2 siblings, 2 replies; 21+ messages in thread
From: Glenn Morris @ 2011-07-21 19:16 UTC (permalink / raw
To: Lars Magne Ingebrigtsen; +Cc: 1580, Chong Yidong, emacs-devel
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".
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-21 19:16 ` Glenn Morris
@ 2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-31 15:33 UTC (permalink / raw
To: Glenn Morris; +Cc: 1580, Chong Yidong, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#1580: zap-to-char too raw, or document
2011-07-21 19:16 ` Glenn Morris
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
@ 2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
1 sibling, 2 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-07-31 15:33 UTC (permalink / raw
To: Glenn Morris; +Cc: 1580, Chong Yidong, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#1580: zap-to-char too raw, or document
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
@ 2012-04-10 2:24 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-10 2:24 UTC (permalink / raw
To: Glenn Morris; +Cc: 1580, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: bug#1580: zap-to-char too raw, or document
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
@ 2012-04-10 2:24 ` Lars Magne Ingebrigtsen
1 sibling, 0 replies; 21+ messages in thread
From: Lars Magne Ingebrigtsen @ 2012-04-10 2:24 UTC (permalink / raw
To: Glenn Morris; +Cc: 1580, Chong Yidong, emacs-devel
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/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-04-10 2:24 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-14 15:28 bug#1580: zap-to-char too raw, or document jidanni
2011-07-10 14:26 ` Lars Magne Ingebrigtsen
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-17 0:23 ` bug#1580: " Stephen J. Turnbull
2011-07-17 0:23 ` Stephen J. Turnbull
2011-07-17 8:01 ` David Kastrup
2011-07-17 9:34 ` Andreas Röhler
2011-07-17 11:18 ` Andreas Schwab
2011-07-17 17:36 ` Andreas Röhler
2011-07-18 13:39 ` Stephen J. Turnbull
2011-07-20 15:02 ` bug#1580: " Chong Yidong
2011-07-20 20:09 ` Lars Magne Ingebrigtsen
2011-07-21 16:19 ` Chong Yidong
2011-07-21 19:16 ` Glenn Morris
2011-07-21 19:16 ` Glenn Morris
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2011-07-31 15:33 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
2012-04-10 2:24 ` Lars Magne Ingebrigtsen
2011-07-16 18:21 ` Lars Magne Ingebrigtsen
2011-07-10 19:37 ` jidanni
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.