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: Customize buttons that change user's custom fileshouldaskforconfirmation Date: Fri, 18 Feb 2005 08:12:46 -0600 (CST) Message-ID: <200502181412.j1IECkj14736@raven.dms.auburn.edu> References: <00e301c509c1$9c761690$0200a8c0@sedrcw11488> <200502152320.j1FNKd310641@raven.dms.auburn.edu> <200502172257.j1HMvJN10856@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1108736605 24815 80.91.229.2 (18 Feb 2005 14:23:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Feb 2005 14:23:25 +0000 (UTC) Cc: miles@gnu.org, rms@gnu.org, lennart.borgman.073@student.lu.se, emacs-devel@gnu.org, monnier@iro.umontreal.ca, snogglethorpe@gmail.com, drew.adams@oracle.com, abraham@dina.kvl.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 18 15:23:24 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D2925-00042l-V5 for ged-emacs-devel@m.gmane.org; Fri, 18 Feb 2005 15:23:02 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D29IR-0000Ox-Dq for ged-emacs-devel@m.gmane.org; Fri, 18 Feb 2005 09:39:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D29Fv-0006d5-6v for emacs-devel@gnu.org; Fri, 18 Feb 2005 09:37:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D29Fs-0006aP-4z for emacs-devel@gnu.org; Fri, 18 Feb 2005 09:37:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D29Fr-0006X7-8c for emacs-devel@gnu.org; Fri, 18 Feb 2005 09:37:15 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D28uL-0004SY-Uo; Fri, 18 Feb 2005 09:15:02 -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 j1IEEf9N028218; Fri, 18 Feb 2005 08:14:42 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j1IECkj14736; Fri, 18 Feb 2005 08:12:46 -0600 (CST) X-Authentication-Warning: raven.dms.auburn.edu: teirllm set sender to teirllm@dms.auburn.edu using -f Original-To: storm@cua.dk In-reply-to: (storm@cua.dk) 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:33608 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33608 Kim Storm wrote: IMHO, this is _expert_ behaviour. I think that most novice users will very rarely mix and match setting some options and saving others. Rarely, but sometimes. Why confuse them badly if they do? Moreover, it is not just setting and saving. It is also about looking at possibilities and saving. Especially with the more complex "Value Menu" buttons. If he is satisfied with the current settings, he will save them ALL. But the problem is exactly that he may _not_ be satisfied with all the current "settings" (widget values). He may just have wanted to set them, or even more likely, just has been looking at them. If accidentally, he saves some option which he forgot he had only set and really didn't want to set, he can EASILY revert the change, either in the same emacs run or next time he runs emacs. Why force users to go to that trouble if it can easily be avoided? Moreover, if you save options that you do not want, you do not even know which one you saved. The user will have to scan his custom-set-variables or custom-set-faces forms. We are supposedly talking about a novice user. Why don't we simply introduce a "customize-expert" option that is off by default, but can be turned on when the user gains more experience. I believe that we should introduce a "customize-expert" option, off by default, and only enable the all whole buffer buttons if it is on. Personally, I would not turn it on. I do not come even remotely close to being enough of a Custom expert to be able to handle the complexity of whole button buffers. I always am careful to set custom-file to a junk file when I play with them. (I never use them "for real". Much too dangerous.) When off, it can limit the features of the customize interface to those features most novice users will be familiar to from other interfaces. Custom _is_ not exactly like other interfaces and _can_ not be. Other interfaces are not trying to handle an underlying customization system that is anywhere as complex and extensive as Emacs'. The average Custom buffer is a lot longer and contains a lot more options than the average customization "page" (or whatever they call it). The choices you have for an individual option can be a lot more complex. Complex types like `choice' force a concept of a `widget' value. Very importantly, other interfaces do not have to deal with the tremendous complexity of options that can be changed by _both_ the user and programs. What makes the whole button buttons dangerous are, among others, the concept of a separate widget value, the difference between Set and Save, bugs in Custom, the length of Custom buffers, options changed by programs behind the user's back, and user absent-mindedness. We are never going to be able to do something about the latter, even if we do something about everything else, which would be highly non-trivial and would involve removing present features, which people actually use. The concept of saving options one by one is not a difficult concept, whether the user is used to it or not. One should not equate "novice" with "stupid". Sincerely, Luc.