From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/62249 Path: news.gmane.org!not-for-mail From: Bill Wohler Newsgroups: gmane.emacs.devel,gmane.emacs.gnus.general Subject: Re: defcustom :version Date: Tue, 14 Mar 2006 16:06:04 -0800 Organization: Newt Software Message-ID: <12521.1142381164@olgas.newt.com> References: <15499.1142047137@olgas.newt.com> <200603110447.k2B4lbt10750@raven.dms.auburn.edu> <200603121454.k2CEsDf05104@raven.dms.auburn.edu> <200603140326.k2E3QFs05473@raven.dms.auburn.edu> <200603142332.k2ENW0928869@raven.dms.auburn.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1142384426 31147 80.91.229.2 (15 Mar 2006 01:00:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2006 01:00:26 +0000 (UTC) Cc: rms@gnu.org, ding@gnus.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 15 02:00:23 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 1FJKNC-0001DF-KV for ged-emacs-devel@m.gmane.org; Wed, 15 Mar 2006 02:00:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJKNC-0008Bo-5O for ged-emacs-devel@m.gmane.org; Tue, 14 Mar 2006 20:00:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FJKMm-0008AZ-Pm for emacs-devel@gnu.org; Tue, 14 Mar 2006 19:59:56 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FJKMk-00089V-JV for emacs-devel@gnu.org; Tue, 14 Mar 2006 19:59:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJKMk-00089O-CB for emacs-devel@gnu.org; Tue, 14 Mar 2006 19:59:54 -0500 Original-Received: from [207.69.195.68] (helo=pop-cowbird.atl.sa.earthlink.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FJKR0-0001Cl-6A; Tue, 14 Mar 2006 20:04:18 -0500 Original-Received: from h-68-165-5-58.snvacaid.dynamic.covad.net ([68.165.5.58] helo=olgas.newt.com) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1FJKMa-0004XF-00; Tue, 14 Mar 2006 19:59:44 -0500 Original-Received: by olgas.newt.com (Postfix, from userid 1000) id C2AD11707E; Tue, 14 Mar 2006 16:06:04 -0800 (PST) Original-Received: from olgas.newt.com (localhost [127.0.0.1]) by olgas.newt.com (Postfix) with ESMTP id BF2A816F9B; Tue, 14 Mar 2006 16:06:04 -0800 (PST) Original-To: Luc Teirlinck In-reply-to: <200603142332.k2ENW0928869@raven.dms.auburn.edu> Comments: In-reply-to Luc Teirlinck message dated "Tue, 14 Mar 2006 17:32:00 -0600." X-Mailer: MH-E 7.93+cvs; nmh 1.1; GNU Emacs 22.0.50.14 X-Image-URL: http://www.newt.com/wohler/images/bill-diving.png Mail-Followup-To: emacs-devel@gnu.org, ding@gnus.org 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:51635 gmane.emacs.gnus.general:62249 Archived-At: [Wondering if we should take ding@gnus.org off of the cc list...] Luc Teirlinck wrote: > Richard Stallman wrote: > > I don't follow the scenario you describe, but don't bother explaining > it. Reduction down to 2635 lines is not enough reduction to make the > situation much better. We need stronger measures. We need to give > this some structure. > > Here's an idea. customize-changed could work like customize-browse, > except that it would show only the groups that cover settings which > have changed meanings. > > What do you think? > > That would obviously not reduce the total number of listed options. I don't think that was the point. If we couldn't reduce the number of items, the point was to display them differently. > It would > not help somebody wanting to take a look at all of them (quite to the > contrary). I think it would, with a "Expand All" button. The user could then close off sub-trees they knew they were not interested in, which you can't do in the existing buffer. Or vice versa--the user could start collapsed and expand sub-trees they were interested in. It occurred to me that we'd need an Expand Entire Sub-Tree button too. > And with the current one-buffer layout, at least they are > listed alphabetically and one can use C-s. I rarely know the name of the variable before I know about it ;-). > It would also not do > anything about the problem that the command may take a very long time > on slow machines (it could actually make it worse). A legitimate concern, but I think the inverse will be true. Instrumenting the customize-change function, I see that it takes than a second to gather the options (on my machine), but over 30 seconds to render them. customize-browse is pretty much instantaneous on my machine, and would only be slowed by about a second (per above) to gather the options. Even expanding the entire customize-browse tree should be faster since it doesn't do as much rendering. But the advantage of the tree control is that you don't have to pay that price unless you want to. p.s. Shouldn't customize-changed-options-previous-release be 21.4, not 21.1? -- Bill Wohler http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane.