* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer @ 2019-07-28 6:08 ndame 2019-07-28 16:51 ` Drew Adams 2019-07-28 18:01 ` Lars Ingebrigtsen 0 siblings, 2 replies; 19+ messages in thread From: ndame @ 2019-07-28 6:08 UTC (permalink / raw) To: 36826 [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 6:08 bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer ndame @ 2019-07-28 16:51 ` Drew Adams 2019-07-28 17:53 ` ndame 2019-07-28 18:01 ` Lars Ingebrigtsen 1 sibling, 1 reply; 19+ messages in thread From: Drew Adams @ 2019-07-28 16:51 UTC (permalink / raw) To: ndame, 36826 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 16:51 ` Drew Adams @ 2019-07-28 17:53 ` ndame 0 siblings, 0 replies; 19+ messages in thread From: ndame @ 2019-07-28 17:53 UTC (permalink / raw) To: Drew Adams, 36826@debbugs.gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 6:08 bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer ndame 2019-07-28 16:51 ` Drew Adams @ 2019-07-28 18:01 ` Lars Ingebrigtsen 2019-07-29 4:00 ` Basil L. Contovounesios ` (2 more replies) 1 sibling, 3 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2019-07-28 18:01 UTC (permalink / raw) To: ndame; +Cc: 36826 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 18:01 ` Lars Ingebrigtsen @ 2019-07-29 4:00 ` Basil L. Contovounesios 2019-07-29 4:35 ` Drew Adams 2019-07-29 13:55 ` Lars Ingebrigtsen 2019-07-29 4:28 ` Michael Heerdegen 2022-04-17 17:00 ` Lars Ingebrigtsen 2 siblings, 2 replies; 19+ messages in thread From: Basil L. Contovounesios @ 2019-07-29 4:00 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ndame, 36826 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:00 ` Basil L. Contovounesios @ 2019-07-29 4:35 ` Drew Adams 2019-07-29 18:15 ` Juri Linkov 2019-07-29 13:55 ` Lars Ingebrigtsen 1 sibling, 1 reply; 19+ messages in thread From: Drew Adams @ 2019-07-29 4:35 UTC (permalink / raw) To: Basil L. Contovounesios, Lars Ingebrigtsen; +Cc: ndame, 36826 > > 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". ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:35 ` Drew Adams @ 2019-07-29 18:15 ` Juri Linkov 0 siblings, 0 replies; 19+ messages in thread From: Juri Linkov @ 2019-07-29 18:15 UTC (permalink / raw) To: Drew Adams; +Cc: Basil L. Contovounesios, Lars Ingebrigtsen, ndame, 36826 > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:00 ` Basil L. Contovounesios 2019-07-29 4:35 ` Drew Adams @ 2019-07-29 13:55 ` Lars Ingebrigtsen 2019-07-29 14:18 ` Drew Adams 1 sibling, 1 reply; 19+ messages in thread From: Lars Ingebrigtsen @ 2019-07-29 13:55 UTC (permalink / raw) To: Basil L. Contovounesios; +Cc: ndame, 36826 "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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 13:55 ` Lars Ingebrigtsen @ 2019-07-29 14:18 ` Drew Adams 0 siblings, 0 replies; 19+ messages in thread From: Drew Adams @ 2019-07-29 14:18 UTC (permalink / raw) To: Lars Ingebrigtsen, Basil L. Contovounesios; +Cc: ndame, 36826 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.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 18:01 ` Lars Ingebrigtsen 2019-07-29 4:00 ` Basil L. Contovounesios @ 2019-07-29 4:28 ` Michael Heerdegen 2019-07-29 4:38 ` ndame 2019-07-29 4:46 ` Drew Adams 2022-04-17 17:00 ` Lars Ingebrigtsen 2 siblings, 2 replies; 19+ messages in thread From: Michael Heerdegen @ 2019-07-29 4:28 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: ndame, 36826 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:28 ` Michael Heerdegen @ 2019-07-29 4:38 ` ndame 2019-07-29 14:22 ` Eli Zaretskii 2019-07-30 0:59 ` Michael Heerdegen 2019-07-29 4:46 ` Drew Adams 1 sibling, 2 replies; 19+ messages in thread From: ndame @ 2019-07-29 4:38 UTC (permalink / raw) To: Lars Ingebrigtsen, Michael Heerdegen; +Cc: 36826@debbugs.gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:38 ` ndame @ 2019-07-29 14:22 ` Eli Zaretskii 2019-07-30 0:59 ` Michael Heerdegen 1 sibling, 0 replies; 19+ messages in thread From: Eli Zaretskii @ 2019-07-29 14:22 UTC (permalink / raw) To: ndame; +Cc: michael_heerdegen, larsi, 36826 > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:38 ` ndame 2019-07-29 14:22 ` Eli Zaretskii @ 2019-07-30 0:59 ` Michael Heerdegen 2019-07-30 2:43 ` Drew Adams 1 sibling, 1 reply; 19+ messages in thread From: Michael Heerdegen @ 2019-07-30 0:59 UTC (permalink / raw) To: ndame; +Cc: Lars Ingebrigtsen, 36826@debbugs.gnu.org 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-30 0:59 ` Michael Heerdegen @ 2019-07-30 2:43 ` Drew Adams 2019-07-30 4:02 ` Michael Heerdegen 0 siblings, 1 reply; 19+ messages in thread From: Drew Adams @ 2019-07-30 2:43 UTC (permalink / raw) To: Michael Heerdegen, ndame; +Cc: Lars Ingebrigtsen, 36826 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'.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-30 2:43 ` Drew Adams @ 2019-07-30 4:02 ` Michael Heerdegen 2019-07-30 18:53 ` Drew Adams 0 siblings, 1 reply; 19+ messages in thread From: Michael Heerdegen @ 2019-07-30 4:02 UTC (permalink / raw) To: Drew Adams; +Cc: Lars Ingebrigtsen, ndame, 36826 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-30 4:02 ` Michael Heerdegen @ 2019-07-30 18:53 ` Drew Adams 2019-07-30 21:32 ` Michael Heerdegen 0 siblings, 1 reply; 19+ messages in thread From: Drew Adams @ 2019-07-30 18:53 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Lars Ingebrigtsen, ndame, 36826 > > (`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.) ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-30 18:53 ` Drew Adams @ 2019-07-30 21:32 ` Michael Heerdegen 0 siblings, 0 replies; 19+ messages in thread From: Michael Heerdegen @ 2019-07-30 21:32 UTC (permalink / raw) To: Drew Adams; +Cc: Lars Ingebrigtsen, ndame, 36826 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-29 4:28 ` Michael Heerdegen 2019-07-29 4:38 ` ndame @ 2019-07-29 4:46 ` Drew Adams 1 sibling, 0 replies; 19+ messages in thread From: Drew Adams @ 2019-07-29 4:46 UTC (permalink / raw) To: Michael Heerdegen, Lars Ingebrigtsen; +Cc: ndame, 36826 > > 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer 2019-07-28 18:01 ` Lars Ingebrigtsen 2019-07-29 4:00 ` Basil L. Contovounesios 2019-07-29 4:28 ` Michael Heerdegen @ 2022-04-17 17:00 ` Lars Ingebrigtsen 2 siblings, 0 replies; 19+ messages in thread From: Lars Ingebrigtsen @ 2022-04-17 17:00 UTC (permalink / raw) To: ndame; +Cc: 36826 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2022-04-17 17:00 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-07-28 6:08 bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer ndame 2019-07-28 16:51 ` Drew Adams 2019-07-28 17:53 ` ndame 2019-07-28 18:01 ` Lars Ingebrigtsen 2019-07-29 4:00 ` Basil L. Contovounesios 2019-07-29 4:35 ` Drew Adams 2019-07-29 18:15 ` Juri Linkov 2019-07-29 13:55 ` Lars Ingebrigtsen 2019-07-29 14:18 ` Drew Adams 2019-07-29 4:28 ` Michael Heerdegen 2019-07-29 4:38 ` ndame 2019-07-29 14:22 ` Eli Zaretskii 2019-07-30 0:59 ` Michael Heerdegen 2019-07-30 2:43 ` Drew Adams 2019-07-30 4:02 ` Michael Heerdegen 2019-07-30 18:53 ` Drew Adams 2019-07-30 21:32 ` Michael Heerdegen 2019-07-29 4:46 ` Drew Adams 2022-04-17 17:00 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).