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 16:59:06 -0600 (CST) Message-ID: <200502182259.j1IMx6g23511@raven.dms.auburn.edu> References: <00e301c509c1$9c761690$0200a8c0@sedrcw11488> <200502152320.j1FNKd310641@raven.dms.auburn.edu> <200502172257.j1HMvJN10856@raven.dms.auburn.edu> <200502181412.j1IECkj14736@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1108768201 29795 80.91.229.2 (18 Feb 2005 23:10:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 Feb 2005 23:10:01 +0000 (UTC) Cc: lennart.borgman.073@student.lu.se, rms@gnu.org, drew.adams@oracle.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 19 00:10:00 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D2HDP-0007Oy-Im for ged-emacs-devel@m.gmane.org; Sat, 19 Feb 2005 00:07:15 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2HRy-00087x-KQ for ged-emacs-devel@m.gmane.org; Fri, 18 Feb 2005 18:22:18 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D2HRX-0007zy-Ae for emacs-devel@gnu.org; Fri, 18 Feb 2005 18:21:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D2HRP-0007w8-0U for emacs-devel@gnu.org; Fri, 18 Feb 2005 18:21:43 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2HRO-0007t1-3k for emacs-devel@gnu.org; Fri, 18 Feb 2005 18:21:42 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D2H7e-0001uJ-E9; Fri, 18 Feb 2005 18:01:18 -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 j1IN129N002858; Fri, 18 Feb 2005 17:01:02 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id j1IMx6g23511; Fri, 18 Feb 2005 16:59:06 -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:33612 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33612 Kim Storm wrote: The confusion arises when you have the option to "set but not save" some options, and later on you do "save" -- that will save all options including those you only "set". No, you completely misunderstand. Getting rid of the Save-Set distinction would _in no way whatsoever_ make using whole buffer buttons safe. There are _tons_ of problems with them, some of which I described in my previous posting. > 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. I don't think this is _typical_ usage. Suppose the user is playing with some feature, e.g. ido-mode, which has many options. He tries to "Set" some parameters to see the effect. If he doesn't like the effect, he will "Reset" to set it back to what it was. You completely misunderstand again. I am talking about just _looking_ at items in a "Value Menu", not about setting anything. When you click on a choice of the Value Menu, the default value _for that choice_ appears in the widget and a separate docstring for that choice may appear, which you may want to read. You may _only_ have clicked on that choice for information purposes. If you are not careful and start looking at another option, without first resetting the Value Menu to your actual choice, and use the per buffer buttons, you may accidentally save the widget value, even though you never wanted to save or even set it. The problem is that Custom buffers can be large, so if you want to save a totally unrelated option, you may have forgotten about the docs you were reading, which are _out of view_. The whole buffer buttons make merely *looking* at the choices you have, or wanting to read their docs, a dangerous activity. If customize is so dangerous, it should really be off-limits for everybody... Customize is not too dangerous, the whole buffer buttons are too dangerous. They probably should indeed be off limits for everybody. I suggest getting rid of them. > 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". So why do you do that ? I do _not_ claim that the average user is too stupid to use whole buffer buttons. I claim that the whole buffer buttons needlessly force the user to be careful about the many options in the buffer he is not interested in. On the other hand, your main argument against per option customization appears to be that the average user is too stupid to grasp the mind-boggling concept of option by option customization if he is not used to it. Sincerely, Luc.