GNU bug report logs - #44852
[PATCH] Fix modification check when custom-form is 'lisp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44852 in the body.
You can then email your comments to 44852 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Fix modification check when custom-form is 'lisp
Date: Tue, 24 Nov 2020 19:51:38 +0100

[Message part 1 (text/plain, inline)]

When a variable’s custom-form is 'lisp (or 'mismatch),
`custom-variable-value-create' will quote its value prior to storing it
inside the widget.  Afterwards, `custom-variable-modified-p' will try to
compare this quoted form to the (unquoted) value and think that the
variable has been modified.

To reproduce, fire up emacs -Q and do:

  1. (setq custom-variable-default-form 'lisp)
  2. M-x customize-variable RET auto-save-file-name-transforms RET

You will notice that Customize thinks that the variable has been
modified even though that is not true.  If step 1. is omitted,
everything is fine.

The patch attached below fixes that.

[0001-Fix-modification-check-when-custom-form-is-lisp.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Best regards,
Dario

-- 
$ keyserver=hkps://hkps.pool.sks-keyservers.net
$ keyid=744A4F0B4F1C9371
$ gpg --keyserver $keyserver --search-keys $keyid

Message #8 received at 44852 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com>
Cc: 44852 <at> debbugs.gnu.org
Subject: Re: bug#44852: [PATCH] Fix modification check when custom-form is
 'lisp
Date: Thu, 26 Nov 2020 11:59:44 +0100

Dario Gjorgjevski <dario.gjorgjevski <at> gmail.com> writes:

> You will notice that Customize thinks that the variable has been
> modified even though that is not true.  If step 1. is omitted,
> everything is fine.
>
> The patch attached below fixes that.

Thanks; applied to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.