reverting CJK input methods

reverting CJK input methods

[Werner LEMBERG]

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

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: reverting CJK input methods

[Miles Bader]

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

Re: reverting CJK input methods

[Miles Bader]

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

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: reverting CJK input methods

[Juri Linkov]

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/

Re: reverting CJK input methods

[Kenichi Handa]

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)

Re: reverting CJK input methods

[Werner LEMBERG]

> 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

Re: reverting CJK input methods

[Juri Linkov]

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/

Re: reverting CJK input methods

[Miles Bader]

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]

Re: reverting CJK input methods

[Werner LEMBERG]

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

Re: reverting CJK input methods

[Werner LEMBERG]

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

Re: reverting CJK input methods

[Kenichi Handa]

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

with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Richard Stallman]

    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.

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Stefan Monnier]

> 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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kevin Rodgers]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Stefan Monnier]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kevin Rodgers]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Richard Stallman]

    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.

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: reverting CJK input methods

[Werner LEMBERG]

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

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Stefan Monnier]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Luc Teirlinck]

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.

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kim F. Storm]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[David Kastrup]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Richard Stallman]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[David Kastrup]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Kenichi Handa]

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

erase-buffer (was: with-output-to-temp-buffer)

[Stefan Monnier]

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

Re: erase-buffer

[Juri Linkov]

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/

Re: erase-buffer (was: with-output-to-temp-buffer)

[David Kastrup]

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

Re: erase-buffer

[Juri Linkov]

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/

Re: erase-buffer (was: with-output-to-temp-buffer)

[Kevin Rodgers]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Juanma Barranquero]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Stefan Monnier]

> 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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Juanma Barranquero]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Kenichi Handa]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Miles Bader]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Stefan Monnier]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Kenichi Handa]

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

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Richard Stallman]

    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.

Re: with-output-to-temp-buffer [Re: reverting CJK input methods]

[Richard Stallman]

    If you want to protect your buffer against erasure, set the whole
    buffer to read-only.

Custom buffers certainly can't do that.

Re: reverting CJK input methods

[Werner LEMBERG]

> 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

Re: reverting CJK input methods

[Kenichi Handa]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Richard Stallman]

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.

Re: erase-buffer (was: with-output-to-temp-buffer)

[Richard Stallman]

    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.

Re: erase-buffer (was: with-output-to-temp-buffer)

[Kevin Rodgers]

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

Re: erase-buffer (was: with-output-to-temp-buffer)

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

Re: erase-buffer (was: with-output-to-temp-buffer)

[Richard Stallman]

    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?