* Re: zap-to-char too raw, or document [not found] ` <m3d3hifbz8.fsf@quimbies.gnus.org> @ 2011-07-16 18:21 ` Lars Magne Ingebrigtsen 2011-07-17 0:23 ` Stephen J. Turnbull 2011-07-20 15:02 ` bug#1580: " Chong Yidong 0 siblings, 2 replies; 13+ 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] 13+ messages in thread
* Re: zap-to-char too raw, or document 2011-07-16 18:21 ` zap-to-char too raw, or document Lars Magne Ingebrigtsen @ 2011-07-17 0:23 ` Stephen J. Turnbull 2011-07-17 8:01 ` David Kastrup 2011-07-20 15:02 ` bug#1580: " Chong Yidong 1 sibling, 1 reply; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ 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; 13+ 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] 13+ messages in thread
* bug#1580: zap-to-char too raw, or document 2011-07-16 18:21 ` zap-to-char too raw, or document Lars Magne Ingebrigtsen 2011-07-17 0:23 ` Stephen J. Turnbull @ 2011-07-20 15:02 ` Chong Yidong 2011-07-20 20:09 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 13+ 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] 13+ 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 2011-07-21 19:16 ` Glenn Morris 0 siblings, 2 replies; 13+ 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] 13+ 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 1 sibling, 0 replies; 13+ 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] 13+ 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-31 15:33 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 13+ 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] 13+ 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 2012-04-10 2:24 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 13+ 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] 13+ 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 0 siblings, 0 replies; 13+ 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] 13+ messages in thread
end of thread, other threads:[~2012-04-10 2:24 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87myeydbea.fsf@jidanni.org> [not found] ` <m3d3hifbz8.fsf@quimbies.gnus.org> 2011-07-16 18:21 ` zap-to-char too raw, or document Lars Magne Ingebrigtsen 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-31 15:33 ` Lars Magne Ingebrigtsen 2012-04-10 2:24 ` Lars Magne Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).