From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: with-output-to-temp-buffer [Re: reverting CJK input methods] Date: 11 May 2004 09:01:50 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040429.150303.42778779.wl@gnu.org> <200404300142.KAA01027@etlken.m17n.org> <87u0z1puxa.fsf@mail.jurta.org> <200404301326.WAA02744@etlken.m17n.org> <8765bga5tt.fsf@mail.jurta.org> <200405020157.KAA07108@etlken.m17n.org> <200405060505.OAA21188@etlken.m17n.org> <200405061310.WAA22378@etlken.m17n.org> <200405101213.VAA04125@etlken.m17n.org> <200405110145.i4B1jNF22171@raven.dms.auburn.edu> <200405110234.LAA06316@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084261741 23317 80.91.224.253 (11 May 2004 07:49:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 May 2004 07:49:01 +0000 (UTC) Cc: juri@jurta.org, teirllm@dms.auburn.edu, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 11 09:48:51 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNS0R-0000gb-00 for ; Tue, 11 May 2004 09:48:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNS0R-0006IZ-00 for ; Tue, 11 May 2004 09:48:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNRlA-0003gg-3Z for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 03:33:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNRdN-0002Jb-EX for emacs-devel@gnu.org; Tue, 11 May 2004 03:25:01 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNRch-000262-VR for emacs-devel@gnu.org; Tue, 11 May 2004 03:24:54 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNRH5-000753-8U for emacs-devel@gnu.org; Tue, 11 May 2004 03:01:59 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BNRGy-00087m-De; Tue, 11 May 2004 03:01:52 -0400 Original-To: Kenichi Handa In-Reply-To: <200405110234.LAA06316@etlken.m17n.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:23114 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23114 Kenichi Handa writes: > In article <200405110145.i4B1jNF22171@raven.dms.auburn.edu>, Luc > Teirlinck 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