emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Commands that change user options? [was: Turning on/off tree-sitter mode


From: Drew Adams
Subject: Commands that change user options? [was: Turning on/off tree-sitter modes]
Date: Sun, 24 Nov 2024 05:32:37 +0000

> From: Eli Zaretskii Sent: Saturday, November 23, 2024 10:51 AM
> 
> But is it okay to have a command modify a user option?
> Do we have examples of this anywhere else?


Changing the Subject/thread.  (I know and care nothing
about tree-sitter modes, so far.)
___

IMHO, it's not a problem to have a command that changes
the value of a user option.  That can even be the main,
or even the only, point of a command.  The command's doc
string should say that it does that, of course.  That's
important.

A user using a command to change an option value is no
different from a user using the Customize UI to do so.
A command is just a different UI.

I've never agreed with the idea that Emacs must not allow
a command to set/change a user option - providing its doc
says clearly that that's its job (or part of its job).

It's typical for a minor mode toggle command to do that,
for instance.  And before we had minor modes (or at least
before we used them much) we had commands that toggled
user options.  There should be nothing shocking about this.
___

FWIW:

Vanilla isearch.el goes out of its way in a few places to
have additional variables that are defvars, and to allow
commands to change those vars instead of corresponding
user options, because of the (misguided, IMO) belief that
commands shouldn't ever change option values.  Or to give
it the benefit of the doubt, because it assumes that any
such changes shouldn't persist beyond the current search.

In isearch+.el I've tried to get along with (accommodate)
the vanilla Isearch way of handling such states (vars).

To do that (i.e., to allow some commands to toggle user
options, but not to impose that behavior) I've even added
an option, `isearchp-toggle-option-flag', which if non-nil
lets Isearch toggling commands affect option values.  And 
a nonvanilla command, `isearchp-toggle-option-toggle',
toggles that option!

That option applies only to the standard Isearch commands
`isearch-toggle-invisible' and `isearch-toggle-case-fold'.
In vanilla Emacs, those toggle non-option vars.  (But the
first toggles non-option `isearch-invisible' between the
two values of option `search-invisible'...)

To me, it's often useful to be able to toggle something
like case-folding and have that effect persist beyond a
single search.  It's also useful to have it _not_ persist
beyond a single search - both behaviors are useful.

My version of `isearch-toggle-case-fold' says this in
its doc string:

  Toggle case sensitivity on or off during incremental searching.

  If `isearchp-toggle-option-flag' is non-nil then toggle the value of
  option `isearchp-case-fold'.  If it is nil then toggle the behavior
  only temporarily, so that the option value is unchanged for subsequent
  searches.

  A prefix argument flips the sense of the last paragraph, so that the
  option is updated only if `isearchp-toggle-option-flag' is nil instead
  of non-nil.

Similarly, for `isearch-toggle-invisible'.  

I also have toggling commands for nonvanilla options and
non-option vars that I provide (prefix `isearchp-').  The
doc strings of such commands say whether they toggle an
option or an internal variable.  (It's only in order to
play nice with those two vanilla variables that I provide
`isearchp-toggle-option-flag' and its toggle command.)
___

Really, IMO the simplest thing to do is allow a command
to toggle - or otherwise change - the value of an option
or a non-option, as long as its doc says what it does.

But I've said all of this before - long ago.  Hasn't
convinced anyone in charge, so far.  But I'm glad to see
you pose the question now, Eli.  Maybe it's time to
loosen up on this?

I don't want Emacs to trounce a user's chosen value for
a user option any more than anyone else.  Such settings
are the province of users.  But I consider commands to
be UI's, and some can be UI's that affect options.  All
a command needs to do is let users know what it does.
___

Is there some downside to allowing a command to change
an option value (toggle or another kind of change)?
Only this minor one, that I'm aware of:

I have a function in my `kill-emacs-query-functions'
value called `customize-unsaved'.  If there are any
options whose values I've changed and not saved then
it opens Customize to show me them.  I appreciate such
notification, but I rarely want to save any changes.
(A typical change is toggling some minor mode.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]