From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: with-output-to-temp-buffer [Re: reverting CJK input methods] Date: Wed, 12 May 2004 03:51:16 -0400 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> Reply-To: rms@gnu.org NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1084348400 19868 80.91.224.253 (12 May 2004 07:53:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 May 2004 07:53:20 +0000 (UTC) Cc: juri@jurta.org, handa@m17n.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 12 09:53:12 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 1BNoYC-0006dJ-00 for ; Wed, 12 May 2004 09:53:12 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNoYB-0000d9-00 for ; Wed, 12 May 2004 09:53:12 +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 1BNoX6-0000rw-HB for emacs-devel@quimby.gnus.org; Wed, 12 May 2004 03:52:04 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNoWs-0000rK-IJ for emacs-devel@gnu.org; Wed, 12 May 2004 03:51:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNoWL-0000hf-EA for emacs-devel@gnu.org; Wed, 12 May 2004 03:51:48 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNoWL-0000hZ-6k for emacs-devel@gnu.org; Wed, 12 May 2004 03:51:17 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1BNoWK-0002xd-MA; Wed, 12 May 2004 03:51:16 -0400 Original-To: David Kastrup In-reply-to: (message from David Kastrup on 11 May 2004 09:49:03 +0200) 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:23219 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23219 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.