* reverting CJK input methods
@ 2004-04-29 13:03 Werner LEMBERG
2004-04-30 1:42 ` Kenichi Handa
0 siblings, 1 reply; 56+ messages in thread
From: Werner LEMBERG @ 2004-04-29 13:03 UTC (permalink / raw)
Computers are much faster today, with much more memory. Ken'ichi-san,
what do you think about activating the decode maps for all CJK quail
input methods, and adding a function like `show-input-method-input'
which yields the current input method's input string for the current
character.
Werner
^ permalink raw reply [flat|nested] 56+ messages in thread* Re: reverting CJK input methods 2004-04-29 13:03 reverting CJK input methods Werner LEMBERG @ 2004-04-30 1:42 ` Kenichi Handa 2004-04-30 2:03 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-04-30 1:42 UTC (permalink / raw) Cc: emacs-devel In article <20040429.150303.42778779.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes: > Computers are much faster today, with much more memory. Ken'ichi-san, > what do you think about activating the decode maps for all CJK quail > input methods, and adding a function like `show-input-method-input' > which yields the current input method's input string for the current > character. It's a good idea. But, as computers are much faster, I think we can find a key for a specific character by looking up the quail map. Please evaluate the attached code, activate some input method, input some character, go to that character, and do M-x quail-find-key RET. If that is too slow, another way is to generate the decode map on demand. --- Ken'ichi HANDA handa@m17n.org (defun quail-find-key (char map key) (when (consp map) (let ((translation (car map))) (cond ((integerp translation) (if (= translation char) (throw 'tag key))) ((stringp translation) (if (string-match (string char) translation) (throw 'tag key))) ((vectorp translation) (dotimes (i (length translation)) (let ((target (aref translation i))) (if (integerp target) (if (= target char) (throw 'tag key)) (if (and (= (length target) 1) (= (aref target 0) char)) (throw 'tag key)))))) ((consp translation) (setq translation (cdr translation)) (dotimes (i (length translation)) (let ((target (aref translation i))) (if (integerp target) (if (= target char) (throw 'tag key)) (if (and (= (length target) 1) (= (aref target 0) char)) (throw 'tag key))))))))) (dolist (elt (cdr map)) (quail-find-key char (cdr elt) (cons (car elt) key)))) (defun quail-show-key () (interactive) (let* ((char (following-char)) (key (catch 'tag (quail-find-key char (quail-map) nil)))) (if key (message "%c can be input by typing \"%s\"" char (apply 'string (nreverse key))) (message "%c can't be input by the current input method" char)))) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 1:42 ` Kenichi Handa @ 2004-04-30 2:03 ` Miles Bader 2004-04-30 2:59 ` Miles Bader 2004-04-30 5:06 ` reverting CJK input methods Kenichi Handa 0 siblings, 2 replies; 56+ messages in thread From: Miles Bader @ 2004-04-30 2:03 UTC (permalink / raw) Cc: wl, emacs-devel Kenichi Handa <handa@m17n.org> writes: > Please evaluate the attached code, activate some input method, input > some character, go to that character, and do M-x quail-find-key RET. let: Wrong type argument: listp, quail-japanese-switch-package -miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 2:03 ` Miles Bader @ 2004-04-30 2:59 ` Miles Bader 2004-04-30 11:27 ` Juri Linkov 2004-04-30 5:06 ` reverting CJK input methods Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Miles Bader @ 2004-04-30 2:59 UTC (permalink / raw) Cc: wl, emacs-devel Miles Bader <miles@lsi.nec.co.jp> writes: > let: Wrong type argument: listp, quail-japanese-switch-package Oh, but it seemed to work well with some other input method, like `german'. I think this would be nice to add to the output for `C-u C-x ='. E.g., character: ö (04366, 2294, 0x8f6, U+00F6) charset: latin-iso8859-1 (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) ... keystroke: ö can be input by typing ";" (using the `german' input method) ... -Miles -- Freedom's just another word, for nothing left to lose --Janis Joplin ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 2:59 ` Miles Bader @ 2004-04-30 11:27 ` Juri Linkov 2004-04-30 13:26 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2004-04-30 11:27 UTC (permalink / raw) Cc: emacs-devel, Kenichi Handa Miles Bader <miles@lsi.nec.co.jp> writes: > I think this would be nice to add to the output for `C-u C-x ='. > > character: ö (04366, 2294, 0x8f6, U+00F6) > charset: latin-iso8859-1 > (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) > ... > keystroke: ö can be input by typing ";" > (using the `german' input method) > ... This would be very useful. BTW, another useful feature of `describe-char' is the ability to display information on a character displayed in the *Help* buffer itself. The recent changes in descr-text.el allow to do this, but buttons in the *Help* buffer become broken, because only text properties are copied, but not overlays. To avoid problems of self-referencing to the same buffer, I propose to display information on characters of the *Help* buffer in a separate buffer whose name is generated by `(generate-new-buffer-name "*Help*")': Index: lisp/descr-text.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/descr-text.el,v retrieving revision 1.21 diff -u -r1.21 descr-text.el --- lisp/descr-text.el 21 Apr 2004 01:25:17 -0000 1.21 +++ lisp/descr-text.el 30 Apr 2004 11:04:11 -0000 @@ -474,7 +474,6 @@ standard-display-table)) (disp-vector (and display-table (aref display-table char))) (multibyte-p enable-multibyte-characters) - text-prop-description item-list max-width unicode) (if (eq charset 'unknown) (setq item-list @@ -583,15 +582,10 @@ (cons (list "Unicode data" " ") unicodedata)))))) (setq max-width (apply #'max (mapcar #'(lambda (x) (length (car x))) item-list))) - (setq text-prop-description - (with-temp-buffer - (let ((buf (current-buffer))) - (save-excursion - (set-buffer buffer) - (describe-text-properties pos buf))) - (buffer-string))) - - (with-output-to-temp-buffer "*Help*" + (with-output-to-temp-buffer + (if (eq (current-buffer) (get-buffer "*Help*")) + (generate-new-buffer-name "*Help*") + "*Help*") (with-current-buffer standard-output (set-buffer-multibyte multibyte-p) (let ((formatter (format "%%%ds:" max-width))) @@ -665,8 +659,10 @@ (insert "\nSee the variable `reference-point-alist' for " "the meaning of the rule.\n")) - (insert text-prop-description) - (describe-text-mode))))) + (let ((output (current-buffer))) + (with-current-buffer buffer + (describe-text-properties pos output)) + (describe-text-mode)))))) (defalias 'describe-char-after 'describe-char) (make-obsolete 'describe-char-after 'describe-char "21.5") -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 11:27 ` Juri Linkov @ 2004-04-30 13:26 ` Kenichi Handa 2004-05-01 8:22 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-04-30 13:26 UTC (permalink / raw) Cc: emacs-devel, miles In article <87u0z1puxa.fsf@mail.jurta.org>, Juri Linkov <juri@jurta.org> writes: > Miles Bader <miles@lsi.nec.co.jp> writes: >> I think this would be nice to add to the output for `C-u C-x ='. >> >> character: ö (04366, 2294, 0x8f6, U+00F6) >> charset: latin-iso8859-1 >> (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) >> ... >> keystroke: ö can be input by typing ";" >> (using the `german' input method) >> ... > This would be very useful. > BTW, another useful feature of `describe-char' is the ability > to display information on a character displayed in the *Help* > buffer itself. > The recent changes in descr-text.el allow to do this, but buttons > in the *Help* buffer become broken, because only text properties > are copied, but not overlays. To avoid problems of self-referencing > to the same buffer, I propose to display information on characters of > the *Help* buffer in a separate buffer whose name is generated by > `(generate-new-buffer-name "*Help*")': Ah, I didn't notice that failure. How about the attached change instead? Perhaps we should also setup "[back]" widget, but I forgot how to do that. :-( --- Ken'ichi HANDA handa@m17n.org *** descr-text.el 21 Apr 2004 10:22:12 +0900 1.21 --- descr-text.el 30 Apr 2004 22:19:22 +0900 *************** *** 465,470 **** --- 465,471 ---- (if (>= pos (point-max)) (error "No character follows specified position")) (let* ((char (char-after pos)) + (char-string (buffer-substring pos (1+ pos))) (charset (char-charset char)) (buffer (current-buffer)) (composition (find-composition pos nil nil t)) *************** *** 474,489 **** standard-display-table)) (disp-vector (and display-table (aref display-table char))) (multibyte-p enable-multibyte-characters) ! text-prop-description item-list max-width unicode) (if (eq charset 'unknown) ! (setq item-list ! `(("character" ! ,(format "%s (0%o, %d, 0x%x) -- invalid character code" ! (if (< char 256) ! (single-key-description char) ! (char-to-string char)) ! char char char)))) (if (or (< char 256) (memq 'mule-utf-8 (find-coding-systems-region pos (1+ pos))) --- 475,485 ---- standard-display-table)) (disp-vector (and display-table (aref display-table char))) (multibyte-p enable-multibyte-characters) ! (overlays (mapcar #'(lambda (o) (overlay-properties o)) ! (overlays-at pos))) item-list max-width unicode) (if (eq charset 'unknown) ! (setq item-list '"character") (if (or (< char 256) (memq 'mule-utf-8 (find-coding-systems-region pos (1+ pos))) *************** *** 491,504 **** (setq unicode (or (get-char-property pos 'untranslated-utf-8) (encode-char char 'ucs)))) (setq item-list ! `(("character" ! ,(format "%s (0%o, %d, 0x%x%s)" (if (< char 256) ! (single-key-description char) ! (char-to-string char)) ! char char char ! (if unicode ! (format ", U+%04X" unicode) ! ""))) ("charset" ,(symbol-name charset) ,(format "(%s)" (charset-description charset))) --- 487,493 ---- (setq unicode (or (get-char-property pos 'untranslated-utf-8) (encode-char char 'ucs)))) (setq item-list ! `(("character") ("charset" ,(symbol-name charset) ,(format "(%s)" (charset-description charset))) *************** *** 583,600 **** (cons (list "Unicode data" " ") unicodedata)))))) (setq max-width (apply #'max (mapcar #'(lambda (x) (length (car x))) item-list))) ! (setq text-prop-description ! (with-temp-buffer ! (let ((buf (current-buffer))) ! (save-excursion ! (set-buffer buffer) ! (describe-text-properties pos buf))) ! (buffer-string))) (with-output-to-temp-buffer "*Help*" (with-current-buffer standard-output (set-buffer-multibyte multibyte-p) (let ((formatter (format "%%%ds:" max-width))) (dolist (elt item-list) (when (cadr elt) (insert (format formatter (car elt))) --- 572,602 ---- (cons (list "Unicode data" " ") unicodedata)))))) (setq max-width (apply #'max (mapcar #'(lambda (x) (length (car x))) item-list))) ! (pop item-list) (with-output-to-temp-buffer "*Help*" (with-current-buffer standard-output (set-buffer-multibyte multibyte-p) (let ((formatter (format "%%%ds:" max-width))) + (insert (format formatter "character") " ") + (setq pos (point)) + (insert char-string + (format " (`%s', 0%o, %d, 0x%x" + (if (< char 256) + (single-key-description char) + (char-to-string char)) + char char char) + (if (eq charset 'unknown) + ") -- invalid character code\n" + (if unicode + (format ", U+%04X)\n" unicode) + ")\n"))) + (mapc #'(lambda (props) + (let ((o (make-overlay pos (1+ pos)))) + (while props + (overlay-put o (car props) (nth 1 props)) + (setq props (cddr props))))) + overlays) (dolist (elt item-list) (when (cadr elt) (insert (format formatter (car elt))) *************** *** 665,671 **** (insert "\nSee the variable `reference-point-alist' for " "the meaning of the rule.\n")) ! (insert text-prop-description) (describe-text-mode))))) (defalias 'describe-char-after 'describe-char) --- 667,673 ---- (insert "\nSee the variable `reference-point-alist' for " "the meaning of the rule.\n")) ! (describe-text-properties pos (current-buffer)) (describe-text-mode))))) (defalias 'describe-char-after 'describe-char) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 13:26 ` Kenichi Handa @ 2004-05-01 8:22 ` Juri Linkov 2004-05-02 1:57 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2004-05-01 8:22 UTC (permalink / raw) Cc: emacs-devel Kenichi Handa <handa@m17n.org> writes: > How about the attached change instead? Perhaps we should also setup > "[back]" widget, but I forgot how to do that. :-( Thank you, it works fine. Perhaps "[back]" button is not needed in this rare case. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-01 8:22 ` Juri Linkov @ 2004-05-02 1:57 ` Kenichi Handa 2004-05-06 5:05 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-02 1:57 UTC (permalink / raw) Cc: emacs-devel In article <8765bga5tt.fsf@mail.jurta.org>, Juri Linkov <juri@jurta.org> writes: > Kenichi Handa <handa@m17n.org> writes: >> How about the attached change instead? Perhaps we should also setup >> "[back]" widget, but I forgot how to do that. :-( > Thank you, it works fine. Perhaps "[back]" button is not needed > in this rare case. Thank you for testint it. I've just installed that change. Juri Linkov <juri@jurta.org> writes: > Kenichi Handa <handa@m17n.org> writes: >> ! (setq item-list '"character") > There is one typo in your patch. This should be simply string > without quote. Though, quoted string is the same as string. Oops, it should be this: (setq item-list '("character")) --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-02 1:57 ` Kenichi Handa @ 2004-05-06 5:05 ` Kenichi Handa 2004-05-06 11:48 ` Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-06 5:05 UTC (permalink / raw) Cc: juri In article <200405020157.KAA07108@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes: > In article <8765bga5tt.fsf@mail.jurta.org>, Juri Linkov <juri@jurta.org> writes: >> Kenichi Handa <handa@m17n.org> writes: >>> How about the attached change instead? Perhaps we should also setup >>> "[back]" widget, but I forgot how to do that. :-( >> Thank you, it works fine. Perhaps "[back]" button is not needed >> in this rare case. > Thank you for testint it. I've just installed that change. Ummm, I found a bug in this change. It signals an error if point is on a read-only text. While trying to fix it, I found this problem. Once we insert a read-only text in *Help* buffer, all succeeding (with-output-to-temp-buffer "*Help*" ...) fails because the function temp_output_buffer_setup calls Ferase_buffer and it signals the error "Text is read-only". Should we bind inhibit-read-only to t while calling Ferase_buffer, or modify Ferase_buffer itself so that it doesn't signal the above error? The docsting of erase-buffer is this: Delete the entire contents of the current buffer. Any narrowing restriction in effect (see `narrow-to-region') is removed, so the buffer is truly empty after this. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 5:05 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Kenichi Handa @ 2004-05-06 11:48 ` Richard Stallman 2004-05-06 13:10 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2004-05-06 11:48 UTC (permalink / raw) Cc: juri, emacs-devel fails because the function temp_output_buffer_setup calls Ferase_buffer and it signals the error "Text is read-only". Should we bind inhibit-read-only to t while calling Ferase_buffer, That is the right fix. or modify Ferase_buffer itself so that it doesn't signal the above error? This would be incorrect. As a general principle: don't make a general facility less natural or harder to describe, in order to solve a problem that occurs with a specific use of that facility. Instead, fix the specific use. Only change the general facility if there's a reason to think it would be better, as a general facility, with the change. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 11:48 ` Richard Stallman @ 2004-05-06 13:10 ` Kenichi Handa 2004-05-06 14:27 ` Stefan Monnier 2004-05-08 1:20 ` Richard Stallman 0 siblings, 2 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-06 13:10 UTC (permalink / raw) Cc: juri, emacs-devel In article <E1BLhN3-0000lY-44@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes: > fails because the function temp_output_buffer_setup calls > Ferase_buffer and it signals the error "Text is read-only". > Should we bind inhibit-read-only to t while calling > Ferase_buffer, > That is the right fix. > or modify Ferase_buffer itself so that it > doesn't signal the above error? > This would be incorrect. > As a general principle: don't make a general facility less natural or > harder to describe, in order to solve a problem that occurs with a > specific use of that facility. Instead, fix the specific use. > Only change the general facility if there's a reason to think > it would be better, as a general facility, with the change. I fully agree with that general principle. But, for the current case, I'm not sure it is the right thing that erase-buffer signals such an error considering that it removes even the narrowing restriction. I grepped Ferase_buffer in src/*.c and found that this also causes the similar problem. (put-text-property 1 10 'help-echo (propertize "test tip" 'read-only t)) Once we add read-only text as a tool-tip (of course it's nonsense to do such a thing), no more tooltip pops up because the " *tip" buffer can't be erased by Ferase_buffer. Another case is display-message-or-buffer. If we eval this once, (display-message-or-buffer (propertize "abc\n\n" 'read-only t)) the further try causes "Text is read-only" error. I fear there's many other codes that pay attention to buffer-read-only but not to read-only text-property. In almost all cases, I think what they want is to erase a buffer completely including read-only text. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 13:10 ` Kenichi Handa @ 2004-05-06 14:27 ` Stefan Monnier 2004-05-06 15:49 ` Kevin Rodgers 2004-05-07 1:53 ` Kenichi Handa 2004-05-08 1:20 ` Richard Stallman 1 sibling, 2 replies; 56+ messages in thread From: Stefan Monnier @ 2004-05-06 14:27 UTC (permalink / raw) Cc: juri, rms, emacs-devel > I fear there's many other codes that pay attention to > buffer-read-only but not to read-only text-property. In > almost all cases, I think what they want is to erase a > buffer completely including read-only text. Then maybe erase-buffer should do something like (let ((inhibit-read-only (not buffer-read-only))) Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 14:27 ` Stefan Monnier @ 2004-05-06 15:49 ` Kevin Rodgers 2004-05-06 16:50 ` Stefan Monnier 2004-05-07 1:53 ` Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Kevin Rodgers @ 2004-05-06 15:49 UTC (permalink / raw) Stefan Monnier wrote: >>I fear there's many other codes that pay attention to >>buffer-read-only but not to read-only text-property. In >>almost all cases, I think what they want is to erase a >>buffer completely including read-only text. > > Then maybe erase-buffer should do something like > (let ((inhibit-read-only (not buffer-read-only))) I don't understand why that should not be the caller's responsibility. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 15:49 ` Kevin Rodgers @ 2004-05-06 16:50 ` Stefan Monnier 2004-05-06 20:57 ` Kevin Rodgers 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2004-05-06 16:50 UTC (permalink / raw) Cc: emacs-devel > > Then maybe erase-buffer should do something like > > (let ((inhibit-read-only (not buffer-read-only))) > I don't understand why that should not be the caller's responsibility. Of course, the caller could do it, but experience seems to indicate that all callers need to do it (and many forget), so it might make sense to do it in erase-buffer. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 16:50 ` Stefan Monnier @ 2004-05-06 20:57 ` Kevin Rodgers 0 siblings, 0 replies; 56+ messages in thread From: Kevin Rodgers @ 2004-05-06 20:57 UTC (permalink / raw) Stefan Monnier wrote: >>>Then maybe erase-buffer should do something like >>>(let ((inhibit-read-only (not buffer-read-only))) >>> >>I don't understand why that should not be the caller's responsibility. > > Of course, the caller could do it, but experience seems to indicate that > all callers need to do it (and many forget), so it might make sense to do > it in erase-buffer. I understand now: read-only buffers would not be affected, just modifiable buffers with read-only text. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 14:27 ` Stefan Monnier 2004-05-06 15:49 ` Kevin Rodgers @ 2004-05-07 1:53 ` Kenichi Handa 1 sibling, 0 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-07 1:53 UTC (permalink / raw) Cc: juri, rms, emacs-devel In article <jwvisf9oclw.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >> I fear there's many other codes that pay attention to >> buffer-read-only but not to read-only text-property. In >> almost all cases, I think what they want is to erase a >> buffer completely including read-only text. > Then maybe erase-buffer should do something like > (let ((inhibit-read-only (not buffer-read-only))) Ah, yes. It seems that buffer-read-only is a stronger specification for read-only-ness than read-only text property. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-06 13:10 ` Kenichi Handa 2004-05-06 14:27 ` Stefan Monnier @ 2004-05-08 1:20 ` Richard Stallman 2004-05-10 12:13 ` Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Richard Stallman @ 2004-05-08 1:20 UTC (permalink / raw) Cc: juri, emacs-devel I fully agree with that general principle. But, for the current case, I'm not sure it is the right thing that erase-buffer signals such an error considering that it removes even the narrowing restriction. I think I partly misunderstood the problem. Is the problem that erase-buffer gets an error when there is read-only text in the buffer? Maybe you're right that it should not get an error for that. However, consider the case of a Customize buffer. That has lots of read-only text, the idea being that the user should not be able to edit it. Should erase-buffer in a Customize buffer leave it empty? The result would be an undesirable confusion. We could respond to that by saying, "So don't do erase-buffer in a Customize buffer." Maybe that's right, but I am not sure. So it seems to me that there are some cases where we want erase-buffer to get rid of read-only text silently, but not all cases. It seems better to change the callers, not change erase-buffer. If we eval this once, (display-message-or-buffer (propertize "abc\n\n" 'read-only t)) That is clearly a bug, but I think the right fix is to change the caller here too. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-08 1:20 ` Richard Stallman @ 2004-05-10 12:13 ` Kenichi Handa 2004-05-10 14:28 ` Stefan Monnier 2004-05-11 1:45 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Luc Teirlinck 0 siblings, 2 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-10 12:13 UTC (permalink / raw) Cc: juri, emacs-devel In article <E1BMGVn-0000xh-3r@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes: > I fully agree with that general principle. But, for the > current case, I'm not sure it is the right thing that > erase-buffer signals such an error considering that it > removes even the narrowing restriction. > I think I partly misunderstood the problem. Is the problem that > erase-buffer gets an error when there is read-only text in the buffer? Yes. > Maybe you're right that it should not get an error for that. > However, consider the case of a Customize buffer. That has lots of > read-only text, the idea being that the user should not be able to > edit it. Should erase-buffer in a Customize buffer leave it empty? > The result would be an undesirable confusion. We could respond to > that by saying, "So don't do erase-buffer in a Customize buffer." > Maybe that's right, but I am not sure. I think "So don't do ..." is sufficient. > So it seems to me that there are some cases where we want erase-buffer > to get rid of read-only text silently, but not all cases. It seems > better to change the callers, not change erase-buffer. > If we eval this once, > (display-message-or-buffer (propertize "abc\n\n" 'read-only t)) > That is clearly a bug, but I think the right fix is to change the > caller here too. Ok, I've just installed these changes in addition to fix of describe-char. 2004-05-10 Kenichi Handa <handa@m17n.org> * print.c (temp_output_buffer_setup): Bind inhibit-read-only and inhibit-modification-hooks to t temporarily before calling Ferase_buffer. * xfns.c (x_create_tip_frame): Bind inhibit-read-only and inhibit-modification-hooks to t temporarily before calling Ferase_buffer. * w32fns.c (x_create_tip_frame): Bind inhibit-read-only and inhibit-modification-hooks to t temporarily before calling Ferase_buffer. But I still believe it is better to change erase-buffer itself (perhaps it should delete all overlays too). Let's discuss it after the next release. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-10 12:13 ` Kenichi Handa @ 2004-05-10 14:28 ` Stefan Monnier 2004-05-11 7:04 ` Richard Stallman 2004-05-11 1:45 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Luc Teirlinck 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2004-05-10 14:28 UTC (permalink / raw) Cc: juri, rms, emacs-devel >> However, consider the case of a Customize buffer. That has lots of >> read-only text, the idea being that the user should not be able to >> edit it. The read-only properties are present only to delimit the fields so people only edit the text where Custom knows what to do with the edits. If the user wants to empty the buffer, there's no point preventing him from doing that, I think. >> Should erase-buffer in a Customize buffer leave it empty? Yes. >> The result would be an undesirable confusion. In what way could it be confusing? >> We could respond to that by saying, "So don't do erase-buffer in >> a Customize buffer." Maybe that's right, but I am not sure. > I think "So don't do ..." is sufficient. Agreed. > But I still believe it is better to change erase-buffer > itself (perhaps it should delete all overlays too). Agreed. > Let's discuss it after the next release. Oh well! Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-10 14:28 ` Stefan Monnier @ 2004-05-11 7:04 ` Richard Stallman 2004-05-11 7:49 ` David Kastrup 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier 0 siblings, 2 replies; 56+ messages in thread From: Richard Stallman @ 2004-05-11 7:04 UTC (permalink / raw) Cc: juri, emacs-devel, handa >> Should erase-buffer in a Customize buffer leave it empty? Yes. >> The result would be an undesirable confusion. In what way could it be confusing? Doesn't Custom create overlays? If you erase the buffer, the overlays will continue to exist; basically, the Custom mechanism won't know that the buffer is empty. I think it is better for erase-buffer to get an error in the Custom buffer. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 7:04 ` Richard Stallman @ 2004-05-11 7:49 ` David Kastrup 2004-05-12 7:51 ` Richard Stallman 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier 1 sibling, 1 reply; 56+ messages in thread From: David Kastrup @ 2004-05-11 7:49 UTC (permalink / raw) Cc: juri, handa, Stefan Monnier, emacs-devel Richard Stallman <rms@gnu.org> writes: > >> Should erase-buffer in a Customize buffer leave it empty? > > Yes. > > >> The result would be an undesirable confusion. > > In what way could it be confusing? > > Doesn't Custom create overlays? If you erase the buffer, > the overlays will continue to exist; They will span empty ranges, though. > basically, the Custom mechanism won't know that the buffer is empty. Well, we had this already. If the user is supposed to be allowed to call erase-buffer (and I don't see anything that would make this a sensible proposition), then the overlays should have the 'evaporate property set. Now your complaint was that user editable fields should probably not evaporate when empty, but the user editable fields are not read-only in the first place! It is a bad idea to protect the user-editable fields by having erase-buffer fail on completely different fields. That is a side effect. Anyway, it might be a good idea if erase-buffer also kills all overlays, after giving them a chance with modification-hooks and evaporate and whatever else there is in way of notification. > I think it is better for erase-buffer to get an error in the Custom > buffer. Even if you think so, I don't think that putting some read-only text in as a side effect is the right way to achieve this. Then it would be saner just to make the buffer-readonly. Or at least restrict the failure on non-evaporating read-only overlays without modification-hook, but let read-only text properties not cause any problems. An evaporating overlay, or one with a non-nil modification-hook _anticipates_ deletion. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 7:49 ` David Kastrup @ 2004-05-12 7:51 ` Richard Stallman 0 siblings, 0 replies; 56+ messages in thread From: Richard Stallman @ 2004-05-12 7:51 UTC (permalink / raw) Cc: juri, handa, monnier, emacs-devel Well, we had this already. If the user is supposed to be allowed to call erase-buffer (and I don't see anything that would make this a sensible proposition), then the overlays should have the 'evaporate property set. Now your complaint was that user editable fields should probably not evaporate when empty, but the user editable fields are not read-only in the first place! The user-editable fields are not read only, and they can be empty, so the overlays must be set not to evaporate. So this solution does not work. I am not sure it is necessary for Custom to work using overlays. Maybe text properties would do the job. They would get eliminated too, if the whole text is deleted. > I think it is better for erase-buffer to get an error in the Custom > buffer. Even if you think so, I don't think that putting some read-only text in as a side effect is the right way to achieve this. I think it makes sense. To have user-editable fields in a buffer implies that there are non-editable parts too. Anyway, it might be a good idea if erase-buffer also kills all overlays, after giving them a chance with modification-hooks and evaporate and whatever else there is in way of notification. That might actually be a good idea. I am not sure, though. ^ permalink raw reply [flat|nested] 56+ messages in thread
* erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 7:04 ` Richard Stallman 2004-05-11 7:49 ` David Kastrup @ 2004-05-11 13:39 ` Stefan Monnier 2004-05-11 14:44 ` erase-buffer Juri Linkov ` (3 more replies) 1 sibling, 4 replies; 56+ messages in thread From: Stefan Monnier @ 2004-05-11 13:39 UTC (permalink / raw) Cc: juri, emacs-devel, handa BTW, it seems the main problem has to do with a conflict between erase-buffer when called interactively and erase-buffer when called from packages. So my question is: why is erase-buffer a command? I didn't know it was a command until 5 days ago, it is not bound to any key, and I can't think of any circumstance where a user might want to say M-x erase-buffer RET. Actually the only case I can think of is when the user knows what he's doing; and allowing the M-x erase-buffer to work in Custom buffers would then still make perfect sense (even if we don't fix the lingering overlays). Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier @ 2004-05-11 14:44 ` Juri Linkov 2004-05-11 16:17 ` erase-buffer Juri Linkov 2004-05-11 15:32 ` erase-buffer (was: with-output-to-temp-buffer) David Kastrup ` (2 subsequent siblings) 3 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2004-05-11 14:44 UTC (permalink / raw) Cc: emacs-devel, rms, handa Stefan Monnier <monnier@iro.umontreal.ca> writes: > So my question is: why is erase-buffer a command? > I didn't know it was a command until 5 days ago, it is not bound to any > key, and I can't think of any circumstance where a user might want to say > M-x erase-buffer RET. Actually the only case I can think of is when the > user knows what he's doing; and allowing the M-x erase-buffer to work in > Custom buffers would then still make perfect sense (even if we don't fix > the lingering overlays). I never used erase-buffer as a command, but as I can see erase-buffer is a disabled command with `disable' property put on its symbol. So as a command it is already safe not to be executed thoughtlessly. PS: I also think that it should remove the current buffer completely with all its overlays. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer 2004-05-11 14:44 ` erase-buffer Juri Linkov @ 2004-05-11 16:17 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2004-05-11 16:17 UTC (permalink / raw) Juri Linkov <juri@jurta.org> writes: > I also think that it should remove the current buffer completely > with all its overlays. I mean to remove the *contents* of the current buffer completely with all overlays and read-only fields. -- Juri Linkov http://www.jurta.org/emacs/ ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier 2004-05-11 14:44 ` erase-buffer Juri Linkov @ 2004-05-11 15:32 ` David Kastrup 2004-05-11 16:22 ` Kevin Rodgers 2004-05-11 18:14 ` Juanma Barranquero 2004-05-11 23:06 ` Kenichi Handa 2004-05-12 19:40 ` Richard Stallman 3 siblings, 2 replies; 56+ messages in thread From: David Kastrup @ 2004-05-11 15:32 UTC (permalink / raw) Cc: juri, handa, rms, emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > BTW, it seems the main problem has to do with a conflict between > erase-buffer when called interactively and erase-buffer when called > from packages. > > So my question is: why is erase-buffer a command? > I didn't know it was a command until 5 days ago, it is not bound to any > key, and I can't think of any circumstance where a user might want to say > M-x erase-buffer RET. Right. At best you want to kill a buffer. > Actually the only case I can think of is when the user knows what > he's doing; and allowing the M-x erase-buffer to work in Custom > buffers would then still make perfect sense (even if we don't fix > the lingering overlays). If one wants to use a command like that, one can always say M-: (erase-buffer) RET I also think that it should not be a command. If you need to erase a buffer for whatever obscure reason, you can clear it with M-h C-w It would at best make marginal sense in, say, a shell-buffer which you find has grown too large for your taste. But even there, you would want to have it remove things like read-only prompt strings. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 15:32 ` erase-buffer (was: with-output-to-temp-buffer) David Kastrup @ 2004-05-11 16:22 ` Kevin Rodgers 2004-05-11 19:30 ` Stefan Monnier 2004-05-11 19:37 ` Juanma Barranquero 2004-05-11 18:14 ` Juanma Barranquero 1 sibling, 2 replies; 56+ messages in thread From: Kevin Rodgers @ 2004-05-11 16:22 UTC (permalink / raw) David Kastrup wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>BTW, it seems the main problem has to do with a conflict between >>erase-buffer when called interactively and erase-buffer when called >>from packages. >> >>So my question is: why is erase-buffer a command? >>I didn't know it was a command until 5 days ago, it is not bound to any >>key, and I can't think of any circumstance where a user might want to say >>M-x erase-buffer RET. > > Right. At best you want to kill a buffer. Wrong. I use it all the time. >>Actually the only case I can think of is when the user knows what >>he's doing; and allowing the M-x erase-buffer to work in Custom >>buffers would then still make perfect sense (even if we don't fix >>the lingering overlays). > > If one wants to use a command like that, one can always say > M-: (erase-buffer) RET Yuck. > I also think that it should not be a command. If you need to erase a > buffer for whatever obscure reason, you can clear it with > M-h C-w I use M-x erase-buffer specifically to avoid munging the kill ring. erase-buffer's (interactive "*") spec will continue to protect users who call it interactively in a read-only buffer. The suggestion that erase-buffer bind inhibit-read-only to (not buffer-read-only) would not affect its interactive use or Lisp function calls in read only buffers, but would allow it to do its job when there are read-only text properties or overlays. I never use M-x customize and don't want it to determine M-x erase-buffer's fate. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 16:22 ` Kevin Rodgers @ 2004-05-11 19:30 ` Stefan Monnier 2004-05-12 21:10 ` Kevin Rodgers 2004-05-11 19:37 ` Juanma Barranquero 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2004-05-11 19:30 UTC (permalink / raw) Cc: emacs-devel > Wrong. I use it all the time. And do you expect/want it to fail in comint and custom buffers, or do you not care because you've never felt the desire to call it in such a buffer? Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 19:30 ` Stefan Monnier @ 2004-05-12 21:10 ` Kevin Rodgers 0 siblings, 0 replies; 56+ messages in thread From: Kevin Rodgers @ 2004-05-12 21:10 UTC (permalink / raw) Stefan Monnier wrote: > And do you expect/want it to fail in comint and custom buffers, > or do you not care because you've never felt the desire to call it in such > a buffer? I use `M-x erase-buffer' the same way Juanma does, but mostly in a *Text* buffer that I've created (instead of *scratch*). Even though I don't use it in comint and custom buffers, I think it should probably signal an error, because that's what `C-x h C-w' and `C-x h M-x delete-region' would do. But it would be nice if `C-u M-x erase-buffer' would work in that context, by binding inhibit-read-only. -- Kevin Rodgers ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 16:22 ` Kevin Rodgers 2004-05-11 19:30 ` Stefan Monnier @ 2004-05-11 19:37 ` Juanma Barranquero 1 sibling, 0 replies; 56+ messages in thread From: Juanma Barranquero @ 2004-05-11 19:37 UTC (permalink / raw) On Tue, 11 May 2004 10:22:10 -0600, Kevin Rodgers <ihs_4664@yahoo.com> wrote: > I never use M-x customize and don't want it to determine M-x > erase-buffer's fate. I agree on both accounts. /L/e/k/t/u ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 15:32 ` erase-buffer (was: with-output-to-temp-buffer) David Kastrup 2004-05-11 16:22 ` Kevin Rodgers @ 2004-05-11 18:14 ` Juanma Barranquero 1 sibling, 0 replies; 56+ messages in thread From: Juanma Barranquero @ 2004-05-11 18:14 UTC (permalink / raw) Cc: David Kastrup On 11 May 2004 17:32:36 +0200, David Kastrup <dak@gnu.org> wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > and I can't think of any circumstance where a user might want to say > > M-x erase-buffer RET. > > Right. At best you want to kill a buffer. Actually, I use M-x erase-buffer quite frequently (though I'm not suicidal enough to bind it to a key). I happen to like to always have a *scratch* buffer around. I use it just for that, scratch: putting away notes for a while, or as a temporary buffer for cut&paste, etc. (the advantage is that in my setup, Emacs warns me if I try to exit it with a non-empty *scratch*). I even have key combinations to switch from any buffer to *scrach* (it saves the selected buffer) and back, because I do it so frequently. So I often do M-x erase-buffer to reset it to a clean state. It's easier (to me, anyway) typing "M-x era TAB RET" than "C-x k RET C-x b *scratch* RET". > If you need to erase a > buffer for whatever obscure reason, you can clear it with > M-h C-w You mean C-x h C-w :) > But even there, you > would want to have it remove things like read-only prompt strings. On that, I agree: you do erase-buffer (in a non-readonly buffer), you get an empty buffer. Any other result would seem ilogical. /L/e/k/t/u ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier 2004-05-11 14:44 ` erase-buffer Juri Linkov 2004-05-11 15:32 ` erase-buffer (was: with-output-to-temp-buffer) David Kastrup @ 2004-05-11 23:06 ` Kenichi Handa 2004-05-11 23:26 ` Miles Bader 2004-05-11 23:34 ` Stefan Monnier 2004-05-12 19:40 ` Richard Stallman 3 siblings, 2 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-11 23:06 UTC (permalink / raw) Cc: juri, rms, emacs-devel In article <877jvjnl4g.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: > BTW, it seems the main problem has to do with a conflict between > erase-buffer when called interactively and erase-buffer when called > from packages. > So my question is: why is erase-buffer a command? > I didn't know it was a command until 5 days ago, it is not bound to any > key, and I can't think of any circumstance where a user might want to say > M-x erase-buffer RET. I often use it in *shell* and *gdb* buffers when they grow too much. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 23:06 ` Kenichi Handa @ 2004-05-11 23:26 ` Miles Bader 2004-05-12 19:42 ` Richard Stallman 2004-05-11 23:34 ` Stefan Monnier 1 sibling, 1 reply; 56+ messages in thread From: Miles Bader @ 2004-05-11 23:26 UTC (permalink / raw) Cc: juri, emacs-devel, monnier, rms On Wed, May 12, 2004 at 08:06:21AM +0900, Kenichi Handa wrote: > > So my question is: why is erase-buffer a command? > > I didn't know it was a command until 5 days ago, it is not bound to any > > key, and I can't think of any circumstance where a user might want to say > > M-x erase-buffer RET. > > I often use it in *shell* and *gdb* buffers when they grow > too much. It's a `weird' command in the way it ignores normal restrictions though. I think for user-use, it might make more sense to define some other command that acts more normally (i.e., obeys buffer narrowing, etc.). Perhaps call it `delete-whole-buffer' (analogous to `mark-whole-buffer'). [Are there in fact programmatic uses that depend on erase-buffer's weird behavior? I'll bet in some cases, it might actually be a bug...] -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 23:26 ` Miles Bader @ 2004-05-12 19:42 ` Richard Stallman 2004-05-12 22:34 ` Miles Bader 0 siblings, 1 reply; 56+ messages in thread From: Richard Stallman @ 2004-05-12 19:42 UTC (permalink / raw) Cc: juri, emacs-devel, monnier, handa I think for user-use, it might make more sense to define some other command that acts more normally (i.e., obeys buffer narrowing, etc.). Perhaps call it `delete-whole-buffer' (analogous to `mark-whole-buffer'). That would be several more characters to type, given the existing completion alternatives, and I see no need for the change. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-12 19:42 ` Richard Stallman @ 2004-05-12 22:34 ` Miles Bader 2004-05-14 9:21 ` Richard Stallman 0 siblings, 1 reply; 56+ messages in thread From: Miles Bader @ 2004-05-12 22:34 UTC (permalink / raw) Cc: juri, handa, emacs-devel, monnier, Miles Bader On Wed, May 12, 2004 at 03:42:01PM -0400, Richard Stallman wrote: > I think for user-use, it might make more sense to define some other > command that acts more normally (i.e., obeys buffer narrowing, etc.). > Perhaps call it `delete-whole-buffer' (analogous to > `mark-whole-buffer'). > > That would be several more characters to type, > given the existing completion alternatives, > and I see no need for the change. Is this really a command you (1) use often, but (2) don't have bound anywhere??? Is there some practical justification for the odd way it works? -Miles -- Suburbia: where they tear out the trees and then name streets after them. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-12 22:34 ` Miles Bader @ 2004-05-14 9:21 ` Richard Stallman 0 siblings, 0 replies; 56+ messages in thread From: Richard Stallman @ 2004-05-14 9:21 UTC (permalink / raw) Cc: juri, handa, emacs-devel, monnier, miles Is this really a command you (1) use often, but (2) don't have bound anywhere??? I use it often enough, but not so often I would want to make a key binding. Is there some practical justification for the odd way it works? It does not seem odd to me. What do you consider odd? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 23:06 ` Kenichi Handa 2004-05-11 23:26 ` Miles Bader @ 2004-05-11 23:34 ` Stefan Monnier 2004-05-11 23:47 ` Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2004-05-11 23:34 UTC (permalink / raw) Cc: juri, rms, emacs-devel >> M-x erase-buffer RET. > I often use it in *shell* and *gdb* buffers when they grow too much. Why not comint-truncate-buffer? Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 23:34 ` Stefan Monnier @ 2004-05-11 23:47 ` Kenichi Handa 0 siblings, 0 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-11 23:47 UTC (permalink / raw) Cc: juri, rms, emacs-devel In article <jwvbrkusfm3.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> M-x erase-buffer RET. >> I often use it in *shell* and *gdb* buffers when they grow too much. > Why not comint-truncate-buffer? M-x era RET is shorter than M-x comint-t RET. The more realistic reason is that the former is more reliable because the latter leaves comint-buffer-maximum-size lines and that may be still huge when a program produces long output without newlines. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: erase-buffer (was: with-output-to-temp-buffer) 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier ` (2 preceding siblings ...) 2004-05-11 23:06 ` Kenichi Handa @ 2004-05-12 19:40 ` Richard Stallman 3 siblings, 0 replies; 56+ messages in thread From: Richard Stallman @ 2004-05-12 19:40 UTC (permalink / raw) Cc: juri, emacs-devel, handa I fairly often use M-x erase-buffer. I could use C-x h C-w. I think my original reason for starting to use erase-buffer was to avoid putting the text in the kill ring. Often these are fairly big buffers. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-10 12:13 ` Kenichi Handa 2004-05-10 14:28 ` Stefan Monnier @ 2004-05-11 1:45 ` Luc Teirlinck 2004-05-11 2:34 ` Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Luc Teirlinck @ 2004-05-11 1:45 UTC (permalink / raw) Cc: juri, rms, emacs-devel Ken'ichi HANDA wrote: But I still believe it is better to change erase-buffer itself (perhaps it should delete all overlays too). Let's discuss it after the next release. I do not understand why we should wait till after the next release to make a decision on this issue. If we do not change `erase-buffer', then I suspect that we will have to bind inhibit-read-only to t around several calls to erase-buffer. When we would decide after the release to change erase-buffer, then not only would we have done all that work for nothing, but we even would have to do the additional work of undoing all these changes. Why can a _final_ decision not be made right now? We are talking about the best way to deal with existing bugs, not about a new feature, so the feature freeze is irrelevant. Sincerely, Luc. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 1:45 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Luc Teirlinck @ 2004-05-11 2:34 ` Kenichi Handa 2004-05-11 7:01 ` David Kastrup 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-11 2:34 UTC (permalink / raw) Cc: juri, rms, emacs-devel In article <200405110145.i4B1jNF22171@raven.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Ken'ichi HANDA wrote: > But I still believe it is better to change erase-buffer > itself (perhaps it should delete all overlays too). Let's > discuss it after the next release. > I do not understand why we should wait till after the next release to > make a decision on this issue. If we do not change `erase-buffer', > then I suspect that we will have to bind inhibit-read-only to t around > several calls to erase-buffer. When we would decide after the release to > change erase-buffer, then not only would we have done all that work > for nothing, but we even would have to do the additional work of > undoing all these changes. > Why can a _final_ decision not be made right now? We are talking about > the best way to deal with existing bugs, not about a new feature, so > the feature freeze is irrelevant. This problem has been there for long (perhaps just after read-only text property was introduced) but has never been reported. It was just revealed by my attempt to fix describe-char. That means that we can live without changing it. In addtion, to make a final decision, we must study how erase-buffer is used in various codes, which consumes our working time much and results in the delay of the next release. I think the sooner release is more important than completely settling on what to do with this problem. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 2:34 ` Kenichi Handa @ 2004-05-11 7:01 ` David Kastrup 2004-05-11 6:55 ` Kim F. Storm ` (2 more replies) 0 siblings, 3 replies; 56+ messages in thread From: David Kastrup @ 2004-05-11 7:01 UTC (permalink / raw) Cc: juri, teirllm, rms, emacs-devel Kenichi Handa <handa@m17n.org> writes: > In article <200405110145.i4B1jNF22171@raven.dms.auburn.edu>, Luc > Teirlinck <teirllm@dms.auburn.edu> writes: > > > Ken'ichi HANDA wrote: > > But I still believe it is better to change erase-buffer > > itself (perhaps it should delete all overlays too). Let's > > discuss it after the next release. > > This problem has been there for long (perhaps just after > read-only text property was introduced) but has never been > reported. It was just revealed by my attempt to fix > describe-char. That means that we can live without changing > it. > > In addtion, to make a final decision, we must study how > erase-buffer is used in various codes, which consumes our > working time much and results in the delay of the next > release. I think the sooner release is more important than > completely settling on what to do with this problem. Can anyone think of any reason why erase-buffer should not remove the current buffer completely? And no, I don't think that read-only properties on some entries in a buffer count as a reason: erase-buffer is basically a buffer-wide operation and should only be influenced by buffer-wide read-only-ness. If you want to protect your buffer against erasure, set the whole buffer to read-only. Or signal errors in before-change-functions, without actually doing the change. That is easy enough to do, and much more reliable. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 7:01 ` David Kastrup @ 2004-05-11 6:55 ` Kim F. Storm 2004-05-11 8:00 ` Kenichi Handa 2004-05-12 7:51 ` Richard Stallman 2 siblings, 0 replies; 56+ messages in thread From: Kim F. Storm @ 2004-05-11 6:55 UTC (permalink / raw) Cc: juri, emacs-devel, teirllm, rms, Kenichi Handa David Kastrup <dak@gnu.org> writes: > Kenichi Handa <handa@m17n.org> writes: > > In addtion, to make a final decision, we must study how > > erase-buffer is used in various codes, which consumes our > > working time much and results in the delay of the next > > release. I think the sooner release is more important than > > completely settling on what to do with this problem. > > Can anyone think of any reason why erase-buffer should not remove the > current buffer completely? And no, I don't think that read-only > properties on some entries in a buffer count as a reason: > erase-buffer is basically a buffer-wide operation and should only be > influenced by buffer-wide read-only-ness. > > If you want to protect your buffer against erasure, set the whole > buffer to read-only. Or signal errors in before-change-functions, > without actually doing the change. > > That is easy enough to do, and much more reliable. I agree. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 7:01 ` David Kastrup 2004-05-11 6:55 ` Kim F. Storm @ 2004-05-11 8:00 ` Kenichi Handa 2004-05-12 7:51 ` Richard Stallman 2 siblings, 0 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-11 8:00 UTC (permalink / raw) Cc: juri, teirllm, rms, emacs-devel In article <x5zn8fxx9d.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes: > Can anyone think of any reason why erase-buffer should not remove the > current buffer completely? And no, I don't think that read-only > properties on some entries in a buffer count as a reason: > erase-buffer is basically a buffer-wide operation and should only be > influenced by buffer-wide read-only-ness. > If you want to protect your buffer against erasure, set the whole > buffer to read-only. Or signal errors in before-change-functions, > without actually doing the change. > That is easy enough to do, and much more reliable. Can you confirm that all lisp codes do above to protect its managing buffer instead of just setting some part read-only? The document of erase-buffer clearly says that it signals an error on read-only text. - Command: erase-buffer This function deletes the entire text of the current buffer, leaving it empty. If the buffer is read-only, it signals a `buffer-read-only' error; if some of the text in it is read-only, it signals a `text-read-only' error. Otherwise, it deletes the text without asking for any confirmation. It returns `nil'. That means there may be a code depending on that feature. We had better leave it unchanged at this moment of before the release. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: with-output-to-temp-buffer [Re: reverting CJK input methods] 2004-05-11 7:01 ` David Kastrup 2004-05-11 6:55 ` Kim F. Storm 2004-05-11 8:00 ` Kenichi Handa @ 2004-05-12 7:51 ` Richard Stallman 2 siblings, 0 replies; 56+ messages in thread From: Richard Stallman @ 2004-05-12 7:51 UTC (permalink / raw) Cc: juri, emacs-devel, teirllm, handa If you want to protect your buffer against erasure, set the whole buffer to read-only. Custom buffers certainly can't do that. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 2:03 ` Miles Bader 2004-04-30 2:59 ` Miles Bader @ 2004-04-30 5:06 ` Kenichi Handa 2004-04-30 16:50 ` Werner LEMBERG 2004-05-01 17:21 ` Werner LEMBERG 1 sibling, 2 replies; 56+ messages in thread From: Kenichi Handa @ 2004-04-30 5:06 UTC (permalink / raw) Cc: wl, emacs-devel In article <buo1xm6jk82.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes: > Kenichi Handa <handa@m17n.org> writes: >> Please evaluate the attached code, activate some input method, input >> some character, go to that character, and do M-x quail-find-key RET. > let: Wrong type argument: listp, quail-japanese-switch-package Oops, please try the attached new one. But, for the input method "Japanese", we can't show key for Kanji characters because the Kanji characters are generated from the input hiragana sequence by the different program than quail. > Oh, but it seemed to work well with some other input method, like > `german'. > I think this would be nice to add to the output for `C-u C-x ='. > E.g., > character: ö (04366, 2294, 0x8f6, U+00F6) > charset: latin-iso8859-1 > (Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100.) > ... > keystroke: ö can be input by typing ";" > (using the `german' input method) > ... Ah, yes, this is also a good idea. --- Ken'ichi HANDA handa@m17n.org (defun quail-find-key (char map key) (when (and (consp map) (listp (cdr map))) (let ((translation (car map))) (cond ((integerp translation) (if (= translation char) (throw 'tag key))) ((stringp translation) (if (string-match (string char) translation) (throw 'tag key))) ((vectorp translation) (dotimes (i (length translation)) (let ((target (aref translation i))) (if (integerp target) (if (= target char) (throw 'tag key)) (if (and (= (length target) 1) (= (aref target 0) char)) (throw 'tag key)))))) ((consp translation) (setq translation (cdr translation)) (dotimes (i (length translation)) (let ((target (aref translation i))) (if (integerp target) (if (= target char) (throw 'tag key)) (if (and (= (length target) 1) (= (aref target 0) char)) (throw 'tag key)))))))) (dolist (elt (cdr map)) (quail-find-key char (cdr elt) (cons (car elt) key))))) (defun quail-show-key () (interactive) (let* ((char (following-char)) (key (catch 'tag (quail-find-key char (quail-map) nil)))) (if key (message "%c can be input by typing \"%s\"" char (apply 'string (nreverse key))) (message "%c can't be input by the current input method" char)))) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 5:06 ` reverting CJK input methods Kenichi Handa @ 2004-04-30 16:50 ` Werner LEMBERG 2004-05-01 9:07 ` Miles Bader 2004-05-08 2:56 ` Kenichi Handa 2004-05-01 17:21 ` Werner LEMBERG 1 sibling, 2 replies; 56+ messages in thread From: Werner LEMBERG @ 2004-04-30 16:50 UTC (permalink / raw) Cc: emacs-devel, miles > Oops, please try the attached new one. It works, thanks! But I think it is too slow. On my laptop, testing chinese-4corner, it takes up to two seconds until the result is displayed. Maybe input methods with more than, say, six to seven thousand elements should use the inverse map. > But, for the input method "Japanese", we can't show key for Kanji > characters because the Kanji characters are generated from the input > hiragana sequence by the different program than quail. It would be *very* nice if the surrounding of the current character could be used to find some Japanese phrases... Werner ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 16:50 ` Werner LEMBERG @ 2004-05-01 9:07 ` Miles Bader 2004-05-01 17:18 ` Werner LEMBERG 2004-05-08 2:56 ` Kenichi Handa 1 sibling, 1 reply; 56+ messages in thread From: Miles Bader @ 2004-05-01 9:07 UTC (permalink / raw) Cc: miles, emacs-devel, handa On Fri, Apr 30, 2004 at 06:50:42PM +0200, Werner LEMBERG wrote: > It would be *very* nice if the surrounding of the current character > could be used to find some Japanese phrases... What do you mean exactly? I've got an edict hack that does pretty painless dictionary lookup. -Miles -- If you can't beat them, arrange to have them beaten. [George Carlin] ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-01 9:07 ` Miles Bader @ 2004-05-01 17:18 ` Werner LEMBERG 0 siblings, 0 replies; 56+ messages in thread From: Werner LEMBERG @ 2004-05-01 17:18 UTC (permalink / raw) Cc: emacs-devel, handa > > It would be *very* nice if the surrounding of the current > > character could be used to find some Japanese phrases... > > What do you mean exactly? Ideally, some contextual analysis would be fine to get the right meaning of a Kanji -- I fear this is beyond skk-dic... > I've got an edict hack that does pretty painless dictionary lookup. Please explain in more detail. Werner ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 16:50 ` Werner LEMBERG 2004-05-01 9:07 ` Miles Bader @ 2004-05-08 2:56 ` Kenichi Handa 2004-05-08 16:38 ` Werner LEMBERG 1 sibling, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-08 2:56 UTC (permalink / raw) Cc: miles, emacs-devel [-- Attachment #1: Type: text/plain, Size: 5201 bytes --] In article <20040430.185042.217838345.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes: >> Oops, please try the attached new one. > It works, thanks! But I think it is too slow. On my laptop, testing > chinese-4corner, it takes up to two seconds until the result is > displayed. Maybe input methods with more than, say, six to seven > thousand elements should use the inverse map. I still insist on generating a key strings to type on demand instead of generating a decode-map at loading an input method because the generation anyway takes some time. So, I decided to generate a halfly cooked decode-map on demand, which results in, I hope, reasonable speed for M-x quail-show-key both at the first attempt and the succeeding attemts. Please try the attached new one after byte-compiling it. > Is it possible to get *all* possible input sequences? For example, 说 > (shuo1) can also be input as `yue4' in chinese-tonepy, and this is > what your code currently returns. Yes, the new code shows all key strings. --- Ken'ichi HANDA handa@m17n.org (require 'quail) ;; Add KEY (string) to the element of TABLE (char-table) for CHAR if ;; it is not yet stored. (defsubst quail-store-decode-map-key (table char key) (let ((elt (aref table char))) (if elt (if (consp elt) (or (member key elt) (aset table char (cons key elt))) (or (string= key elt) (aset table char (list key elt)))) (aset table char key)))) ;; Helper function for quail-gen-decode-map. Store key strings to ;; type each character under MAP in TABLE (char-table). MAP is an ;; element of the current Quail map reached by typing keys in KEY ;; (string). (defun quail-gen-decode-map1 (map key table) (when (and (consp map) (listp (cdr map))) (let ((trans (car map))) (cond ((integerp trans) (quail-store-decode-map-key table trans key)) ((stringp trans) (dotimes (i (length trans)) (quail-store-decode-map-key table (aref trans i) key))) ((or (vectorp trans) (and (consp trans) (setq trans (cdr trans)))) (dotimes (i (length trans)) (let ((elt (aref trans i))) (if (stringp elt) (if (= (length elt) 1) (quail-store-decode-map-key table (aref elt 0) key)) (quail-store-decode-map-key table elt key))))))) (if (> (length key) 1) (dolist (elt (cdr map)) (quail-gen-decode-map1 (cdr elt) key table)) (dolist (elt (cdr map)) (quail-gen-decode-map1 (cdr elt) (format "%s%c" key (car elt)) table))))) (put 'quail-decode-map 'char-table-extra-slots 0) ;; Generate a decode map (char-table) for the current Quail map. (defun quail-gen-decode-map () (let ((table (make-char-table 'quail-decode-map nil))) (dolist (elt (cdr (quail-map))) (quail-gen-decode-map1 (cdr elt) (string (car elt)) table)) table)) ;; Helper function for quail-find-key. Prepend key strings to type ;; for inputting CHAR by the current input method to KEY-LIST and ;; return the result. MAP is an element of the current Quail map ;; reached by typing keys in KEY. (defun quail-find-key1 (map key char key-list) (let ((trans (car map)) (found-here nil)) (cond ((stringp trans) (setq found-here (and (= (length trans) 1) (= (aref trans 0) char)))) ((or (vectorp trans) (consp trans)) (if (consp trans) (setq trans (cdr trans))) (setq found-here (catch 'tag (dotimes (i (length trans)) (let ((target (aref trans i))) (if (integerp target) (if (= target char) (throw 'tag t)) (if (and (= (length target) 1) (= (aref target 0) char)) (throw 'tag t)))))))) ((integerp trans) (if (= trans char) (setq found-here t)))) (if found-here (setq key-list (cons key key-list))) (if (> (length key) 1) (dolist (elt (cdr map)) (setq key-list (quail-find-key1 (cdr elt) (format "%s%c" key (car elt)) char key-list)))) key-list)) (defun quail-find-key (char) "Return a list of key strings to type for inputting CHAR." (let ((decode-map (or (quail-decode-map) (setcar (nthcdr 10 quail-current-package) (quail-gen-decode-map)))) (key-list nil)) (if (consp decode-map) (let ((str (string char))) (mapc #'(lambda (elt) (if (string= str (car elt)) (setq key-list (cons (cdr elt) key-list)))) (cdr decode-map))) (let ((key-head (aref decode-map char))) (if (stringp key-head) (setq key-list (quail-find-key1 (quail-lookup-key key-head nil t) key-head char nil)) (mapc #'(lambda (elt) (setq key-list (quail-find-key1 (quail-lookup-key elt nil t) elt char key-list))) key-head)))) key-list)) (defun quail-show-key () "Show a list of key strings to type for inputting a character at point." (interactive) (let* ((char (following-char)) (key-list (quail-find-key char))) (if key-list (message "To input `%c', type \"%s\"" char (mapconcat 'identity key-list "\", \"")) (message "%c can't be input by the current input method" char)))) [-- Attachment #2: Type: text/plain, Size: 141 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-08 2:56 ` Kenichi Handa @ 2004-05-08 16:38 ` Werner LEMBERG 2004-05-10 4:40 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Werner LEMBERG @ 2004-05-08 16:38 UTC (permalink / raw) Cc: emacs-devel, miles > So, I decided to generate a halfly cooked decode-map on demand, > which results in, I hope, reasonable speed for M-x quail-show-key > both at the first attempt and the succeeding attempts. Very nice, thanks! For me there is no delay visible now. I suggest that you incorporate this into Emacs -- it is a tiny and very useful, but a new feature, so I don't know whether it should be added right now or after the next release. What key assignment do you suggest? Werner PS: Some possible improvements: . Using quail-show-key on a key X which is assigned to `self-insert-command' should probably say so instead of X can't be input by current input method . quail-show-key should say `no input method is activated now' if no input method is active instead of referring to the one selected previously. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-08 16:38 ` Werner LEMBERG @ 2004-05-10 4:40 ` Kenichi Handa 2004-05-12 2:42 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-10 4:40 UTC (permalink / raw) Cc: miles, emacs-devel In article <20040508.183839.74756820.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes: >> So, I decided to generate a halfly cooked decode-map on demand, >> which results in, I hope, reasonable speed for M-x quail-show-key >> both at the first attempt and the succeeding attempts. > Very nice, thanks! For me there is no delay visible now. Thank you for testing it. > I suggest that you incorporate this into Emacs -- it is a tiny and > very useful, I agree. > but a new feature, so I don't know whether it should be > added right now or after the next release. Me neither. Richard, please decide whether or not I should install this new feature (i.e. showing what key to type to insert a specific character) now. > What key assignment do you suggest? As Miles suggsested, I think it is good that C-u C-x = shows this info. If it's too heavy just to see this info, one can assign his preferred key to quail-show-key. > PS: Some possible improvements: > . Using quail-show-key on a key X which is assigned to > `self-insert-command' should probably say so instead of > X can't be input by current input method > . quail-show-key should say `no input method is activated now' if > no input method is active instead of referring to the one > selected previously. Thank you, I'll included these fixes when I install the code. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-10 4:40 ` Kenichi Handa @ 2004-05-12 2:42 ` Kenichi Handa 2004-05-12 8:32 ` Werner LEMBERG 0 siblings, 1 reply; 56+ messages in thread From: Kenichi Handa @ 2004-05-12 2:42 UTC (permalink / raw) Cc: emacs-devel, rms, miles In article <200405100440.NAA03200@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes: >> but a new feature, so I don't know whether it should be >> added right now or after the next release. > Me neither. Richard, please decide whether or not I should > install this new feature (i.e. showing what key to type to > insert a specific character) now. Richard Stallman <rms@gnu.org> writes: > Please do install it. Ok, I've just installed it with this NEWS entry. ** New command quail-show-key shows what key to type to input a character at point. --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-12 2:42 ` Kenichi Handa @ 2004-05-12 8:32 ` Werner LEMBERG 2004-05-12 11:10 ` Kenichi Handa 0 siblings, 1 reply; 56+ messages in thread From: Werner LEMBERG @ 2004-05-12 8:32 UTC (permalink / raw) Cc: emacs-devel, rms, miles > Ok, I've just installed it with this NEWS entry. > > ** New command quail-show-key shows what key to type to input a > character at point. Hmm, what about this: ** New command quail-show-key shows what key or string to type in the current input method to input a character at point. It should also be mentioned in the explanation of quail input methods. Otherwise, its usefulness is lost in the wealth of other information. Werner ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-05-12 8:32 ` Werner LEMBERG @ 2004-05-12 11:10 ` Kenichi Handa 0 siblings, 0 replies; 56+ messages in thread From: Kenichi Handa @ 2004-05-12 11:10 UTC (permalink / raw) Cc: emacs-devel, rms, miles In article <20040512.103216.233101356.wl@gnu.org>, Werner LEMBERG <wl@gnu.org> writes: >> Ok, I've just installed it with this NEWS entry. >> >> ** New command quail-show-key shows what key to type to input a >> character at point. > Hmm, what about this: > ** New command quail-show-key shows what key or string to type in > the current input method to input a character at point. As "typing a string" sounds a little bit strange to me, I changed the entry as below: ** New command quail-show-key shows what key (or key sequence) to type in the current input method to input a character at point. > It should also be mentioned in the explanation of quail input methods. > Otherwise, its usefulness is lost in the wealth of other information. Do you mean to mention it in info? Then, could you give me a patch? --- Ken'ichi HANDA handa@m17n.org ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: reverting CJK input methods 2004-04-30 5:06 ` reverting CJK input methods Kenichi Handa 2004-04-30 16:50 ` Werner LEMBERG @ 2004-05-01 17:21 ` Werner LEMBERG 1 sibling, 0 replies; 56+ messages in thread From: Werner LEMBERG @ 2004-05-01 17:21 UTC (permalink / raw) Cc: emacs-devel, miles [-- Attachment #1: Type: Text/Plain, Size: 237 bytes --] > Oops, please try the attached new one. Is it possible to get *all* possible input sequences? For example, 说 (shuo1) can also be input as `yue4' in chinese-tonepy, and this is what your code currently returns. Werner [-- Attachment #2: Type: text/plain, Size: 141 bytes --] _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2004-05-14 9:21 UTC | newest] Thread overview: 56+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-04-29 13:03 reverting CJK input methods Werner LEMBERG 2004-04-30 1:42 ` Kenichi Handa 2004-04-30 2:03 ` Miles Bader 2004-04-30 2:59 ` Miles Bader 2004-04-30 11:27 ` Juri Linkov 2004-04-30 13:26 ` Kenichi Handa 2004-05-01 8:22 ` Juri Linkov 2004-05-02 1:57 ` Kenichi Handa 2004-05-06 5:05 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Kenichi Handa 2004-05-06 11:48 ` Richard Stallman 2004-05-06 13:10 ` Kenichi Handa 2004-05-06 14:27 ` Stefan Monnier 2004-05-06 15:49 ` Kevin Rodgers 2004-05-06 16:50 ` Stefan Monnier 2004-05-06 20:57 ` Kevin Rodgers 2004-05-07 1:53 ` Kenichi Handa 2004-05-08 1:20 ` Richard Stallman 2004-05-10 12:13 ` Kenichi Handa 2004-05-10 14:28 ` Stefan Monnier 2004-05-11 7:04 ` Richard Stallman 2004-05-11 7:49 ` David Kastrup 2004-05-12 7:51 ` Richard Stallman 2004-05-11 13:39 ` erase-buffer (was: with-output-to-temp-buffer) Stefan Monnier 2004-05-11 14:44 ` erase-buffer Juri Linkov 2004-05-11 16:17 ` erase-buffer Juri Linkov 2004-05-11 15:32 ` erase-buffer (was: with-output-to-temp-buffer) David Kastrup 2004-05-11 16:22 ` Kevin Rodgers 2004-05-11 19:30 ` Stefan Monnier 2004-05-12 21:10 ` Kevin Rodgers 2004-05-11 19:37 ` Juanma Barranquero 2004-05-11 18:14 ` Juanma Barranquero 2004-05-11 23:06 ` Kenichi Handa 2004-05-11 23:26 ` Miles Bader 2004-05-12 19:42 ` Richard Stallman 2004-05-12 22:34 ` Miles Bader 2004-05-14 9:21 ` Richard Stallman 2004-05-11 23:34 ` Stefan Monnier 2004-05-11 23:47 ` Kenichi Handa 2004-05-12 19:40 ` Richard Stallman 2004-05-11 1:45 ` with-output-to-temp-buffer [Re: reverting CJK input methods] Luc Teirlinck 2004-05-11 2:34 ` Kenichi Handa 2004-05-11 7:01 ` David Kastrup 2004-05-11 6:55 ` Kim F. Storm 2004-05-11 8:00 ` Kenichi Handa 2004-05-12 7:51 ` Richard Stallman 2004-04-30 5:06 ` reverting CJK input methods Kenichi Handa 2004-04-30 16:50 ` Werner LEMBERG 2004-05-01 9:07 ` Miles Bader 2004-05-01 17:18 ` Werner LEMBERG 2004-05-08 2:56 ` Kenichi Handa 2004-05-08 16:38 ` Werner LEMBERG 2004-05-10 4:40 ` Kenichi Handa 2004-05-12 2:42 ` Kenichi Handa 2004-05-12 8:32 ` Werner LEMBERG 2004-05-12 11:10 ` Kenichi Handa 2004-05-01 17:21 ` Werner LEMBERG
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).