From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: with-output-to-temp-buffer [Re: reverting CJK input methods] Date: Tue, 11 May 2004 17:00:09 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200405110800.RAA07081@etlken.m17n.org> 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 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1084308008 15096 80.91.224.253 (11 May 2004 20:40:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 May 2004 20:40:08 +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 22:39:52 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 1BNe2Z-0007uA-00 for ; Tue, 11 May 2004 22:39: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 1BNe2Y-0004gT-00 for ; Tue, 11 May 2004 22:39: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 1BNe0r-0004q9-R6 for emacs-devel@quimby.gnus.org; Tue, 11 May 2004 16:38:05 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNe0K-0004cP-U1 for emacs-devel@gnu.org; Tue, 11 May 2004 16:37:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNdw7-0003VU-BE for emacs-devel@gnu.org; Tue, 11 May 2004 16:33:42 -0400 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1BNdqo-0002oY-Bw; Tue, 11 May 2004 16:27:42 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by mx20.gnu.org with esmtp (Exim 4.34) id 1BNSJ2-00046T-SW; Tue, 11 May 2004 04:08:09 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2]) by tsukuba.m17n.org (8.11.6p2/8.11.6) with ESMTP id i4B80C822548; Tue, 11 May 2004 17:00:12 +0900 (JST) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) by fs.m17n.org (8.11.6p2/8.11.6) with ESMTP id i4B80C928266; Tue, 11 May 2004 17:00:12 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id RAA07081; Tue, 11 May 2004 17:00:09 +0900 (JST) Original-To: dak@gnu.org In-reply-to: (message from David Kastrup on 11 May 2004 09:01:50 +0200) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) 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:23175 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23175 In article , David Kastrup 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