An easier way to edit variables

An easier way to edit variables

[Tom]

The other day I was browsing info and I saw a variable there. I
wanted to check its value and possibly modify it, so I did a C-h
v and then copied it into the M-: prompt for modification. It
occured to me it could be done more conveniently if info had a
key to show/edit the variable under point.

A while ago I had an idea about modifying a variable directly in
the Help buffer:

http://thread.gmane.org/gmane.emacs.devel/168042

I don't know if somebody tried implementing the above idea, but
if it gets implemented then the two features could easily be
combined: when in info and reading about a variable I could
press, say, 'v' on it which would bring up the Help window of
describe-variable where I could immediately see the current value
of the variable and I could even modify it in place if I wanted
to.

Re: An easier way to edit variables

[Ted Zlatanov]

On Tue, 13 Jan 2015 20:16:53 +0000 (UTC) Tom <adatgyujto@gmail.com> wrote: 

T> A while ago I had an idea about modifying a variable directly in
T> the Help buffer:

T> http://thread.gmane.org/gmane.emacs.devel/168042

T> I don't know if somebody tried implementing the above idea, but
T> if it gets implemented then the two features could easily be
T> combined: when in info and reading about a variable I could
T> press, say, 'v' on it which would bring up the Help window of
T> describe-variable where I could immediately see the current value
T> of the variable and I could even modify it in place if I wanted
T> to.

I think the `v' info popup would be good regardless of the rest.

The `describe-variable' popup already has a link to the customization
interface but the in-place-editing would be really nice.  Perhaps it
could be implemented as an accordion-style interface (like in
`customize-group') so it's hidden by default, yet you don't need to hit
a link and go to a different buffer to use it.

Ted

Re: An easier way to edit variables

[Tom]

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> 
> The `describe-variable' popup already has a link to the customization
> interface but the in-place-editing would be really nice.  Perhaps it
> could be implemented as an accordion-style interface (like in
> `customize-group') so it's hidden by default, yet you don't need to hit
> a link and go to a different buffer to use it.
> 

It should work for all variables, of course, not just for 
customizable variables.

In the above linked thread there was a discussion about the 
possible implementation and it was quite simple.

I think it was pressing e for edit in the Help buffer, then
the buffer is narrowed to the variable value only (which can be a 
complex list or anything) which you can modify in place and
then press C-c C-c to apply it to the variable and exit
edit mode.

Re: An easier way to edit variables

[Tom]

Tom <adatgyujto <at> gmail.com> writes:
> 
> I think it was pressing e for edit in the Help buffer, then
> the buffer is narrowed to the variable value only (which can be a 
> complex list or anything) which you can modify in place and
> then press C-c C-c to apply it to the variable and exit
> edit mode.
> 

BTW, I should add that when I wrote "easier" in the subject I 
meant easier for Lisp hackers who change Lisp variables on
a daily basis.

That's why a quick edit feature in the Help buffer is useful, because
you already see the value there, so if it's complex list
(e.g. a font lock setting or anything) then you don't have to
copy it etc, if you just want to change one thing in it,
you just press e, you get the lisp value, you edit it,
press C-c C-c and it is applied instantly.

Re: An easier way to edit variables

[João Távora]

Tom <adatgyujto@gmail.com> writes:

> Tom <adatgyujto <at> gmail.com> writes:
>> 
>> I think it was pressing e for edit in the Help buffer, then
>> the buffer is narrowed to the variable value only (which can be a 
>> complex list or anything) which you can modify in place and
>> then press C-c C-c to apply it to the variable and exit
>> edit mode.
>> 
>
> BTW, I should add that when I wrote "easier" in the subject I 
> meant easier for Lisp hackers who change Lisp variables on
> a daily basis.
>
> That's why a quick edit feature in the Help buffer is useful, because
> you already see the value there, so if it's complex list
> (e.g. a font lock setting or anything) then you don't have to
> copy it etc, if you just want to change one thing in it,
> you just press e, you get the lisp value, you edit it,
> press C-c C-c and it is applied instantly.

I still find this idea very good. Some time ago, I presented a quick
hack for this in

   https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01053.html

You made some comments, but the discussion died or something.

Here's a not-so-quick hack that addresses those concerns. It emulates
widgets in the *Help* buffer and you edit the variable's value in
place. Should support buffer-local vars but I didn't test much. Also no
"eval" is used, the form is just read back much like it was printed.

It's still a bit broken in, bringing the field to 0-length breaks
it. Should use an overlay. And maybe use "proper" widgets? Probably
broken in more ways I didn't see.

Still, can anyone test it and give me some feedback? The diff is against
emacs-24.4 sorry, I'm on windows and no git clone. 

João

*** z:/Vendor/emacs-w64-24.4/share/emacs/24.4/lisp/help-fns.el.gz
--- z:/Vendor/emacs-24.4/share/emacs/24.4/lisp/help-fns.el
***************
*** 610,615 ****
--- 610,686 ----
  			    version package))))))
      output))
  
+ (defun help--editable-find-near-point (&optional pos)
+   (let* ((pos (or pos (point)))
+          (field-pos
+           (if (eq 'help--editable-field (car (field-at-pos pos)))
+               pos
+             (let ((p (point-min)))
+               (while (and (setq p (next-single-property-change p 'field))
+                           (not (eq 'help--editable-field (car (field-at-pos p))))))
+               p))))
+     (or field-pos
+         (error "No editable field found"))))
+ 
+ (defun help-edit-editable-field (field-pos)
+   (interactive (list (help--editable-find-near-point)))
+   (read-only-mode -1)
+   (let ((start (field-beginning field-pos))
+         (end (field-end field-pos)))
+     (add-text-properties
+      (point-min) start
+      '(rear-nonsticky (read-only) read-only t))
+     (put-text-property end (point-max) 'read-only t)
+     (add-text-properties
+      start end
+      `(local-map ,help--editing-field-keymap
+                  face widget-field
+                  font-lock-face 'widget-field
+                  front-sticky (face font-lock-face field local-map)))))
+ 
+ (defun help-commit-editable-field (field-pos)
+   (interactive (list (help--editable-find-near-point)))
+   (let* ((field (field-at-pos field-pos))
+          (string (field-string-no-properties field-pos))
+          (read (car (read-from-string string)))
+          (variable (cdr (assoc 'variable (cdr field))))
+          (locus (cdr (assoc 'locus (cdr field)))))
+     (cond ((bufferp locus)
+            (with-current-buffer locus
+              (set (make-local-variable variable) read)))
+           (t
+            (set-default variable read)))
+     (help-quit-editable-field field-pos)))
+ 
+ (defun help-quit-editable-field (_field-pose)
+   (interactive (help--editable-field-interactive))
+   ;; TODO: a better implementation might be to restore the text
+   ;; properties and the text according to the
+   ;; `original-representation' prop. But this is safer for now.
+   (revert-buffer nil t))
+ 
+ (defvar help--editable-field-keymap
+   (let ((map (make-sparse-keymap)))
+     (define-key map (kbd "v") 'help-edit-editable-field)
+     map))
+ 
+ (defvar help--editing-field-keymap
+   (let ((map (make-sparse-keymap)))
+     (define-key map (kbd "C-c C-c") 'help-commit-editable-field)
+     (define-key map (kbd "C-c C-q") 'help-quit-editable-field)
+     map))
+ 
+ (defun help--insert-editable-field (variable
+                                     representation
+                                     &optional locus)
+   (insert (propertize
+            representation
+            'field `(help--editable-field
+                     . ((original-representation . ,representation)
+                        (variable                . ,variable)
+                        (locus                   . ,locus)))
+            'keymap help--editable-field-keymap)))
+ 
  ;;;###autoload
  (defun describe-variable (variable &optional buffer frame)
    "Display the full documentation of VARIABLE (a symbol).
***************
*** 684,692 ****
  		       (let ((print-quoted t))
  			 (prin1-to-string val))))
  		  (if (< (+ (length print-rep) (point) (- line-beg)) 68)
! 		      (insert print-rep)
  		    (terpri)
! 		    (pp val)
  		    (if (< (point) (+ 68 (line-beginning-position 0)))
  			(delete-region from (1+ from))
  		      (delete-region (1- from) from)))
--- 755,765 ----
  		       (let ((print-quoted t))
  			 (prin1-to-string val))))
  		  (if (< (+ (length print-rep) (point) (- line-beg)) 68)
!                       (help--insert-editable-field variable
!                                                    print-rep
!                                                    locus)
  		    (terpri)
! 		    (help--insert-editable-field variable (pp-to-string val) locus)
  		    (if (< (point) (+ 68 (line-beginning-position 0)))
  			(delete-region from (1+ from))
  		      (delete-region (1- from) from)))
***************
*** 728,734 ****
  		      ;; probably print it raw once and check it's a
  		      ;; sensible size before prettyprinting.  -- fx
  		      (let ((from (point)))
! 			(pp global-val)
  			;; See previous comment for this function.
  			;; (help-xref-on-pp from (point))
  			(if (< (point) (+ from 20))
--- 801,807 ----
  		      ;; probably print it raw once and check it's a
  		      ;; sensible size before prettyprinting.  -- fx
  		      (let ((from (point)))
!                         (help--insert-editable-field variable (pp-to-string global-val))
  			;; See previous comment for this function.
  			;; (help-xref-on-pp from (point))
  			(if (< (point) (+ from 20))

Re: An easier way to edit variables

[Ted Zlatanov]

On Tue, 13 Jan 2015 21:53:52 +0000 (UTC) Tom <adatgyujto@gmail.com> wrote: 

T> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> 
>> The `describe-variable' popup already has a link to the customization
>> interface but the in-place-editing would be really nice.  Perhaps it
>> could be implemented as an accordion-style interface (like in
>> `customize-group') so it's hidden by default, yet you don't need to hit
>> a link and go to a different buffer to use it.
>> 

T> It should work for all variables, of course, not just for 
T> customizable variables.

Perhaps, but I think it's significantly less useful to users if you just
drop them into a "enter a Lisp form" interface.  It could actually be
harmful and lose their data.

T> I think it was pressing e for edit in the Help buffer, then
T> the buffer is narrowed to the variable value only (which can be a 
T> complex list or anything) which you can modify in place and
T> then press C-c C-c to apply it to the variable and exit
T> edit mode.
...
T> That's why a quick edit feature in the Help buffer is useful, because
T> you already see the value there, so if it's complex list
T> (e.g. a font lock setting or anything) then you don't have to
T> copy it etc, if you just want to change one thing in it,
T> you just press e, you get the lisp value, you edit it,
T> press C-c C-c and it is applied instantly.

You'd need good custom editors for strings, lists, alists, plists... and
a guess on which one to use... and lots of luck :)  IMHO it's better to
try to write customization tools that all users can use, and link to
those.

T> BTW, I should add that when I wrote "easier" in the subject I 
T> meant easier for Lisp hackers who change Lisp variables on
T> a daily basis.

I really think those guys are in the minority and already know about
`setq` and `M-:` and so on. If you're targeting them specifically, it's
not as useful as I thought.

Ted

Re: An easier way to edit variables

[João Távora]

Ted Zlatanov <tzz@lifelogs.com> writes:

> T> It should work for all variables, of course, not just for 
> T> customizable variables.
>
> Perhaps, but I think it's significantly less useful to users if you just
> drop them into a "enter a Lisp form" interface.  It could actually be
> harmful and lose their data.

Well, M-x customize can also "lose your data". I see your point, but
this is the point of the feature: change *any variable*, including
"dangerous" variables hidden from the user. Isn't that "disabled command
because new users find it confusing" feature used anymore?

> You'd need good custom editors for strings, lists, alists, plists... and
> a guess on which one to use... and lots of luck :)  IMHO it's better to
> try to write customization tools that all users can use, and link to
> those.

Why? Assume the user knows Lisp and use form, and pass it to READ.
Did you try my prototype?

> I really think those guys are in the minority and already know about
> `setq` and `M-:` and so on. If you're targeting them specifically, it's
> not as useful as I thought.

I've known about this, well, since the beginning, and of course I do use
it. But it still sucks to have to use

  M-:
  (setq find-the-variables-name-again )
  Multiple C-x o to go to the *Help* window.
  Scroll around until I find the form that I want to change.
  Copy that to the kill ring
  More C-x o
  Yank it to the minibuffer
  Remember to quote it, almost always

Perhaps I can cut down on some of these steps, but still, what Tom
proposes is way nicer.

Re: an easier way to edit variables

[Ivan Shmakov]

>>>>> João Távora <joaotavora@gmail.com> writes:

[…]

 > M-: (setq find-the-variables-name-again )
 > Multiple C-x o to go to the *Help* window.
 > Scroll around until I find the form that I want to change.
 > Copy that to the kill ring.

	Actually, I think it’d be nice to have /both/ a key binding for
	the above (say, ‘E’) /and/ a separate key binding (say, ‘e’) to
	call customize-variable, – if the variable is indeed declared
	customizable.  The code for the latter would probably be just a
	few lines long, and the formed could use something like:

(let ((eval-expression-minibuffer-setup-hook
       (cons (lambda ()
               (insert (format "(setq %S %S)"
                               variable-name
                               ;; FIXME: double-check the following
                               (if (consp variable-value)
                                   (list 'quote variable-value)
                                 variable-value))))
             eval-expression-minibuffer-setup-hook)))
  (call-interactively 'eval-expression))

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: An easier way to edit variables

[Tom]

Ted Zlatanov <tzz <at> lifelogs.com> writes:
> 
> Perhaps, but I think it's significantly less useful to users if you just
> drop them into a "enter a Lisp form" interface.  It could actually be
> harmful and lose their data.

Users already have customize. Just a put a customize button 
into the Help buffer for those variables which are customizable
and users can click on that.

The in place lisp editing is useful for advanced users. Why not help
them if it's not hard to implement?

> I really think those guys are in the minority and already know about
> `setq` and `M-:` and so on. If you're targeting them specifically, it's
> not as useful as I thought.

Yes, I also know about these, but still if I want to change the
value of some variable then I have to copy its name and value into
scratch the change and evaluate it there, etc.

It would be much more convenient to simply press 'e', edit the value in 
place and apply it. 

But there can be a 'c' customize binding too if somebody prefers
that.

Re: An easier way to edit variables

[Tom]

João Távora <joaotavora <at> gmail.com> writes:

> 
> Still, can anyone test it and give me some feedback? The diff is against
> emacs-24.4 sorry, I'm on windows and no git clone. 

I did a quick test.

I tried it on auto-mode-alist as an example for a sufficiently
complex variable, changed one character in it and it seemed to work
well.

Also tried a simple variable (history-length) and it worked correctly.


BTW, why bind the key to the widget? It should be bound in the
buffer, so I can press it anywhere and it jumps
to the edit field. (And I'd use the binding e for edit. It's more
mnemonic than v, the function is also called edit.)

Re: An easier way to edit variables

[Yuri Khan]

On Wed, Jan 14, 2015 at 10:09 PM, Tom <adatgyujto@gmail.com> wrote:

> Yes, I also know about these, but still if I want to change the
> value of some variable then I have to copy its name and value into
> scratch the change and evaluate it there, etc.
>
> It would be much more convenient to simply press 'e', edit the value in
> place and apply it.

It might be even more convenient if pressing the key prepared a nicely
formatted (setq VARIABLE-NAME CURRENT-VALUE) form and presented *that*
in a lisp-interaction-mode buffer. Then it could be edited and
evaluated right there, and/or copy-pasted into an .emacs.d/init.el.

Re: An easier way to edit variables

[Tom]

Yuri Khan <yuri.v.khan <at> gmail.com> writes:
> 
> It might be even more convenient if pressing the key prepared a nicely
> formatted (setq VARIABLE-NAME CURRENT-VALUE) form and presented *that*
> in a lisp-interaction-mode buffer. Then it could be edited and
> evaluated right there, and/or copy-pasted into an .emacs.d/init.el.
> 

The advantage of in place editing is that you can also see the
documentation which can be useful for more complicated variables.
Of course, you could copy the doc too to the interaction buffer,
but it would be like duplicating the Help buffer.

But I also see that in some situations your version could be useful,
so why not provide both? E.g. press e for in place editing and E 
(S-e) for seeing the whole setq expression in a seperate buffer.

Re: An easier way to edit variables

[Ted Zlatanov]

On Wed, 14 Jan 2015 16:09:10 +0000 (UTC) Tom <adatgyujto@gmail.com> wrote: 

T> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> 
>> Perhaps, but I think it's significantly less useful to users if you just
>> drop them into a "enter a Lisp form" interface.  It could actually be
>> harmful and lose their data.

T> Users already have customize. Just a put a customize button 
T> into the Help buffer for those variables which are customizable
T> and users can click on that.

I suggested that, hidden by an accordion-style interface so it doesn't
take up space unnecessarily. Would you consider adding that to your
patch?

T> The in place lisp editing is useful for advanced users. Why not help
T> them if it's not hard to implement?

I didn't say it's not nice and convenient, just that it's not as useful
as I thought because you're talking about in-place editing of arbitrary
Lisp code.  It serves a smaller audience.  See below for some
suggestions, but please don't consider me opposed even to a rudimentary
implementation as long as it's something better than the current state.

Regarding your current UI proposal, I think hitting a special key is a
barrier for users. At least for the Customize link, the UI should be in
the help buffer. Joe New User should be able to say `C-h v
the-variable-name' and start customizing it right away, not learn new
keystrokes and click on links.

On Wed, 14 Jan 2015 23:56:34 +0700 Yuri Khan <yuri.v.khan@gmail.com> wrote: 

YK> On Wed, Jan 14, 2015 at 10:09 PM, Tom <adatgyujto@gmail.com> wrote:

>> Yes, I also know about these, but still if I want to change the
>> value of some variable then I have to copy its name and value into
>> scratch the change and evaluate it there, etc.
>> 
>> It would be much more convenient to simply press 'e', edit the value in
>> place and apply it.

YK> It might be even more convenient if pressing the key prepared a nicely
YK> formatted (setq VARIABLE-NAME CURRENT-VALUE) form and presented *that*
YK> in a lisp-interaction-mode buffer. Then it could be edited and
YK> evaluated right there, and/or copy-pasted into an .emacs.d/init.el.

I'd find that better than trying to edit a Lisp form directly.  The
problem with the form is that it can get very complex, and you need the
tools that go with Emacs Lisp editing in a `lisp-mode' buffer
(font-lock, navigation, plus the countless customizations power users
do).  So if that can be done, I'm 100% in favor.  If not, I'm not
against it, just not excited by it :)

(I also wonder if the above UI wouldn't be nice as an addition to
Customize itself. I often play with the widgets but want to see the
result as a Lisp form quickly, jumping back and forth. We have the menu
item "show saved state as a Lisp expression" but that shows the *saved*
data and not in `lisp-mode'.)

Ted