From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: customize-apropos
Date: Thu, 15 Dec 2005 08:33:16 -0800 [thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICCEENDAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <200512150533.jBF5Xk027595@raven.dms.auburn.edu>
I do not believe that the numeric arg is really useful (it is just a
confusing alternative to apropos-variable), but it does no real harm
either. Unless somebody uses it for no other reason that they do not
know about apropos-variable. That is why I proposed my patch pointing
out in the docstrings that in most cases using `apropos-variable' is
more useful than using the numeric arg to `customize-apropos'.
One big difference between `customize-apropos-options' and
`apropos-variable' is that the former puts you in a Custom buffer, where you
can customize options and easily navigate (browse). Even if someone wants to
_see_ all matching variables, (s)he might still want to browse or customize
some customizable user options. Plus, Custom is intended to present a more
"user-friendly" face for option names, values, and value descriptions (I
won't go to the death defending the current implementation of that feature,
however).
So, I cannot agree that "in most cases using `apropos-variable' is more
useful." It is, in most use cases, _less_ useful. Everything that
`apropos-variable' gives you, `customize-apropos-options' (with prefix arg)
gives you too. And the latter gives you more, and in a more digestible
format (that's the intention, anyway).
My point was not to get rid of the C-u behavior - it was to get rid of it
_IF_ the only acceptable (to you and RMS) alternative is an end-user
description that is confusing or frightening. Fixing the language is the
other alternative.
I said: "Experts don't need this (C-u) any more than regular users."
Equivalent: Regular users need this (C-u) just as much as expert users.
Casting the C-u behavior as an expert-user feature is wrong, IMO.
The alternatives I proposed are: get rid of the C-u behavior _OR_ fix the
descriptions of non-defcustom variables, so they don't confuse and frighten.
Richard's latest proposal of wording is this:
"NO CUSTOMIZATION DATA; set this only if you know what you are doing."
I feel that "if you know what you are doing" is confusing, unhelpful, and
frightening. Might as well say "Don't set this!" - those who do know what
they're doing will presumably know enough to ignore that admonition.
_I_ don't know what "if you know what you are doing" means (how does one
know whether one knows? what's the secret key?), so I must assume that I
don't know what I'm doing. Fair enough, I won't set the option in Custom -
but I won't learn anything about why not or about how I might legitimately
set it (`set-variable').
I will get the (false) impression that setting that option is something only
for THOSE WHO KNOW (and know that they know). And I will have no idea how to
become a member of those-who-know. I will come away thinking that Emacs is
indeed mysterious and Custom is not something for the faint of heart. I will
wonder why, if people should not set those options, setting them was
presented as a possibility (instead of simply getting rid of the State
button or editable Value field). I'll begin to wonder about a lot of things
Custom, in fact.
If we cannot distinguish the problematic (bug) cases (which Luc listed) and
the internal-variable cases from the non-defcustom user-option cases (`*' in
doc string), then I guess we are stuck with language such as that Richard
proposed.
But a better solution would be to distinguish those cases, and tell people,
in the user-option case, that they can use `set-variable' - nothing to fear
here, nothing esoteric. For a non-defcustom user option, we could even
provide a link that called `set-variable' directly. IOW, it's better to
reserve the less-informative, more frightening language for the bug and
internal-variable cases. Better still would be to remove the State button
from variables whose value should not be changed in Custom - experts have
other ways to change them.
And, as I mentioned near the beginning of this thread, it is at least as
useful to be able to show all _user options_ (no internal variables) as it
is to show all variables (current C-u behavior). If we offered that (e.g.
via C-u `customize-apropos-options' or via `customize-apropos-variables'),
and we got rid of some of the bug cases, and we distinguished the
`set-variable' user options, then we would have no scary, abracadabra,
secret-cult language at all.
If this is too much to ask before the release, consider this a prelude to
Customize discussions to come after the release. That beast sorely needs to
be tamed.
next prev parent reply other threads:[~2005-12-15 16:33 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-10 3:47 customize-apropos Luc Teirlinck
2005-12-10 3:51 ` customize-apropos Luc Teirlinck
2005-12-10 23:04 ` customize-apropos Kim F. Storm
2005-12-10 23:07 ` customize-apropos Luc Teirlinck
2005-12-11 16:49 ` customize-apropos Richard M. Stallman
2005-12-11 5:03 ` customize-apropos Richard M. Stallman
2005-12-11 17:57 ` customize-apropos Drew Adams
2005-12-12 5:03 ` customize-apropos Luc Teirlinck
2005-12-12 5:40 ` customize-apropos Drew Adams
2005-12-12 23:56 ` customize-apropos Luc Teirlinck
2005-12-13 0:22 ` customize-apropos Drew Adams
2005-12-13 0:45 ` customize-apropos Luc Teirlinck
2005-12-13 3:55 ` customize-apropos Drew Adams
2005-12-13 1:01 ` customize-apropos Luc Teirlinck
2005-12-13 1:29 ` customize-apropos Luc Teirlinck
2005-12-13 23:33 ` customize-apropos Richard M. Stallman
2005-12-14 1:14 ` customize-apropos Luc Teirlinck
2005-12-14 1:25 ` customize-apropos Drew Adams
2005-12-14 2:13 ` customize-apropos Luc Teirlinck
2005-12-14 3:20 ` customize-apropos Drew Adams
2005-12-14 3:40 ` customize-apropos Luc Teirlinck
2005-12-14 3:52 ` customize-apropos Drew Adams
2005-12-14 5:58 ` customize-apropos Luc Teirlinck
2005-12-14 15:07 ` customize-apropos Drew Adams
2005-12-15 5:33 ` customize-apropos Luc Teirlinck
2005-12-15 16:33 ` Drew Adams [this message]
2005-12-16 5:09 ` customize-apropos Richard M. Stallman
2005-12-14 3:45 ` customize-apropos Luc Teirlinck
2005-12-14 3:54 ` customize-apropos Drew Adams
2005-12-14 20:02 ` customize-apropos Richard M. Stallman
2005-12-15 4:18 ` customize-apropos Luc Teirlinck
2005-12-16 1:51 ` customize-apropos Richard M. Stallman
2005-12-16 3:47 ` customize-apropos Luc Teirlinck
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=DNEMKBNJBGPAOPIJOOICCEENDAAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
/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.