From: Luc Teirlinck <teirllm@dms.auburn.edu>
Cc: emacs-devel@gnu.org
Subject: Re: Visual cleanup for customize buffers
Date: Fri, 13 Jan 2006 08:18:47 -0600 (CST) [thread overview]
Message-ID: <200601131418.k0DEIld23354@raven.dms.auburn.edu> (raw)
In-Reply-To: <m3ace0mhhe.fsf@kfs-l.imdomain.dk> (storm@cua.dk)
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.
next prev parent reply other threads:[~2006-01-13 14:18 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm
2006-01-12 23:45 ` Luc Teirlinck
2006-01-13 12:37 ` Kim F. Storm
2006-01-13 14:18 ` Luc Teirlinck [this message]
2006-01-13 15:16 ` Kim F. Storm
2006-01-13 19:05 ` Drew Adams
2006-01-13 19:16 ` David Kastrup
2006-01-13 23:28 ` Luc Teirlinck
2006-01-13 23:34 ` Luc Teirlinck
2006-01-14 16:14 ` Richard M. Stallman
2006-01-14 0:08 ` Luc Teirlinck
2006-01-14 0:44 ` Luc Teirlinck
2006-01-14 1:56 ` Kim F. Storm
2006-01-14 2:58 ` Chong Yidong
2006-01-14 6:10 ` Drew Adams
2006-01-14 16:14 ` Richard M. Stallman
2006-01-14 16:14 ` Richard M. Stallman
2006-01-14 20:50 ` Lennart Borgman
2006-01-14 21:32 ` Luc Teirlinck
2006-01-14 21:47 ` Lennart Borgman
2006-01-15 18:09 ` Luc Teirlinck
2006-01-15 18:41 ` Kim F. Storm
2006-01-15 19:59 ` Luc Teirlinck
2006-01-14 21:58 ` Drew Adams
2006-01-14 22:17 ` Drew Adams
2006-01-15 1:40 ` Luc Teirlinck
2006-01-15 23:08 ` Richard M. Stallman
2006-01-16 4:19 ` Luc Teirlinck
2006-01-19 17:44 ` Richard M. Stallman
2006-01-17 4:20 ` Luc Teirlinck
2006-01-17 20:00 ` Richard M. Stallman
2006-01-20 0:18 ` Luc Teirlinck
2006-01-13 16:40 ` Stefan Monnier
2006-01-13 19:04 ` Bill Wohler
2006-01-14 1:28 ` Luc Teirlinck
2006-01-14 1:46 ` Bill Wohler
2006-01-14 5:49 ` Richard M. Stallman
2006-01-14 15:28 ` Luc Teirlinck
2006-01-13 0:08 ` Luc Teirlinck
2006-01-13 15:24 ` Kim F. Storm
2006-01-13 19:33 ` martin rudalics
2006-01-13 0:24 ` Luc Teirlinck
2006-01-14 5:48 ` Richard M. Stallman
2006-01-14 5:49 ` Richard M. Stallman
2006-01-14 15:07 ` Luc Teirlinck
2006-01-14 23:05 ` Luc Teirlinck
2006-01-15 4:40 ` Luc Teirlinck
2006-02-05 0:07 ` Kim F. Storm
2006-02-06 2:07 ` Richard M. Stallman
2006-02-06 4:30 ` Luc Teirlinck
2006-02-06 7:21 ` Eli Zaretskii
2006-02-06 17:35 ` Luc Teirlinck
2006-01-14 23:27 ` Luc Teirlinck
2006-01-14 23:45 ` Drew Adams
2006-01-15 18:59 ` Kim F. Storm
2006-01-15 4:17 ` Luc Teirlinck
2006-01-15 23:08 ` Richard M. 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=200601131418.k0DEIld23354@raven.dms.auburn.edu \
--to=teirllm@dms.auburn.edu \
--cc=emacs-devel@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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.