Subject: bug#72156: 31.0.50; defcustom set issue

From: Eli Zaretskii <[email-masked]>
Date: Sat, 20 Jul 2024 11:50:47 +0300

> Date: Wed, 17 Jul 2024 14:08:59 +0200
> From:  Ergus via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email-masked]>
> 
> I have this defcustom:
> 
> ```
> (defcustom gtags-mode-features '(control meta)
>   "HELLO WORLD"
>   :type '(set (const control)
>               (const meta)
>               (const shift)
>               (const hyper)
>               (const super)
>               (const alt)))
> ```
> 
> When I try the customize-variable I get this:
> 
> ```
> Hide Gtags Mode Features:
> Set:
> [X] control
> [X] meta
> [ ] shift
> [ ] hyper
> [ ] super
> [ ] alt
>    [ State ]: EDITED, shown value does not take effect until you set or save it.
>    HELLO WORLD
> Groups: [Gtags Mode]
> ```
> 
> But, if I do the next change and save
> 
> 
> ```
> Hide Gtags Mode Features:
> Set:
> [X] control
> [X] meta
> [X] shift
> [ ] hyper
> [ ] super
> [ ] alt
>    [ State ]: EDITED, shown value does not take effect until you set or save it.
>    HELLO WORLD
> Groups: [Gtags Mode]
> ```
> 
> The customize variable value saved is:
> 
> '(gtags-mode-features3 '(shift))
> 
> it only saved the "new" value and ignores the previous
> existing ones.
> 
> When I restart and check the variable's value I get as expected '(shift)
> and lost the control and meta.
> 
> Going to customize-variable again I get:
> 
> ```
> Hide Gtags Mode Features:
> Set:
> [ ] control
> [ ] meta
> [X] shift
> [ ] hyper
> [ ] super
> [ ] alt
>    [ State ]: EDITED, shown value does not take effect until you set or save it.
>    HELLO WORLD
> Groups: [Gtags Mode]
> ```
> 
> Consistent with the variable value, but inconsistent with what was
> actually saved before.
> 
> IF instead of selecting a new value I un-select some, then variable
> saves nil and will be nil.

This seems to be some bug in handling the 'set' type of defcustoms.  I
see the same problem when customizing completions-merging-modes from
completion.el.  Perhaps Mauro (CC'ed) could chime in and suggest how
to solve this.