* add generic toggle, turn on, and turn off commands to Options menu
@ 2006-03-04 21:24 Drew Adams
2006-04-21 16:33 ` Drew Adams
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2006-03-04 21:24 UTC (permalink / raw
For after the Release or Godot, whichever comes first -
The question has occasionally been debated here whether such and such an
option merits a place on the Options menu, and, if so, where to put it
(submenu? order?). There are potentially lots and lots of boolean options
that could be added to the menu, but it also makes sense to keep the menu a
reasonable size.
Here's a suggestion that might mitigate the effect of leaving some options
out: As a fallback, add a generic menu item that reads the name of a binary
option and toggles its value. In fact, add three generic menu items, to 1)
toggle, 2) turn on, and 3) turn off any boolean option.
In my own code I use such commands, which are also in the Options menu. And
because many options are only "quasi-binary", you can use a prefix arg to
control how strict the interpretation of "binary" is, for purposes of
defining the set of completion candidates. Here's the doc string of the
toggle-option command:
Toggle option's value. This makes sense for binary (toggle) options.
By default, completion candidates are limited to user options that
have `boolean' custom types. However, there are many "binary" options
that allow other non-nil values than t.
You can use a prefix argument to change the set of completion
candidates, as follows:
- With a non-negative prefix arg, all user options are candidates.
- With a negative prefix arg, all variables are candidates.
Would this be useful?
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: add generic toggle, turn on, and turn off commands to Options menu
2006-03-04 21:24 add generic toggle, turn on, and turn off commands to Options menu Drew Adams
@ 2006-04-21 16:33 ` Drew Adams
2006-04-23 21:58 ` Richard Stallman
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2006-04-21 16:33 UTC (permalink / raw
Resending (and top-posting). The recent thread on "allout patch - more
safe-local-variables, plus autoloads" reminded me of this, even though there
is no real connection between the two. This is for after the release.
1. Many Emacs user options are quasi-binary: There is a primary behavior
difference via nil vs non-nil, and a secondary one via different non-nil
values. This is a common pattern.
In addition, even those options that have only a nil vs non-nil behavior
difference do not necessarily correspond to the custom type `boolean', which
reflects only t vs nil. The `boolean' custom type represents perhaps a
minority (?) of ~binary user options. A common custom type for quasi-binary
options is a `choice' of nil and one or more other values.
2. It can be useful to toggle any of these various ~binary options, even
though they don't all fit the standard toggling framework. When toggling a
quasi-binary option to a non-nil value, of course, which non-nil value to
use is up for grabs, but some general defaulting convention might be
adopted, or the user could simply be queried for which non-nil value to use.
As described in the original post, below, the user could use a prefix arg to
determine the strictness of "binary" for toggling - this would determine the
appropriate set of completion candidates. From strictest to laxest: a) only
defcustom `boolean's; b) all defcustom `choice's between nil and a single
other value; c) all defcustom `choice's that include nil; d) all user
options; e) all variables. For the last two cases, "toggling" would not
really mean toggling: it would just be setting the variable. But the
next-to-last could use `defcustom' :type info to control the set of
candidates. We might not want to differentiate between all of these
gradations - in my proposal below I used only (a), (d), and (e).
3. The Options menu is handy for toggling binary user options. That menu is
already large, however, and it is perhaps unreasonable to add all ~binary
options to it. So far, we have made this choice of menu items at design
time: we haggle over the choices in emacs-devel and then decide what is best
for the user.
4. Something additional, not proposed below: Which options are most useful
to have in the Options menu can depend on personal habits. We might define
Options with a default set but make it easy for users to modify this
interactively - that is, make the choice at runtime rather than design time.
This could also be automatic: Emacs might keep track of which options a user
changes most frequently, and adjust the Options menu accordingly.
This is done, for example, with the MS Windows Start menu: it automatically
reflects your use pattern, but you can also modify it manually
(interactively), to always include particular items. Emacs does something
similar with menus such as Buffers and Recent Files: they are updated
dynamically.
5. Even with an Options menu that is thus tailored to personal use, it would
be good for users to see readily which ~binary options are available (not
just those in the menu) and to be able to toggle any of them easily. That is
the reason for the proposal below: Provide a generic entry in the Options
menu (and a generic command) for toggling all binary and quasi-binary
options.
The generic toggle would, by minibuffer completion, show users which ~binary
options are available. It is by using the generic toggle (via menu or
command) that Emacs would track your toggling and automatically accomodate
the Options menu to your personal use (#4).
6. These two aspects of the proposal below can be separated: a) Add a
generic toggling item to the Options menu (and add a generic toggling
command). b) Try to accomodate quasi-binary options too wherever (or in some
of the places where) we deal with truly binary options (either in the sense
of nil vs non-nil or nil vs t).
7. Something additional, not proposed below: Save the current non-nil value,
when toggling from a non-nil value to a nil value. That would be the value
to restore when toggling back from nil to non-nil. For example, if you have
a defcustom :type of (choice (const :tag "None" nil) regexp) and the current
value is "foo.*", then toggling to nil would remember "foo.*" as the regexp
to restore when toggling again. This would probably require some changes to
the defcustom code.
8. The proposal below also suggests adding generic Turn On and Turn Off
items to the Options menu.
WDOT?
-----------
For after the Release or Godot, whichever comes first -
The question has occasionally been debated here whether such and such an
option merits a place on the Options menu, and, if so, where to put it
(submenu? order?). There are potentially lots and lots of
boolean options that could be added to the menu, but it also makes sense
to keep the menu a reasonable size.
Here's a suggestion that might mitigate the effect of leaving
some options out: As a fallback, add a generic menu item that reads the
name of a binary option and toggles its value. In fact, add three
generic menu items, to 1) toggle, 2) turn on, and 3) turn off any
boolean option.
In my own code I use such commands, which are also in the Options menu.
And because many options are only "quasi-binary", you can use a prefix
arg to control how strict the interpretation of "binary" is, for
purposes of defining the set of completion candidates. Here's the doc
string of the toggle-option command:
Toggle option's value. This makes sense for binary (toggle) options.
By default, completion candidates are limited to user options that
have `boolean' custom types. However, there are many "binary" options
that allow other non-nil values than t.
You can use a prefix argument to change the set of completion
candidates, as follows:
- With a non-negative prefix arg, all user options are candidates.
- With a negative prefix arg, all variables are candidates.
Would this be useful?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: add generic toggle, turn on, and turn off commands to Options menu
2006-04-21 16:33 ` Drew Adams
@ 2006-04-23 21:58 ` Richard Stallman
2006-04-23 22:42 ` Drew Adams
0 siblings, 1 reply; 5+ messages in thread
From: Richard Stallman @ 2006-04-23 21:58 UTC (permalink / raw
Cc: emacs-devel
I don't think it is desirable to create menu items for a lot more
options unless we do it with something like tabs so as to make it
easier to manage them all.
Maybe we could have a tabs-based customization buffer
that is modeled more closely after the configuration facilities
of other programs.
After the release, of course.
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: add generic toggle, turn on, and turn off commands to Options menu
2006-04-23 21:58 ` Richard Stallman
@ 2006-04-23 22:42 ` Drew Adams
2006-04-24 11:51 ` Richard Stallman
0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2006-04-23 22:42 UTC (permalink / raw
I don't think it is desirable to create menu items for a lot more
options unless we do it with something like tabs so as to make it
easier to manage them all.
I wonder if you misunderstood what I wrote or I misunderstand what you
wrote. My proposal (for after the release) was to add a _generic_ toggle
menu item, usable for any binary option.
That would _reduce_ the number of toggle items needed in the menu. At the
limit, this would be the _only_ toggle menu item needed, but it can be
useful to include a few commonly used toggle commands as menu items in their
own right. (I would give the user control over which other toggle items to
include, as I mentioned.)
Maybe we could have a tabs-based customization buffer
that is modeled more closely after the configuration facilities
of other programs.
That is something altogether different (orthogonal). A menu is for quick
toggling. Making the customization buffer tabs-based doesn't speak to the
same need, AFAICT.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: add generic toggle, turn on, and turn off commands to Options menu
2006-04-23 22:42 ` Drew Adams
@ 2006-04-24 11:51 ` Richard Stallman
0 siblings, 0 replies; 5+ messages in thread
From: Richard Stallman @ 2006-04-24 11:51 UTC (permalink / raw
Cc: emacs-devel
I wonder if you misunderstood what I wrote or I misunderstand what you
wrote. My proposal (for after the release) was to add a _generic_ toggle
menu item, usable for any binary option.
I think I did not read far enough to get to that part.
When a message is long, I read the beginning to see what it is about,
and based on that I decide whether I need to read the rest.
(So it is important to put the main point in the beginning.)
I don't like the idea of a generic toggle menu item.
I don't think that is a helpful UI. I don't have time to
discuss it, though.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-04-24 11:51 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-04 21:24 add generic toggle, turn on, and turn off commands to Options menu Drew Adams
2006-04-21 16:33 ` Drew Adams
2006-04-23 21:58 ` Richard Stallman
2006-04-23 22:42 ` Drew Adams
2006-04-24 11:51 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).