bug#62106: 29.0.60; Emacs 29 changing user option values (?)

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Drew Adams]

Apologies for an incomplete bug report.  Feel free to close if not
helpful.

I downloaded the Windows binary posted today, with dependencies
included, and gave it a naive try using my setup.  Naturally I ran into
some problems.  But when I went to exit, my `kill-emacs-query-functions'
code that checks for changes to user option values (using function
`customize-unsaved') let me know that something had changed these option
values (I had not changed them):

connection-local-criteria-alist

Its value is

(((:application tramp)
  tramp-connection-local-default-system-profile tramp-connection-local-default-shell-profile))

Original value was nil


connection-local-profile-alist

The value is a long, complex Tramp alist.  Original value was nil.

So it looks like Tramp (?) might be messing with user-ooption values,
without resetting their state to tell Customize that they haven't been
changed since last saved.  This should be a no-no.

HTH.


In GNU Emacs 29.0.60 (build 1, x86_64-w64-mingw32)
 of 2023-03-10
Repository revision: 6fe9075ff3814ce825c9869c901903edad9d0b44
Windowing system distributor `Microsoft Corp.', version 10.0.19044
Configured using:
 `configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install --with-tree-sitter CFLAGS=-O2'

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Corwin Brust]

On Fri, Mar 10, 2023 at 4:16 PM Drew Adams <drew.adams@oracle.com> wrote:
>
> I downloaded the Windows binary posted today, with dependencies

I can't comment on the bug you are reporting but..
..thank you for trying out the new Windows binaries and reporting what
you see, Drew!

Corwin

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> Apologies for an incomplete bug report.  Feel free to close if not
> helpful.
>
> I downloaded the Windows binary posted today, with dependencies
> included, and gave it a naive try using my setup.  Naturally I ran into
> some problems.  But when I went to exit, my `kill-emacs-query-functions'
> code that checks for changes to user option values (using function
> `customize-unsaved') let me know that something had changed these option
> values (I had not changed them):
>
> connection-local-criteria-alist
>
> Its value is
>
> (((:application tramp)
>   tramp-connection-local-default-system-profile tramp-connection-local-default-shell-profile))
>
> Original value was nil
>
>
> connection-local-profile-alist
>
> The value is a long, complex Tramp alist.  Original value was nil.
>
> So it looks like Tramp (?) might be messing with user-ooption values,
> without resetting their state to tell Customize that they haven't been
> changed since last saved.  This should be a no-no.

Let's CC Michael (I mean, the other one).  He changed that in
6058d3ebb41 - Respect customization nature of `connection-local-*' user
options.

Dunno what the intention was - could we use `setopt' here?


Michael.

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Michael Albinus]

Version: 29.1

Michael Heerdegen <michael_heerdegen@web.de> writes:

Hi,

>> I downloaded the Windows binary posted today, with dependencies
>> included, and gave it a naive try using my setup.  Naturally I ran into
>> some problems.  But when I went to exit, my `kill-emacs-query-functions'
>> code that checks for changes to user option values (using function
>> `customize-unsaved') let me know that something had changed these option
>> values (I had not changed them):
>>
>> connection-local-criteria-alist
>>
>> Its value is
>>
>> (((:application tramp)
>>   tramp-connection-local-default-system-profile tramp-connection-local-default-shell-profile))
>>
>> Original value was nil
>>
>>
>> connection-local-profile-alist
>>
>> The value is a long, complex Tramp alist.  Original value was nil.
>>
>> So it looks like Tramp (?) might be messing with user-ooption values,
>> without resetting their state to tell Customize that they haven't been
>> changed since last saved.  This should be a no-no.
>
> Let's CC Michael (I mean, the other one).  He changed that in
> 6058d3ebb41 - Respect customization nature of `connection-local-*' user
> options.
>
> Dunno what the intention was - could we use `setopt' here?

`setopt' does not really help. Using `customize-save-variable' instead
of `customize-set-variable' does the trick.

Pushed to the emacs-29 branch, closing the bug. Pls reply if it doesn't
work as expected.

> Michael.

Best regards, Michael.

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Drew Adams]

> > Dunno what the intention was - could we use `setopt' here?
> 
> `setopt' does not really help. Using `customize-save-variable' instead
> of `customize-set-variable' does the trick.
> 
> Pushed to the emacs-29 branch, closing the bug. Pls reply if it doesn't
> work as expected.

Thanks for working on this.  Without studying this at all, I'm guessing that `customize-save-variable' is the wrong thing to do.  Doesn't that mean that you're not only changing a user-option value, but you're also doing so permanently (persistently)?  If so, isn't that even _worse_?

Wouldn't this be better - pseudo-saving, i.e., making Customize treat a changed option as if it were unchanged, _without_ saving it?

(put SYMBOL 'saved-value
            (list (custom-quote (default-value SYMBOL)))))
_________

FWIW, I define these functions (commands), based on that.

;; Use this one anywhere.
;;
(defun customize-consider-all-vars-unchanged ()
  "Consider all customizable variables as saved, without saving them."
  (interactive)
  (when (interactive-p) (message "Please wait..."))
  (mapatoms
   (lambda (symbol)
     (when (and (or (custom-variable-p symbol)
                    (user-variable-p symbol))
                (default-boundp symbol) ; Value neither saved nor standard.
                (not (member (list (custom-quote (default-value symbol)))
                             (list (get symbol 'saved-value)
                                   (get symbol 'standard-value)))))
       ;; Pretend the current value has been saved.
       (put symbol 'saved-value (list (custom-quote (default-value symbol)))))
     (put symbol 'customized-value nil)
     (when (get symbol 'customized-variable-comment)
       (put symbol 'saved-variable-comment
                   (get symbol 'customized-variable-comment)))
     (put symbol 'customized-variable-comment nil)))
  (message "All variables are now considered unchanged (\"saved\"),\
 but they were not saved."))

________________

;; Use this in the Customize UI.
;;
(defun Custom-consider-unchanged (&rest _IGNORED)
  "Consider all preferences here as being unchanged now.
This does not save the current values; it just considers them to be
unchanged values.  If no further changes are made to any of these
preferences, then after doing this, `customize-customize' will not
display any of these preferences, since they were considered
unchanged."
  (interactive)
  (if (not (y-or-n-p "All of these values will be considered \
unchanged now, without being saved.  Continue? "))
      (message nil)
    (message "Please wait...")
    (let ((children  custom-options))
      (dolist (child  children)
        (let ((symbol  (widget-get-tag-or-value child)))
          (cond ((custom-facep symbol)
                 (custom-consider-face-unchanged child))
                ((custom-variable-p symbol)
                 (custom-consider-variable-unchanged child))))))
    (message "Current values here are now considered unchanged.\
  They were not saved.")))

;; Inspired from `custom-variable-save'.
;; Due to a `cus-edit.el' bug (hidden widgets are not saved), we need to temporarily
;; show hidden widgets.
;;
;; Should we (put symbol 'saved-value...) only if not
;; (eq (widget-get widget :custom-state) 'standard), as in `custom-face-save'?
;;
(defun custom-consider-variable-unchanged (widget)
  "Consider this variable as being unchanged now.
This does not save the current value; it just considers the value to
be unchanged.  If no further changes are made to this variable, then
after doing this, `customize-customize' will not display this
variable, since it was considered unchanged."
  (message "Please wait...")
  (let ((form      (widget-get widget :custom-form))
        (hidden-p  (eq (widget-get widget :custom-state) 'hidden)))
    (when hidden-p                      ; Show it.
      (widget-put widget :custom-state 'unknown)
      (custom-redraw widget)
      (setq form  (widget-get widget :custom-form)))
    (let ((child   (car (widget-get widget :children)))
          (symbol  (widget-value widget)))
      (cond ((memq form '(lisp mismatch))
             (put symbol 'saved-value (list (widget-value child))))
            (t (put symbol 'saved-value
                           (list (custom-quote (widget-value child))))))
      (put symbol 'customized-value nil)
      (put symbol 'customized-variable-comment nil))
    (widget-put widget :custom-state 'saved)
    (when hidden-p                      ; Hide it again.
      (widget-put widget :documentation-shown nil)
      (widget-put widget :custom-state 'hidden)
      (custom-redraw widget)))
  (custom-redraw-magic widget)
  (message "Current variable value is now considered unchanged.\
  It was not saved."))
_______

https://www.emacswiki.org/emacs/download/cus-edit%2b.el

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Augusto Stoffel]

On Sat, 11 Mar 2023 at 17:34, Michael Albinus wrote:

> `setopt' does not really help. Using `customize-save-variable' instead
> of `customize-set-variable' does the trick.

This seems like something that would be better handled via
multisession.el, no?  I think that library should really be made an ELPA
package (possibly without the SQLite stuff), cf. bug#59995.

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi Drew,

>> `setopt' does not really help. Using `customize-save-variable' instead
>> of `customize-set-variable' does the trick.
>>
>> Pushed to the emacs-29 branch, closing the bug. Pls reply if it doesn't
>> work as expected.
>
> Thanks for working on this.  Without studying this at all, I'm
> guessing that `customize-save-variable' is the wrong thing to do.
> Doesn't that mean that you're not only changing a user-option value,
> but you're also doing so permanently (persistently)?  If so, isn't
> that even _worse_?

Oops, that's true.

> Wouldn't this be better - pseudo-saving, i.e., making Customize treat a changed option as if it were unchanged, _without_ saving it?
>
> (put SYMBOL 'saved-value
>             (list (custom-quote (default-value SYMBOL)))))

I've tested further, and it looks like `custom-set-variables' does
already what we want. So I've modifed my change in the emacs-29 branch
accordingly.

It would be great if you could counter test once the recent emacs-29
branch is on your laptop.

Best regards, Michael.

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Drew Adams]

> > Wouldn't this be better - pseudo-saving, i.e., making Customize treat
> > a changed option as if it were unchanged, _without_ saving it?
> >
> > (put SYMBOL 'saved-value
> >             (list (custom-quote (default-value SYMBOL)))))
> 
> I've tested further, and it looks like `custom-set-variables' does
> already what we want. So I've modifed my change in the emacs-29 branch
> accordingly.

Yes, I think that'll do it.  Thx.

> It would be great if you could counter test once the recent emacs-29
> branch is on your laptop.

No idea when that might happen, and I'll likely have
forgotten about this bug by then. ;-)  I depend on
MS Windows snapshots for builds.  I think things are
probably good now.  Thx.

bug#62106: 29.0.60; Emacs 29 changing user option values (?)

[Michael Albinus]

Drew Adams <drew.adams@oracle.com> writes:

Hi Drew,

>> It would be great if you could counter test once the recent emacs-29
>> branch is on your laptop.
>
> No idea when that might happen, and I'll likely have
> forgotten about this bug by then. ;-)  I depend on
> MS Windows snapshots for builds.  I think things are
> probably good now.  Thx.

There's no rush. The bug is closed, and like you I'll forget it,
soon. You only need to holler when it doesn't work for you as expected.

Best regards, Michael.