From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Visual cleanup for customize buffers Date: Sun, 5 Feb 2006 22:30:11 -0600 (CST) Message-ID: <200602060430.k164UBb19480@raven.dms.auburn.edu> References: <200601142305.k0EN5Nl22098@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1139200644 4561 80.91.229.2 (6 Feb 2006 04:37:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2006 04:37:24 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 05:37:20 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F5y7n-0001rZ-Su for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2006 05:37:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F5yB5-0003EU-DA for ged-emacs-devel@m.gmane.org; Sun, 05 Feb 2006 23:40:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F5yA5-0003EL-8W for emacs-devel@gnu.org; Sun, 05 Feb 2006 23:39:37 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F5y9r-00036l-Lu for emacs-devel@gnu.org; Sun, 05 Feb 2006 23:39:37 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F5y9r-00036i-KR for emacs-devel@gnu.org; Sun, 05 Feb 2006 23:39:23 -0500 Original-Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1F5y8e-00076K-Iy; Sun, 05 Feb 2006 23:38:08 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by mx20.gnu.org with esmtp (Exim 4.52) id 1F5y52-0000ji-LA; Sun, 05 Feb 2006 23:34:24 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id k164XvEN015949; Sun, 5 Feb 2006 22:33:57 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k164UBb19480; Sun, 5 Feb 2006 22:30:11 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: storm@cua.dk In-reply-to: (storm@cua.dk) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Sun, 05 Feb 2006 22:33:57 -0600 (CST) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:50077 Archived-At: Kim Storm wrote: I have worked a little more on this to address the bugs that Luc reported, Your patch addresses only _some manifestations_ of the bugs. You did not even fix all examples that I reported. For instance, a manifestation of the bug that is still present is that the "Value Menu" for initial-scratch-message says: ";; This buffer is for notes you don't want to save, and for Lisp evaluation." whereas it should be saying: "Message". I already reported this while discussing your earlier patch. Your "Value Menu" for initial-scratch-message is _also_ part of the _value_ and hence can be edited and is _meant_ to be edited. If you do C-k at the beginning of it, the value menu is _gone_. It is a complete mess. YMMV, but I think the new patch is quite harmless. This has nothing to do with varying mileage. You said this once before about your earlier patch and you were very wrong. Now you say it a second time and you are very wrong again. I would *very much* appreciate if you could wait till after the release before submitting any more "quite harmless" patches on this. Right now, one should concentrate on fixing existing bugs. I know that there are problems with the "feature freeze", but this is no reason to make a complete mockery out of it. There are still many known bugs related to Custom that need to be fixed. Each time somebody tries to implement a new feature in Custom, like you are trying to implement, or starts yet another discussion about Custom that could wait till after the release, people have to spend time finding the bugs in these new features and reporting them and participating in long discussions. As a result, numerous bugs related to Custom that could otherwise have fixed during all that time will now find their way into the release. Sincerely, Luc.