Gnus development mailing list
 help / color / mirror / Atom feed
From: Bill Wohler <wohler@newt.com>
Cc: rms@gnu.org, ding@gnus.org, emacs-devel@gnu.org
Subject: Re: defcustom :version
Date: Tue, 14 Mar 2006 16:06:04 -0800	[thread overview]
Message-ID: <12521.1142381164@olgas.newt.com> (raw)
In-Reply-To: <200603142332.k2ENW0928869@raven.dms.auburn.edu>

[Wondering if we should take ding@gnus.org off of the cc list...]

Luc Teirlinck <teirllm@dms.auburn.edu> 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 <wohler@newt.com>  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.

  reply	other threads:[~2006-03-15  0:06 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-11  3:18 Bill Wohler
2006-03-11  4:47 ` Luc Teirlinck
2006-03-11 20:40   ` Bill Wohler
2006-03-12 12:47     ` Richard Stallman
2006-03-12 20:30       ` Bill Wohler
2006-03-13 12:55         ` Richard Stallman
2006-03-14  2:58           ` Bill Wohler
2006-03-29  1:45           ` Bill Wohler
2006-03-29 23:02             ` Richard Stallman
2006-03-30  2:43               ` Bill Wohler
2006-03-30  3:11                 ` Luc Teirlinck
2006-03-30 17:28                   ` Bill Wohler
2006-03-31 17:28                     ` Richard Stallman
2006-03-31 18:11                       ` Bill Wohler
2006-04-01 13:46                         ` Richard Stallman
2006-04-11  0:10                           ` Bill Wohler
2006-04-01 14:23                         ` Eli Zaretskii
2006-03-31  3:10                   ` Richard Stallman
2006-03-30 19:53                 ` Wolfram Fenske
2006-03-30 21:18                   ` Bill Wohler
2006-04-07 18:44               ` Bill Wohler
2006-04-08 16:17                 ` Richard Stallman
2006-04-10 23:49                   ` Bill Wohler
2006-03-12 12:47   ` Richard Stallman
2006-03-12 14:54     ` Luc Teirlinck
2006-03-13  1:26       ` Richard Stallman
2006-03-14  3:26         ` Luc Teirlinck
2006-03-14  3:37           ` Luc Teirlinck
2006-03-14 16:09           ` Richard Stallman
2006-03-14 17:49             ` Bill Wohler
2006-03-15 20:20               ` Richard Stallman
2006-03-15 20:25                 ` Bill Wohler
2006-03-14 23:32             ` Luc Teirlinck
2006-03-15  0:06               ` Bill Wohler [this message]
2006-03-15  1:36                 ` Luc Teirlinck
2006-03-15  2:09                   ` Bill Wohler
2006-03-17 16:32                   ` Richard Stallman
2006-03-15 20:21               ` Richard Stallman
2006-03-11  5:02 ` Luc Teirlinck
2006-03-11 13:57 ` Reiner Steib
2006-03-11 23:57   ` Bill Wohler
2006-03-11 23:46 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12521.1142381164@olgas.newt.com \
    --to=wohler@newt.com \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).