From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: find-file-hook as illustration of Custom problems Date: Mon, 7 Feb 2005 19:50:22 -0600 (CST) Message-ID: <200502080150.j181oMf07339@raven.dms.auburn.edu> References: <200502040036.j140atb03430@raven.dms.auburn.edu> <200502060150.j161oqh15336@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1107829353 21899 80.91.229.2 (8 Feb 2005 02:22:33 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 02:22:33 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 03:22:33 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CyL1J-000604-0d for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 03:22:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyLFX-0003iE-Qg for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2005 21:37:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CyL65-0002bI-No for emacs-devel@gnu.org; Mon, 07 Feb 2005 21:27:28 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CyL5u-0002Wq-Q4 for emacs-devel@gnu.org; Mon, 07 Feb 2005 21:27:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CyL5u-0002R7-F9 for emacs-devel@gnu.org; Mon, 07 Feb 2005 21:27:14 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CyKXf-0002E3-62; Mon, 07 Feb 2005 20:51:51 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.12.10/8.12.10) with ESMTP id j181po9N019789; Mon, 7 Feb 2005 19:51:50 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j181oMf07339; Mon, 7 Feb 2005 19:50:22 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: rms@gnu.org In-reply-to: (message from Richard Stallman on Sun, 06 Feb 2005 16:02:03 -0500) 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 X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33068 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33068 Richard Stallman wrote: I don't think that minibuffer-prompt-properties is a problem. It is simply a customizable variable whose value is set up with a setq. Likewise for help-event-list. If there is a problem with these, it is only that they are built-in and handled by cus-start.el rather than a defcustom. We just need to give them the right standard value. Do you want to try to do that? If you mean removing the "Changed outside Custom" warning from those rogue-at-startup (with emacs -q) variables that are really harmless, then I could definitely do that way in time for Emacs 22 (old 21.4). The way in which I would do that could be a temporary solution until a more fundamental solution is implemented. I could mention that in a comment. I might need to keep the "Changed outside Custom" warning for the two hooks in the list. I will need to take a closer look at that. At a given moment we will have to implement the splitting of hooks and probably other list vars into two parts which we discussed. Until we do that bugs in Custom will remain, but they are not new bugs. These bugs are serious, but the probability of users encountering them is limited by the fact that the involved variables are not often used by beginning users and are inconvenient to set through Custom anyway. As we get more hooks like `before-save-hook', by which the user can enable two relatively popular features by a simple mouse click or RETURN, the probability of users actually being inconvenienced by those bugs will increase. So we can not wait forever to fix them but I believe we can (actually have to) wait until after the 22 release. Getting rid of the bugs I described will require fundamental changes in the Custom user interface. Until we look at these problems carefully and implement solutions, I would make as few changes to the current Custom interface as possible. I believe it would be bad to have an oddball 22 Custom interface that would be very different from both the 21 and the 23 interface. People are used to the old interface. They should not have to adapt to non-trivial changes for one single release (or *maybe* two releases, should 23 be released very soon after 22). We very definitely need to keep "Set outside Custom" until the bugs are fixed. Whether we still need it afterward depends on the particular interface we wound up with. Sincerely, Luc.