From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Eliminating "changed in Emacs outside of Customize" Date: Thu, 3 Feb 2005 12:53:02 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107464147 30426 80.91.229.2 (3 Feb 2005 20:55:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Feb 2005 20:55:47 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 03 21:55:46 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cwnz8-0001LK-7J for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 21:54:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwoCS-0006Es-Uv for ged-emacs-devel@m.gmane.org; Thu, 03 Feb 2005 16:07:41 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwoC5-0006Dp-Sm for emacs-devel@gnu.org; Thu, 03 Feb 2005 16:07:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwoC3-0006CH-Hb for emacs-devel@gnu.org; Thu, 03 Feb 2005 16:07:15 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwoC3-0006C7-DG for emacs-devel@gnu.org; Thu, 03 Feb 2005 16:07:15 -0500 Original-Received: from [141.146.126.230] (helo=agminet03.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CwnyU-00052R-9w; Thu, 03 Feb 2005 15:53:14 -0500 Original-Received: from agminet03.oracle.com (localhost [127.0.0.1]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j13KrC4a017324; Thu, 3 Feb 2005 12:53:12 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet03.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j13Kr8mt017280; Thu, 3 Feb 2005 12:53:09 -0800 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j13Kr8jH015395; Thu, 3 Feb 2005 13:53:08 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j13Kr2Ub015367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 3 Feb 2005 13:53:03 -0700 Original-To: , "Per Abrahamsen" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 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:32846 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32846 The "Changed outside customize" has been a great help for me to catch those hooks, setq's and poorly written major modes, and I think Emacs has improved because of it, by fixing the modes and rethinking the hooks. As I mentioned previously, these can still be caught if "changed-outside" is conflated with "set", and in fact it is more likely that they will be caught, because users will find them and report them: WRT the value of such a distinction in helping us identify "hooks, setq's and poorly written major modes" that don't play by the rules: I've found (by experiment) that removing the distinction changed-outside/set actually makes such faulty library codings _more visible_, not less. If every change is considered to "set" the option, then querying with customize-customize picks up all such faulty changes (along with any user changes made inside customize). Yes, the same info is available today via customize-rogue. My point is that erasing the distinction (in the UI, for users) doesn't hamper our ability to find such rogue library coding. And in fact it can make it more visible to more users. That visibility could help us by inviting more bug reports on faulty coding in libraries that we might not check otherwise. We could provide an option to continue making the distinction, for the sake of testing. Yes, if there is any value in maintaining such a distinction _internally_, that could still be done - for testing or in general. The question is about the _UI_ only. Does it help users or get in their way to have such a distinction in the UI? I argue that it is clearer for users without such a distinction.