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 14:11:22 -0800 Message-ID: References: <00ac01c5096a$cfaf6950$0200a8c0@sedrcw11488> 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 1107382660 1156 80.91.229.2 (2 Feb 2005 22:17:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2005 22:17:40 +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 23:17:40 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CwSni-0008M6-7B for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2005 23:16:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwT0u-0005O4-E8 for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2005 17:30:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwSzb-0004nm-BL for emacs-devel@gnu.org; Wed, 02 Feb 2005 17:28:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwSzW-0004l6-0F for emacs-devel@gnu.org; Wed, 02 Feb 2005 17:28:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwSzV-0004l3-Tm for emacs-devel@gnu.org; Wed, 02 Feb 2005 17:28:53 -0500 Original-Received: from [141.146.126.229] (helo=agminet02.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CwSir-0006C4-Ll; Wed, 02 Feb 2005 17:11:42 -0500 Original-Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j12MBdwJ030588; Wed, 2 Feb 2005 14:11:39 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j12MBZKf030488; Wed, 2 Feb 2005 14:11:36 -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 j12MBTnB032523; Wed, 2 Feb 2005 15:11:29 -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 j12MBNu2032482 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 2 Feb 2005 15:11:23 -0700 Original-To: "Lennart Borgman" , "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: <00ac01c5096a$cfaf6950$0200a8c0@sedrcw11488> 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:32775 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:32775 > 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? The novice user changes a value in customize, saves and restarts Emacs. Then he find that the value is still the same. His conclusion is that there is something wrong with Emacs. He does not dare to use it any more. Yes (here we go 'round again) - that is exactly the behavior that we have _today_, in spite of our blessed distinction between "changed outside customize" and "set within customize". What is the specific problem that Per and Stefan think would result from treating "changed outside" as "set"? IOW, what does this "pb" have to do with a proposal to subsume "changed outside" under "set"? We were told that this pb would result in users making bug reports _if_ we treated "changed outside" as "set", but there has been no explanation of the connection between this pb and that proposed enhancement. The pb as described exists today, yet we don't seem swamped with such bug reports. And even if we were, that pb has nothing to do with the question at hand - at least nothing that has been pointed out yet. So, I don't get it - what's the real pb here in connection with "changed outside" vs "set"? > The original question was that: "What would be wrong > with treating, in the Customize UI, outside changes the same as > inside changes?" I think the distinction is good. Why? Will someone please tell me _why_ it is good? That was the original question. To which question we got the scenario we're all familiar with by now. But I don't see how that scenario shows why this distinction is good. The "pb" pointed to by that scenario is independent of whether we keep this distinction or get rid of it (for the UI). Or, if it is not independent, please show the connection. It was however very confusing the first time I saw it. When I now see the distinction between user variables (should only be changed by the user) and others it is much more clear. Should not this distinction should be pointed out very clearly in Info under Easy Customization? Which distinction? The distinction between "changed outside" and "set" for user options or the distinction between user variables and non-user variables? Why bring up the latter in the context of this discussion? - Drew