[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: |
Drew Adams |
Subject: |
bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer |
Date: |
Sun, 28 Jul 2019 21:46:09 -0700 (PDT) |
> > 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, ndame, 2019/07/28
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Michael Heerdegen, 2019/07/29
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer,
Drew Adams <=
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, ndame, 2019/07/29
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Eli Zaretskii, 2019/07/29
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Michael Heerdegen, 2019/07/29
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Drew Adams, 2019/07/29
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Michael Heerdegen, 2019/07/30
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Drew Adams, 2019/07/30
- bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer, Michael Heerdegen, 2019/07/30