From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: ndame Newsgroups: gmane.emacs.bugs 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) Message-ID: References: <87a7cx4g7f.fsf@web.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10080_96023940.1564375105246" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88520"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "36826@debbugs.gnu.org" <36826@debbugs.gnu.org> To: Lars Ingebrigtsen , Michael Heerdegen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 29 06:58:10 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hrxje-000Myh-57 for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jul 2019 06:58:10 +0200 Original-Received: from localhost ([::1]:49444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrxjd-0005OV-7J for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Jul 2019 00:58:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38047) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrxjY-0005Mh-F8 for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2019 00:58:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hrxjW-0001bP-HF for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2019 00:58:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38723) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hrxjV-0001ZX-UW for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2019 00:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hrxjV-0008LL-SC for bug-gnu-emacs@gnu.org; Mon, 29 Jul 2019 00:58:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ndame Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Jul 2019 04:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36826 X-GNU-PR-Package: emacs Original-Received: via spool by 36826-submit@debbugs.gnu.org id=B36826.156437626132042 (code B ref 36826); Mon, 29 Jul 2019 04:58:01 +0000 Original-Received: (at 36826) by debbugs.gnu.org; 29 Jul 2019 04:57:41 +0000 Original-Received: from localhost ([127.0.0.1]:47544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrxjA-0008Kk-Iz for submit@debbugs.gnu.org; Mon, 29 Jul 2019 00:57:40 -0400 Original-Received: from fmfe31.onbox.hu ([46.107.16.236]:23646 helo=web-out.onbox.hu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrxj7-0008KU-8w for 36826@debbugs.gnu.org; Mon, 29 Jul 2019 00:57:38 -0400 X-fm-smtp-source: yes Original-Received: from localhost (localhost [94.21.144.65]) by web-out.onbox.hu (Postfix) with SMTP id 45xnVf0QyxzZLG; Mon, 29 Jul 2019 06:57:30 +0200 (CEST) In-Reply-To: <87a7cx4g7f.fsf@web.de> X-AccountId: 57978162 X-Originating-Ip: 94.21.144.65 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrledtgdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdcuhfftgffgofetkffnnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvkfgjfhfugggtihesrgdtregstddtudenucfhrhhomhepnhgurghmvgcuoegvmhgrtghsuhhsvghrsehfrhgvvghmrghilhdrhhhuqeenucfkphepleegrddvuddrudeggedrieehnecurfgrrhgrmhephhgvlhhopedpihhnvghtpeelgedrvddurddugeegrdeihedpmhgrihhlfhhrohhmpegvmhgrtghsuhhsvghrsehfrhgvvghmrghilhdrhhhupdhrtghpthhtoheplhgrrhhsihesghhnuhhsrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/relaxed; t=1564376250; s=20181004; d=freemail.hu; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=4935; bh=iO7dPrcL58e6HBKsXQ/BjfVLwFxY6S+nf1cZjFiTXwo=; b=OeTEWadEN4+0FDTX1QrClDwjM22PR+d0ist3vbL7XlfPeDSvJHDyszTNmnrHlnV5 4SNE5kTyOdU8H+cxJNMX+TYJWObnu7zcKP+JZ7cj8R4mQbR9r1pdz9njNvG4eU4eoVU LDoZwvRBVIYAY2XJklSbIv6fe8bO8n2UzjI9PLQP9nlT+caRH3dD4Xy6F4pIPkl+W+a gI4+zJiS9FOGOW4dU4AVfrKNbQ4GAgIrOo1WM03F0gDHan7PsRqlX6WX8pVS1tSJhnv oAUUaHro0ZiWBdT4sb7vzGbNB4myu8cETiSEG1TWMHjjm/0EXcjbb043pNkpl3y3JtF 6C5NGDvGvA== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:164008 Archived-At: ------=_Part_10080_96023940.1564375105246 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > - 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=C2= =A0 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 situatio= n 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 y= ou=C2=A0 want to tweak a variable. You press c and the lisp form of setting the=C2= =A0 variable (setq varname ....current value...) is copied to the kill ring whi= ch you can tweak in=C2=A0 scratch. This could trivially do the tedious work of copying the variable's name and= =C2=A0 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?=C2=A0 E.g. buffers: they have a print syntax, but it's n= ot 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=C2=A0 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=C2= =A0 are beyond customize, able to use lisp and tweak variables and other things often in emacs. =C2=A0 ------=_Part_10080_96023940.1564375105246 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > - 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.
  ------=_Part_10080_96023940.1564375105246--