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:49:03 +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> <87ekpsuzqa.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1084261949 23751 80.91.224.253 (11 May 2004 07:52:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 May 2004 07:52:29 +0000 (UTC) Cc: juri@jurta.org, handa@m17n.org, Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 11 09:52:21 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 1BNS3p-0000sP-00 for ; Tue, 11 May 2004 09:52:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNS3p-0006Mn-00 for ; Tue, 11 May 2004 09:52:21 +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 1BNS1j-0007kB-Ha for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 03:50:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNS1J-0007jI-N6 for emacs-devel@gnu.org; Tue, 11 May 2004 03:49:45 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNS0l-0007aH-Vx for emacs-devel@gnu.org; Tue, 11 May 2004 03:49:44 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNS0l-0007aC-R1 for emacs-devel@gnu.org; Tue, 11 May 2004 03:49:11 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1BNS0f-0001v1-4M; Tue, 11 May 2004 03:49:05 -0400 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:23115 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23115 Richard Stallman 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