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: Customize buttons that change user's custom fileshouldaskforconfirmation Date: Sun, 20 Feb 2005 17:00:23 -0800 Message-ID: References: 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 1108948058 18475 80.91.229.2 (21 Feb 2005 01:07:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 Feb 2005 01:07:38 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 21 02:07:38 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D322j-0001fN-HL for ged-emacs-devel@m.gmane.org; Mon, 21 Feb 2005 02:07:21 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D32Ja-0004DD-7I for ged-emacs-devel@m.gmane.org; Sun, 20 Feb 2005 20:24:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D32Hr-0003U6-PH for emacs-devel@gnu.org; Sun, 20 Feb 2005 20:23:02 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D32Hk-0003Q2-LM for emacs-devel@gnu.org; Sun, 20 Feb 2005 20:22:53 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D32Hk-0003Md-Ej for emacs-devel@gnu.org; Sun, 20 Feb 2005 20:22:52 -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 1D31xR-0005tF-H6 for emacs-devel@gnu.org; Sun, 20 Feb 2005 20:01:53 -0500 Original-Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j1L11qFb012156 for ; Sun, 20 Feb 2005 17:01:52 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet02.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j1L10bwB011175 for ; Sun, 20 Feb 2005 17:00:46 -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 j1L10aXA027912 for ; Sun, 20 Feb 2005 18:00:36 -0700 Original-Received: from dradamslap (dhcp-amer-whq-csvpn-gw3-141-144-81-110.vpn.oracle.com [141.144.81.110]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j1L10Zom027902 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sun, 20 Feb 2005 18:00:36 -0700 Original-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE 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:33658 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33658 Maybe the "Customize" menu could have a simple check-box option for "Show per-option action buttons". The inquisitive emacs user will surely find it :-) I agree that if a user enabled this, the global buttons should not be shown. This is a compromise that gives both approaches what they want. We should, however, strive to adopt such a compromise only if there is a consensus that there is (separate) value in having _each_ approach - not simply because we can't seem to reach consensus on _which_ approach is best. I doubt that we currently agree that both approaches are good (simple, safe, etc.), and that which to use should just be a user choice (option). From the current state of the discussion, it sounds more like each "side" thinks that his side is the "simpler" and "safer" approach. I agree with everyone else that no action should be taken now. In fact, the remainder of the customize-design discussion should be postponed until after 22.1 is released. There is a lot that we could put on the table for discussion regarding customize, and some of the issues are best discussed in combination. I think we all have the same general goals, and our differences probably reflect (mainly) different usage patterns or mutual misunderstandings. That is, I expect that we can in fact reach consensus on what is the best approach, given sufficient time and discussion. Customize is complex, the present UI provides lots of possibilities for a user, and the possibilities of changing customize to improve it are innumerable. So, it's no wonder that we haven't yet reached consensus - we haven't really explored the customize design space much. And, as I mentioned once before, it is essential to get input from Per, who understands the original design well - both the intent and the howto.