bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[ndame]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

When doing a C-h v the Help buffer shows the value of the variable and also
its documentation.

Bind the currently unused key 'e' to edit the variable's value, maybe in a separate popup
buffer if the value is complex. E.g. the user presses e, the value pops up rendered in
editable lisp format, the user edits it in place, presses C-c C-c and the variable is set
to the new value.

[-- Attachment #2: Type: text/html, Size: 428 bytes --]

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

> When doing a C-h v the Help buffer shows
> the value of the variable and also its documentation.
>
> Bind the currently unused key 'e' to edit the
> variable's value, maybe in a separate popup
> buffer if the value is complex. E.g. the user
> presses e, the value pops up rendered in
> editable lisp format, the user edits it in place,
> presses C-c C-c and the variable is set
> to the new value.

I would say this isn't really needed or that helpful.
(Just one opinion.)

1. If the variable is a user option then:
   a. `*Help*' already shows a link to the Customize
      buffer, which is the proper place to change
      the value (and possibly save it).
   b. With the cursor on the option name in `*Help*',
      `M-x set-variable' defaults to the option name.

2. If the variable is not a user option, it may
   be buffer-local.  Does the user want to set the
   value in the current buffer or set the default
   value of the variable?  The behavior is different.

3. It's not hard to use `M-: (setq ...)' or
   `M-: (setq-default ...)' to set the new value.
   And it's not hard to copy the current value to
   the `setq(-default)' sexp and edit it there.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[ndame]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

> I would say this isn't really needed or that helpful.

Well, I say it's needed and helpful. :)

Not necessarily for basic users, they can use customize, but for advanced users who
know lisp well and prefer setting the values themselves, instead of navigating customize.

I check variable values all the time and I often want to change them, and it's bothersome
to copy the name and the value, when emacs could do it for me. A human should not do
what a computer can do automatically and in this case it's pretty easy for the computer
to read the value and set the variable to it. It could even copy the setting afterwards in
lisp form to the  kill-ring in case the user wants to further experiment with it, or copy
the setting to the init file.

If a variable has a buffer local value then it can ask if I want to set the local or global value.

 

[-- Attachment #2: Type: text/html, Size: 975 bytes --]

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Lars Ingebrigtsen]

ndame <emacsuser@freemail.hu> writes:

> Bind the currently unused key 'e' to edit the variable's value, maybe
> in a separate popup buffer if the value is complex. E.g. the user
> presses e, the value pops up rendered in editable lisp format, the
> user edits it in place, presses C-c C-c and the variable is set to the
> new value.

I think this sounds useful.  I'm often rooting around not quite sure
what variable I'm looking for in the help buffers, and trying different
values, and having a command to make this faster would be nice.  There's
`customize-variable', but I...  just don't like it.  (And besides, not
all variables are customisable...)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> ndame <emacsuser@freemail.hu> writes:
>
>> Bind the currently unused key 'e' to edit the variable's value, maybe
>> in a separate popup buffer if the value is complex. E.g. the user
>> presses e, the value pops up rendered in editable lisp format, the
>> user edits it in place, presses C-c C-c and the variable is set to the
>> new value.
>
> I think this sounds useful.  I'm often rooting around not quite sure
> what variable I'm looking for in the help buffers, and trying different
> values, and having a command to make this faster would be nice.  There's
> `customize-variable', but I...  just don't like it.  (And besides, not
> all variables are customisable...)

There's also M-x set-variable, which inserts the current value of the
variable when you type M-n.  Perhaps all that's needed is for
set-variable to also detect the variable described in the current *Help*
buffer, and offer it as one of the default variables to set, following
the value of variable-at-point (which is the current default).

-- 
Basil

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

> > I think this sounds useful.  I'm often rooting around not quite sure
> > what variable I'm looking for in the help buffers, and trying
> > different values, and having a command to make this faster would be nice.
> > There's `customize-variable', but I...  just don't like it.  (And besides,
> > not all variables are customisable...)
> 
> There's also M-x set-variable, which inserts the current value of the
> variable when you type M-n.  Perhaps all that's needed is for
> set-variable to also detect the variable described in the current
> *Help*
> buffer, and offer it as one of the default variables to set, following
> the value of variable-at-point (which is the current default).

I mentioned `set-variable'.  But it is only for
user options.  (And there is already a link to
Customize for the variable being described.)

And there's `M-: (setq...)`.  But for that what's
missing is the ability to insert buffer text (e.g.
a variable name at point) into the minibuffer.
(See the discussion in bug #36525 about that.)

And see discussions in emacs-devel:
2017, "custom-set-variables considered harmful",
2011, "set-variable and defcustom",
2010, "`set-variable' should use :set",
2007, "customize-set-(value|variable)",
2007, "apropos commands for commands, user options, all functions, all variables".

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Juri Linkov]

> I mentioned `set-variable'.  But it is only for user options.

I use such advice to workaround this restriction:

;; Allow set-variable to set all variables, not only customizable ones:
(advice-add 'set-variable :around
	    (lambda (orig-fun &rest args)
	      (interactive (lambda (spec)
			     (cl-letf (((symbol-function 'custom-variable-p)
                                        (lambda (v)
                                          (and (symbolp v) (boundp v)))))
                               (advice-eval-interactive-spec spec))))
	      (cl-flet ((custom-variable-p (v) t))
		(apply orig-fun args)))
	    '((name . override-custom-variable)))

But I agree with Michael this should be allowed only to developers.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> There's also M-x set-variable, which inserts the current value of the
> variable when you type M-n.

Oh, nice.  I didn't know that.

> Perhaps all that's needed is for set-variable to also detect the
> variable described in the current *Help* buffer, and offer it as one
> of the default variables to set, following the value of
> variable-at-point (which is the current default).

Yes, or bind `e' to a command that would call `set-variable' with the
variable under point?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

See the older discussions I pointed to previously
for why command `customize-set-variable' is
generally preferable to command `set-variable'.
(Or compare their doc and behavior.)

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think this sounds useful.  I'm often rooting around not quite sure
> what variable I'm looking for in the help buffers, and trying
> different values, and having a command to make this faster would be
> nice.  There's `customize-variable', but I...  just don't like it.
> (And besides, not all variables are customisable...)

There are also some downsides:

- Changing variables might break Emacs if you are not knowing what you
are doing.  Customize at least has some safety checks.  Users might not
expect that clicking on the button and changing values might have
dangerous consequences.  Likewise, Emacs might change or modify the
value and users wonder why their setting had been "rejected".  With
other words: it is potentially dangerous and might confuse users.

- It is no fun for variables with complicated values, like large lists
of lists.  Just a minibuffer prompt would not be nice.  Here you
probably still would use scratch or so.  And even in the situation you
described, I would prefer having an expression in scratch, edit and eval
it, compared to clicking a button in the help buffer and edit in the mb
or a popup buffer.

- There are nitpicks which may complicate doing what at first sounds
simple, e.g. what if the value includes things were printing and reading
comes into play?  E.g. buffers: they have a print syntax, but it's not a
read syntax.  Objects may be replaced by equal objects (e.g. lists will
be recreated) which might confuse Emacs.  There is buffer local
vs. global bindings of variables (and hooks), etc.

But my main point is the question if we should really invite the typical
user, which is not an Emacs developer (ok, here I'm not really sure if
I'm right) to change variables on the fly, or if it's not better if
these users are directed to customize, and the others use just M-: or
ielm or what they use now.

Michael.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[ndame]

[-- Attachment #1: Type: text/plain, Size: 2105 bytes --]

> - It is no fun for variables with complicated values, like large lists
of lists. Just a minibuffer prompt would not be nice.

That's why I mentioned popup buffers for complicated values. It could
be especially useful for variables with complicated values like nested 
lists. You just press e, a buffer pops up with the value, so you don't have
to manually copy it to scratch, etc. you can tweak it in place quickly and
set it with C-c C-c

> Here you probably still would use scratch or so. And even in the situation you
> described, I would prefer having an expression in scratch, edit and eval
> it, compared to clicking a button in the help buffer and edit in the mb
>or a popup buffer.

A related idea is that we could have the key c bound to copy as elisp. So you 
want to tweak a variable. You press c and the lisp form of setting the 
variable (setq varname ....current value...) is copied to the kill ring which you can tweak in 
scratch.

This could trivially do the tedious work of copying the variable's name and 
value manually.



> - There are nitpicks which may complicate doing what at first sounds
> simple, e.g. what if the value includes things were printing and reading
> comes into play?  E.g. buffers: they have a print syntax, but it's not a
> read syntax.

We are talking about variables which the user sets from lisp. Variables
containing buffer objects are not such. For these the feature could 
throw an error saying the variable cannot be changed manually.

> But my main point is the question if we should really invite the typical
user, which is not an Emacs developer (ok, here I'm not really sure if
I'm right) to change variables on the fly,

I don't know what you mean by emacs developer (core developer?), but
the typical emacs user tends to learn lisp, so he can extend and mold
the editor to his needs. Such a user inspects variables, changes them,
copies code to the init file etc. This feature targets those users who 
are beyond customize, able to use lisp and tweak variables and other
things often in emacs.
 

[-- Attachment #2: Type: text/html, Size: 2424 bytes --]

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Eli Zaretskii]

> Date: Mon, 29 Jul 2019 04:38:25 +0000 (GMT)
> From: ndame <emacsuser@freemail.hu>
> Cc: "36826@debbugs.gnu.org" <36826@debbugs.gnu.org>
> 
> > - It is no fun for variables with complicated values, like large lists
> of lists. Just a minibuffer prompt would not be nice.
> 
> That's why I mentioned popup buffers for complicated values. It could
> be especially useful for variables with complicated values like nested 
> lists. You just press e, a buffer pops up with the value, so you don't have
> to manually copy it to scratch, etc. you can tweak it in place quickly and
> set it with C-c C-c

Would invoking Customize with 'e' fix most of the problems?

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Michael Heerdegen]

ndame <emacsuser@freemail.hu> writes:

> A related idea is that we could have the key c bound to copy as
> elisp. So you want to tweak a variable. You press c and the lisp form
> of setting the variable (setq varname ....current value...) is copied
> to the kill ring which you can tweak in scratch.

It's convenient, but also a small gain: copy the variable to scratch,
hit C-u C-x C-e, and you already have most of this.  Takes two seconds
or so to type all that to have the complete setq form.

> We are talking about variables which the user sets from lisp. Variables
> containing buffer objects are not such. For these the feature could
> throw an error saying the variable cannot be changed manually.

Could be done.  Note that already variables whose values contain
functions could throw this error.

> > But my main point is the question if we should really invite the typical
> > user, which is not an Emacs developer (ok, here I'm not really sure if
> > I'm right) to change variables on the fly,

> I don't know what you mean by emacs developer (core developer?), but
> the typical emacs user tends to learn lisp, so he can extend and mold
> the editor to his needs. Such a user inspects variables, changes them,
> copies code to the init file etc. This feature targets those users who
> are beyond customize, able to use lisp and tweak variables and other
> things often in emacs.

Doing so is quite often a mistake.  Some variables should not be set
outside of customize.  Other variables, especially list valued variables
we spoke about, often need to be value modified instead of set.  And for
variables with atom values, the gain is small.

Michael.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

In addition to what Michael said, I'll add this, for
those who think Customize is not for Lispers or is
otherwise beneath them.

If you customize a list-valued option, such as
`default-frame-alist', and you use `M-x customize-option'
on it, menu `State' lets you choose `Show Saved Lisp
expression', which does what it says: replaces the `INS'
and `DEL' entries of `Parameter' and `Value' with, well
the alist as a Lisp sexp.  Edit that there, or edit it
elsewhere.

IOW, `customize-option' gives you more along the lines
of what was requested than does `customize-set-variable'.
But yes, `customize-set-variable' should at least give
you the current value using `M-n'.  Given that value,
even a complex one, you could edit it in the minibuffer.

(`set-variable' does make the current value available
as the default (`M-n') for editing.  In other respects
`customize-set-variable' is preferable to `set-variable'.)

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:
>
> (`set-variable' does make the current value available
> as the default (`M-n') for editing.  In other respects
> `customize-set-variable' is preferable to `set-variable'.)

AFAICT: doesn't `customize-set-variable' prefill the minibuffer with
the current value?

Michael.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

> > (`set-variable' does make the current value available
> > as the default (`M-n') for editing.  In other respects
> > `customize-set-variable' is preferable to `set-variable'.)
> 
> AFAICT: doesn't `customize-set-variable' prefill the minibuffer with
> the current value?

Seems to depend.  For `fill-column', yes.  For
`default-frame-alist' no.  You get a hint at
the beginning of the prompt: "[repeat]", but
you have no idea what to repeat, no completion,
etc.  You don't get the current value, as a
complex list etc., AFAICT.  (I haven't checked
the code, to see what it really does.)

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > > (`set-variable' does make the current value available
> > > as the default (`M-n') for editing.  In other respects
> > > `customize-set-variable' is preferable to `set-variable'.)
> >
> > AFAICT: doesn't `customize-set-variable' prefill the minibuffer with
> > the current value?
>
> Seems to depend.  For `fill-column', yes.  For
> `default-frame-alist' no.  You get a hint at
> the beginning of the prompt: "[repeat]", but
> you have no idea what to repeat, no completion,
> etc.  You don't get the current value, as a
> complex list etc., AFAICT.

Oh, indeed.  At the end, in this case the :prompt-value spec of the
default widget is used (the repeat widget which is used here inherits
it), which is the quite simple `widget-default-prompt-value'.

Michael.

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Drew Adams]

> > I think this sounds useful.  I'm often rooting around not quite sure
> > what variable I'm looking for in the help buffers, and trying
> > different values, and having a command to make this faster would be
> > nice.  There's `customize-variable', but I...  just don't like it.
> > (And besides, not all variables are customisable...)
>
> There are also some downsides:
> 
> - Changing variables might break Emacs if you are not knowing what you
> are doing.  Customize at least has some safety checks.  Users might not
> expect that clicking on the button and changing values might have
> dangerous consequences.  Likewise, Emacs might change or modify the
> value and users wonder why their setting had been "rejected".  With
> other words: it is potentially dangerous and might confuse users.
> 
> - It is no fun for variables with complicated values, like large lists
> of lists.  Just a minibuffer prompt would not be nice.  Here you
> probably still would use scratch or so.  And even in the situation you
> described, I would prefer having an expression in scratch, edit and
> eval it, compared to clicking a button in the help buffer and edit
> in the mb or a popup buffer.
> 
> - There are nitpicks which may complicate doing what at first sounds
> simple, e.g. what if the value includes things w[h]ere printing and
> reading comes into play?  E.g. buffers: they have a print syntax,
> but it's not a read syntax.  Objects may be replaced by equal objects
> (e.g. lists will be recreated) which might confuse Emacs.  There is
> buffer local vs. global bindings of variables (and hooks), etc.
> 
> But my main point is the question if we should really invite the
> typical user, which is not an Emacs developer (ok, here I'm not
> really sure if I'm right) to change variables on the fly, or if
> it's not better if these users are directed to customize, and the
> others use just M-: or ielm or what they use now.

All good points, I think.

And I'm not convinced of the problem the proposed
solution tries to solve.  But maybe I don't have
a good idea of what the problem is.

FWIW, I don't think I ever find myself "rooting
around not quite sure what variable I'm looking
for in the help buffers, and trying different
values".  But maybe I don't really know what Lars
meant by that.  Is that about wanting better apropos
features, to find the right variable?  How about an
example of such rooting around?

bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think this sounds useful.  I'm often rooting around not quite sure
> what variable I'm looking for in the help buffers, and trying different
> values, and having a command to make this faster would be nice. 

I've now added this to Emacs 29 -- doubly disabled by default, to
discourage casual users from using it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no