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 11:34:03 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200405110234.LAA06316@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> 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 1084243034 21981 80.91.224.253 (11 May 2004 02:37:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 11 May 2004 02:37:14 +0000 (UTC) Cc: juri@jurta.org, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 11 04:37:03 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 1BNN8h-0005qJ-00 for ; Tue, 11 May 2004 04:37:03 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BNN8h-0000Wq-00 for ; Tue, 11 May 2004 04:37:03 +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 1BNN7o-0002JK-8U for emacs-devel@quimby.gnus.org; Mon, 10 May 2004 22:36:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BNN71-0002HD-CT for emacs-devel@gnu.org; Mon, 10 May 2004 22:35:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BNN6T-0001mB-DO for emacs-devel@gnu.org; Mon, 10 May 2004 22:35:17 -0400 Original-Received: from [192.47.44.130] (helo=tsukuba.m17n.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BNN5w-0001WS-Rk; Mon, 10 May 2004 22:34:13 -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 i4B2Y3814600; Tue, 11 May 2004 11:34:03 +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 i4B2Y3922374; Tue, 11 May 2004 11:34:03 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id LAA06316; Tue, 11 May 2004 11:34:03 +0900 (JST) Original-To: teirllm@dms.auburn.edu In-reply-to: <200405110145.i4B1jNF22171@raven.dms.auburn.edu> (message from Luc Teirlinck on Mon, 10 May 2004 20:45:23 -0500 (CDT)) 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:23104 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:23104 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. > I do not understand why we should wait till after the next release to > make a decision on this issue. If we do not change `erase-buffer', > then I suspect that we will have to bind inhibit-read-only to t around > several calls to erase-buffer. When we would decide after the release to > change erase-buffer, then not only would we have done all that work > for nothing, but we even would have to do the additional work of > undoing all these changes. > Why can a _final_ decision not be made right now? We are talking about > the best way to deal with existing bugs, not about a new feature, so > the feature freeze is irrelevant. 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. --- Ken'ichi HANDA handa@m17n.org