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: Changed outside --> set, in Customize UI Date: Tue, 8 Feb 2005 12:37:29 -0800 Message-ID: References: <871xbsky5a.fsf-monnier+emacs@gnu.org> 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 1107895929 9792 80.91.229.2 (8 Feb 2005 20:52:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 8 Feb 2005 20:52:09 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 08 21:52:09 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CycL4-00022U-8I for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 21:52:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CycZS-0002sr-NE for ged-emacs-devel@m.gmane.org; Tue, 08 Feb 2005 16:06:54 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CycUg-000156-Bz for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CycUO-0000yd-Eo for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:44 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CycUM-0000rS-Ul for emacs-devel@gnu.org; Tue, 08 Feb 2005 16:01:38 -0500 Original-Received: from [148.87.122.30] (helo=rgminet01.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1Cyc7A-00040o-Oh for emacs-devel@gnu.org; Tue, 08 Feb 2005 15:37:41 -0500 Original-Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18KbbiM028635; Tue, 8 Feb 2005 15:37:37 -0500 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j18Kba31028621; Tue, 8 Feb 2005 15:37:36 -0500 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 j18KbZlf027911; Tue, 8 Feb 2005 13:37:35 -0700 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-66-208.vpn.oracle.com [141.144.66.208]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j18KbVQo027829 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 8 Feb 2005 13:37:34 -0700 Original-To: "Stefan Monnier" , "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <871xbsky5a.fsf-monnier+emacs@gnu.org> 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:33093 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33093 > If, today, most "changes outside customize" occur > systematically, that is > because most represent _bugs_: libraries that are diddling > user options when they shouldn't. No, it's because the same code is executed at most startup. After all, your .emacs doesn't change much from one invocation to the next and you tend to use the same major modes from one invocation to the next, so the same code is triggered. How much of this is caused directly by stuff in your .emacs and how much is caused by stuff your .emacs loads? How many of the latter changes are really _appropriate_ for libraries to make? That is, how much changing of user options by libraries that you load each day is appropriate? I don't know, but I suspect that most current changes of user options by libraries represent bugs. And, given the discussion in this thread, I'm hopeful that number will be reduced. > In the future, I expect that most such outside changes will be made by > users using other ways than Customize (extensions of Customize, > essentially) to change values. Users will set options in various ways and > they will see that "Set" status correctly reflected in Customize. Then you're not talking about removing the distinction but about eradicating the cases where "changed outside customize" occurs. I'm not interested in eradicating all the cases where "changed outside" occurs. From the beginning, I've been interested in eradicating _inappropriate_ changes of user options - as well as removing the outside/inside distinction (in the UI). A user using a command to change a face color is setting that user option - the change is both outside customize and appropriate. Currently, I suspect that most "outside changes" are inappropriate. I expect the number of occurrences of appropriate (that is, user-intended) outside changes to grow, both relative to the number of inappropriate such changes and absolutely (due to Customize extensions that help users change options "outside" Customize). Setting user options, in whatever way, should be done by users, but users should be able to use any means to do that. > And even if it does show up, taking a look at the customize > buffer when you see the problem will tell you "changed > outside customize" warning you of the problem. > What is the problem you are trying to solve, really? I.e. in > what way is the message "changed outside customize" a problem? > Come on, you can't have it both ways. Either "changed outside > customize" is valuable because it is effective in warning > users about disastrous problems, or it is harmless (might not > help but doesn't hurt), has no effect, and > means nothing. Which do you want to claim? Notice I asked "in what way is the message `changed outside customize' a problem", which is not the same as "in what way is a situation denoted by `changed outside customize' a problem". Don't shoot the messenger. I'm not. We're both talking about the message, not the messenger. The claim was made that the message is invaluable in finding bugs and in warning users. And I interpreted your last question ("what's the harm?", essentially) as suggesting that the message is really not important, that it is harmless. Is the message an important warning, or is it something harmless that can be ignored? > IOW, turn your question around: In what way is using Set instead of > Changed Outside Customize a problem? Because it hides the fact that Custom has detected a potential problem. The net is too wide. We don't want to scream "Wolf!" for all outside changes. We only want to warn about identified problems (until we can fix them). Do you want to solve the problem or do you want to put your head in the sand by removing the message warning you of the problem? The warning is not going to solve the problem, which is a set of bugs that need to be fixed. I already seconded Luc's suggestion of creating a _real_ warning until the bugs are fixed, but I also mentioned that it makes sense to target such a message to those cases that we know are problematic, rather than painting all outside changes with the same broad brush. We want people to pay attention when we cry "Wolf!".