all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ndame <emacsuser@freemail.hu>
To: Lars Ingebrigtsen <larsi@gnus.org>,
	Michael Heerdegen <michael_heerdegen@web.de>
Cc: "36826@debbugs.gnu.org" <36826@debbugs.gnu.org>
Subject: bug#36826: 26.1; request: add variable value editing feature to the *Help* buffer
Date: Mon, 29 Jul 2019 04:38:25 +0000 (GMT)	[thread overview]
Message-ID: <Axuu0g.HkCXWWtfWbR.MB54p8XYTOQqsLkRnbS@freemail.hu> (raw)
In-Reply-To: <87a7cx4g7f.fsf@web.de>

[-- 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 --]

  reply	other threads:[~2019-07-29  4:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Axuu0g.HkCXWWtfWbR.MB54p8XYTOQqsLkRnbS@freemail.hu \
    --to=emacsuser@freemail.hu \
    --cc=36826@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.