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 08:18:47 -0600 (CST) Message-ID: <200601131418.k0DEIld23354@raven.dms.auburn.edu> References: <200601122345.k0CNjx114407@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1137173846 30167 80.91.229.2 (13 Jan 2006 17:37:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2006 17:37:26 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 13 18:37:21 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 1ExSqF-0003DA-PP for ged-emacs-devel@m.gmane.org; Fri, 13 Jan 2006 18:36:00 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExSsG-0001dd-Uz for ged-emacs-devel@m.gmane.org; Fri, 13 Jan 2006 12:38:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExPqR-0004mY-IE for emacs-devel@gnu.org; Fri, 13 Jan 2006 09:23:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExPqO-0004lj-Nj for emacs-devel@gnu.org; Fri, 13 Jan 2006 09:23:59 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExPqO-0004lf-KD for emacs-devel@gnu.org; Fri, 13 Jan 2006 09:23:56 -0500 Original-Received: from [131.204.53.104] (helo=manatee.dms.auburn.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ExPtO-0006RF-3l for emacs-devel@gnu.org; Fri, 13 Jan 2006 09:27:02 -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 k0DELavC024499; Fri, 13 Jan 2006 08:21:36 -0600 (CST) Original-Received: (from teirllm@localhost) by raven.dms.auburn.edu (8.11.7p1+Sun/8.11.7) id k0DEIld23354; Fri, 13 Jan 2006 08:18:47 -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 08:21:36 -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:48996 Archived-At: Kim Storm wrote: - click on whole buffer "Save for Future Sessions" button => saves the unset options, but NOT the changed face!! That is because you hid it, as I explained. Really?? The "hide value" button is right there when I look! I don't see any code that removes the button -- that's what I added. Yes, I somehow got confused here. I do not know why I somehow did not notice the button there. I don't see why! If people want to save indiviual options, use the individual State buttons. If people want to save everything, use the whole buffer buttons. It would definitely be wrong to change the behavior of the whole buffer buttons with respect to hidden items before the release. Some of the few people who use the whole buffer buttons may have come to rely on it. Importantly, some Custom internals rely on the whole buffer buttons not operating on hidden buttons. For instance, it is what prevents the whole buffer buttons from recursively descending into subgroups (which would be a bug with very bad consequences). Also, if one changed the behavior, it would be very difficult to avoid introducing a variety of other bugs. For instance, one would have to make sure that the whole buffer buttons would not operate on hidden options that are set outside Custom or are otherwise "rogue", which would also be a very bad bug. There has been a previous discussion on Custom where you proposed to get rid of the State buttons (at least by default). I believe that the present discussion shows that this would be a very bad idea (except maybe in single option buffers). If it were implemented one would definitely need to be able to hide options from the whole buffer buttons. (And some basic, often needed, things like resetting one single option to its standard value would get very complex and clumsy.) I believe that the main problem with the whole buffer buttons (and related functionality) is that it is too visible to beginning users, who should not use them (except in single option buffers), because they are too tricky to use. Sincerely, Luc.