bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Michael Heerdegen
Subject: bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer
Date: Tue, 30 Jul 2019 02:59:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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.





reply via email to

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