From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: Visual cleanup for customize buffers Date: Sat, 14 Jan 2006 11:14:14 -0500 Message-ID: References: <200601122345.k0CNjx114407@raven.dms.auburn.edu> <200601131418.k0DEIld23354@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1137259944 31988 80.91.229.2 (14 Jan 2006 17:32:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2006 17:32:24 +0000 (UTC) Cc: teirllm@dms.auburn.edu, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 14 18:32:14 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 1ExpG6-0006gQ-Sy for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 18:32:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExpII-0007TZ-CT for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 12:34:26 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Exo7R-0006w6-Py for emacs-devel@gnu.org; Sat, 14 Jan 2006 11:19:10 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Exo7O-0006ui-Fd for emacs-devel@gnu.org; Sat, 14 Jan 2006 11:19:07 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Exo7N-0006uM-Fd for emacs-devel@gnu.org; Sat, 14 Jan 2006 11:19:06 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ExoAY-00057q-QL for emacs-devel@gnu.org; Sat, 14 Jan 2006 11:22:22 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1Exo2g-0007tu-Rp; Sat, 14 Jan 2006 11:14:14 -0500 Original-To: storm@cua.dk (Kim F. Storm) 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 Xref: news.gmane.org gmane.emacs.devel:49079 Archived-At: They do not operate on settings whose values are hidden, nor on subgroups not visible in the buffer. Indeed, this seems to be an intentional feature--not a quirk or a bug. Let's not change it. Agreed. The show/hide names even seem to imply that they only affect the display, not the behavior. That is a valid argument that there is a flaw in this feature. For now, we could fix it by changing the text that the State line displays in this case, to something like SET: Value has been set for this session; CAN'T BE SAVED NOW because hidden Other bigger changes could be considered for after the release but not for now. a) to be "expected" behavior, the naming would have to be something like Access/Disregard instead of Show/Hide. That might be a change we could make now, but I fear it will not be easy to decide what it should really say. b) if the visibility affects the operation of "save settings", it makes absolutely no sense that some options start out being shown, others hidden. It is absolutely essential that large values start out hidden. - If we keep global buttons (or equivalent menu items or whatever) that operate on multiple preferences all at once, each button action should: 1) explicitly list the preferences that will be affected or those that will *not* be affected (or perhaps both?), whichever group is smaller, and 2) require confirmation. That could be a good solution to that flaw, if it works out well in practice. - One way to do this would be to provide a check box next to each preference in the buffer and 1) precheck the boxes of those preferences that the program thinks could be targets If the "hide value" buttons control this, we don't need a checkbox to control it too.