From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Visual cleanup for customize buffers Date: Sat, 14 Jan 2006 22:47:40 +0100 Message-ID: <43C9717C.4020900@student.lu.se> References: <200601122345.k0CNjx114407@raven.dms.auburn.edu> <200601131418.k0DEIld23354@raven.dms.auburn.edu> <43C9642E.3050301@student.lu.se> <200601142132.k0ELWUi21167@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1137275312 16084 80.91.229.2 (14 Jan 2006 21:48:32 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2006 21:48:32 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 14 22:48:22 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 1ExtFr-0004uI-9a for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 22:48:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExtI3-0002Cd-AL for ged-emacs-devel@m.gmane.org; Sat, 14 Jan 2006 16:50:27 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ExtHt-0002BC-94 for emacs-devel@gnu.org; Sat, 14 Jan 2006 16:50:17 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ExtHs-0002Ai-MU for emacs-devel@gnu.org; Sat, 14 Jan 2006 16:50:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ExtHs-0002AO-Gn for emacs-devel@gnu.org; Sat, 14 Jan 2006 16:50:16 -0500 Original-Received: from [81.228.11.159] (helo=pne-smtpout2-sn1.fre.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ExtL5-0006l5-E7; Sat, 14 Jan 2006 16:53:35 -0500 Original-Received: from [192.168.123.121] (83.249.218.244) by pne-smtpout2-sn1.fre.skanova.net (7.2.069.1) id 43C778C400067BAE; Sat, 14 Jan 2006 22:47:41 +0100 User-Agent: Thunderbird 1.5 (Windows/20051201) Original-To: Luc Teirlinck In-Reply-To: <200601142132.k0ELWUi21167@raven.dms.auburn.edu> 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:49101 Archived-At: Luc Teirlinck wrote: > Lennart Borgman wrote: > > Would it perhaps be easy to make it impossible to hide a value that has > been changed and not set in the current custom buffer? That could > perhaps be a bit less confusing. > > If I understand correctly, it is already supposed to be impossible > right now. You should get the minibuffer message: "There are unset changes". > Was there some case where this failed for you? > No, sorry, I actually forgot that. However the other cases you mentioned seem to me serious enough. > According to Kim's theory, if I understand it correctly, people > accustomed to the "Apply-OK-Cancel" type interface would never > use anything but the whole buffer "Save for Future Sessions", > "Undo Edits" (and "Finish") buttons. In that case, the fact that > these buttons will not work on hidden items will _never_ inconvenience > them, because there will be no hidden edited items. > I would guess it is quite natural to use Hide but still assume that the whole buffer buttons apply. > Note that in the many years that this feature existed (as long as > Custom has been part of Emacs), there was not exactly a flood of > complaints by people having been surprised or inconvenienced by it. > I know of none (before yesterday). Complaints only started after I > pointed the feature out, from people who did not know it existed, and > hence probably had never been affected by the feature either. > My impression when we started looking at Custom was that not many developers or advanced users were using it. Could that perhaps be part of the reason that there were not many complaints? A feature as obscure as this (that hidden values do not get saved or set) is very easy to miss. You probably set several features if you hide the value before hitting the set or save buttons. When you perhaps quite a while afterward notice something is not working you may have forgotten or you may very well guess it is some kind of bug instead.