Stephen Berman writes: > On Sun, 04 Aug 2024 10:49:52 +0300 Eli Zaretskii wrote: > >>> From: Stephen Berman >>> Cc: john muhl , juri@linkov.net,  maurooaranda@gmail.com, >>>   72404@debbugs.gnu.org >>> Date: Thu, 01 Aug 2024 19:28:04 +0200 >>> >>> On Thu, 01 Aug 2024 12:12:52 +0200 Stephen Berman wrote: >>> >>> I did happen to have a bit more time for this problem, and I think I've >>> found the cause, a single line in commit 8d354925ddb: >>> >>> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el >>> index 693991a6f3e..aa653549dad 100644 >>> --- a/lisp/wid-edit.el >>> +++ b/lisp/wid-edit.el >>> @@ -2549,7 +2549,8 @@ widget-checklist-add-item >>>                  (t >>>                   (widget-create-child-value >>>                    widget type (car (cdr chosen))) >>> - (widget-specify-selected child))))) >>> +                             ;; (widget-specify-selected child) >>> +                             )))) >>>             (t >>>          (error "Unknown escape `%c'" escape))))) >>>       ;; Update properties. >>> >>> With this line commented out as in the above patch, I get the expected >>> value when carrying out Juri's recipe.  Moreover, after making that >>> change, I then briefly tested customizing the face widget-unselected >>> (which the problematic commit added) to inherit from the default face >>> and it shows the labels of unselected check boxes in the default face, >>> as it should.  So maybe deleting the commented out line above and >>> leaving the rest of the change is a sufficient fix.  But I have to admit >>> I don't know why that line causes the problem, and I haven't done enough >>> testing of this change to the widget-unselected face feature, so this is >>> just a status report. >> >> Thanks, I installed the above fix. > > Thanks, this seems at least a plausible stopgap. > >> It turns out the same problem also caused bug#72156, so I've now >> merged them. >> >> I'm leaving this bug open, in the hope that you or someone else will >> find the root cause for the regression and fix it. > > I will try to debug it further, but I do hope Mauro or someone else more > familiar with the widget and custom code than I am will look into it. > > Steve Berman Looks to me that it's a matter of order of function calls.  The return value of widget-create-child-value was used for setting child. I found this by using widget-browse-at at the checkbox.  I navigated to the checkbox parent, the set widget, and saw that only the unselected children were specified as children of the set widget. The attached patch should fix it.