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: Mon, 10 May 2004 21:13:00 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200405101213.VAA04125@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> 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 1084195170 23223 80.91.224.253 (10 May 2004 13:19:30 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 10 May 2004 13:19:30 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon May 10 15:19:10 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 1BNAgX-0008MY-00 for ; Mon, 10 May 2004 15:19:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNAgX-0000Xu-00 for ; Mon, 10 May 2004 15:19:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.33) id 1BNAYJ-0003mB-5g for emacs-devel@quimby.gnus.org; Mon, 10 May 2004 09:10:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.33) id 1BNAXq-0003kq-Q2 for emacs-devel@gnu.org; Mon, 10 May 2004 09:10:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.33) id 1BN9ea-0003yx-ML for emacs-devel@gnu.org; Mon, 10 May 2004 08:13:39 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.33) id 1BN9eZ-0003y6-G3; Mon, 10 May 2004 08:13:04 -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 i4ACD0810026; Mon, 10 May 2004 21:13:00 +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 i4ACD0907884; Mon, 10 May 2004 21:13:00 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id VAA04125; Mon, 10 May 2004 21:13:00 +0900 (JST) Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Fri, 07 May 2004 21:20:19 -0400) 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:23034 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23034 In article , Richard Stallman 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 * 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