add generic toggle, turn on, and turn off commands to Options menu

add generic toggle, turn on, and turn off commands to Options menu

[Drew Adams]

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?

RE: add generic toggle, turn on, and turn off commands to Options menu

[Drew Adams]

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?

Re: add generic toggle, turn on, and turn off commands to Options menu

[Richard Stallman]

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.

RE: add generic toggle, turn on, and turn off commands to Options menu

[Drew Adams]

    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.

Re: add generic toggle, turn on, and turn off commands to Options menu

[Richard Stallman]

    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.