From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Luc Teirlinck Newsgroups: gmane.emacs.devel Subject: Re: Visual cleanup for customize buffers Date: Fri, 13 Jan 2006 18:44:36 -0600 (CST) Message-ID: <200601140044.k0E0iaF07171@raven.dms.auburn.edu> References: <200601122345.k0CNjx114407@raven.dms.auburn.edu> <200601131418.k0DEIld23354@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137200702 3357 80.91.229.2 (14 Jan 2006 01:05:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2006 01:05:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 14 02:04:59 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ExZbL-0003p5-LQ for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 01:49:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExZdU-00023C-BO for ged-emacs-devel@m.gmane.org; Fri, 13 Jan 2006 19:51:16 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExZc9-0001pk-4i for emacs-devel@gnu.org; Fri, 13 Jan 2006 19:49:53 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExZc5-0001nP-HE for emacs-devel@gnu.org; Fri, 13 Jan 2006 19:49:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExZc4-0001n2-1T for emacs-devel@gnu.org; Fri, 13 Jan 2006 19:49:48 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ExZf8-0004sK-8U for emacs-devel@gnu.org; Fri, 13 Jan 2006 19:52:58 -0500 Original-Received: from raven.dms.auburn.edu (raven.dms.auburn.edu [131.204.53.29]) by manatee.dms.auburn.edu (8.13.3+Sun/8.13.3) with ESMTP id k0E0lQ2J028793; Fri, 13 Jan 2006 18:47:26 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k0E0iaF07171; Fri, 13 Jan 2006 18:44:36 -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-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.1 (manatee.dms.auburn.edu [131.204.53.104]); Fri, 13 Jan 2006 18:47:26 -0600 (CST) 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 Xref: news.gmane.org gmane.emacs.devel:49051 Archived-At: Kim Storm wrote: > (And some basic, often needed, things like resetting one > single option to its standard value would get very complex and clumsy.) So what. I bet that most people are used to click "Cancel" and start over if they mess things up too gravely. Suppose I save 10 different complex items in a Custom buffer for future sessions. Some sessions later I want to reset one of these to its standard value. I do not want to reset the other nine and redo them, because they are complex and would take a lot of work to redo, even if I actually could remember the values. How could I handle this without individual State buttons? How is your magic whole buffer "Cancel" button supposed to help me in this situation? > If it were implemented one > would definitely need to be able to hide options from the whole buffer > buttons. Why? They would just "save all options" -- just like any other GUI applications do when you click "Save" or "Appy" or "Ok". I honestly don't see why emacs has to be different here. Being different (be default) is just confusing. Two reasons: firstly, that interface has serious flaws and secondly, programs that use it take special steps to minimize the consequences of these flaws, which Emacs does not take at all, quite to the contrary. The example I gave above illustrates both reasons. In the "Apply-OK-Cancel" interface I can not even reset anything to its standard value to begin with, once I have OK'ed it. I can not even easily figure out what the standard value is. This is a major nuisance. The fact that you have to Apply or OK everything at once or completely punt, click "Cancel", loosing _all_ your edits and closing the application and then start it up again and start from scratch is another major (and very irritating) nuisance. But most applications with such an interface would limit customizability to simple enable-disable toggles and radio buttons, so at least you do not lose anything complex. This is not the case for Emacs customizations (except in the Options menubar item). Basically, the "Apply-OK-Cancel" interface becomes completely disfunctional once you apply it to a customization buffer containing several options that can be set to complex values. That is also why the Custom whole buffer buttons are completely disfunctional in multi-option buffers. Sincerely, Luc.