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: Wed, 2 Feb 2005 10:33:41 -0800 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107369899 10993 80.91.229.2 (2 Feb 2005 18:44:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2005 18:44:59 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 02 19:44:59 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CwPUg-0008EI-Dv for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2005 19:44:50 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwPe2-000753-Gj for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2005 13:54:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwPdQ-00071y-Qn for emacs-devel@gnu.org; Wed, 02 Feb 2005 13:53:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwPdG-0006w0-Du for emacs-devel@gnu.org; Wed, 02 Feb 2005 13:53:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwPdG-0006tH-8s for emacs-devel@gnu.org; Wed, 02 Feb 2005 13:53:42 -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 1CwPK7-0004uI-8K; Wed, 02 Feb 2005 13:33:55 -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 j12IXrY7029833; Wed, 2 Feb 2005 10:33:53 -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 j12IXpvl029802; Wed, 2 Feb 2005 10:33:52 -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 j12IXm07022626; Wed, 2 Feb 2005 11:33:48 -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 j12IXfmd022583 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Feb 2005 11:33:42 -0700 Original-To: "Per Abrahamsen" , "Stefan Monnier" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal 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:32765 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32765 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. I can see there is a lot of followup mails. I don't have time for either discussion or design, so I'll skip them unread. If someone have specific questions, mail them to me directly. I still have the specific question of _what the problem is_ with the scenario that you and Stefan (and I) described: a setq (in .emacs or a library) executed after custom-set-variables. Yes, a setq changes the current value so that it is no longer the `saved-value' - but so what? And, more importantly, what that pb has to do with a proposal to eliminate the distinction between "changed outside" and "set" in favor of only "set". The behavior in the scenario seems to me to be the _same_, regardless of whether such a proposal were adopted. IOW, the scenario doesn't seem to show the reason to maintain the distinction. I know you're busy, but I think that only you can help with this specific question. Help us understand what the pb is. Here's what I wrote before on this (which you perhaps missed): Was this unclear: If you .emacs, or some third party code you... What is not at all clear (to me) is what this has to do with the supposed need to distinguish, for the user, a value that is changed using a customize buffer from a value that is changed otherwise. The original question was that: "What would be wrong with treating, in the Customize UI, outside changes the same as inside changes?" IOW, nothing in the above description (Stefan's or Per's) makes any mention of replacing "changed outside" by "set" in the Customize UI. The above description holds perfectly in today's vanilla Emacs, does it not? ... Beyond that, what does this have to do with the question: "What would be wrong with treating outside changes the same as inside changes - in the Customize UI?" 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. So, the main thing that it would be a great help to clear up is 1) just what is the pb with the scenario that you outlined, and 2) what does that scenario (and pb) have to do with possibly erasing the distinction between changed-outside and set. Thanks, Drew