Received: (at 69941) by debbugs.gnu.org; 18 Apr 2024 11:34:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 18 07:34:51 2024 Received: from localhost ([127.0.0.1]:51885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rxQ2O-00084t-Dy for submit <at> debbugs.gnu.org; Thu, 18 Apr 2024 07:34:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rxQ2F-0007xy-Ck for 69941 <at> debbugs.gnu.org; Thu, 18 Apr 2024 07:34:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rxQ1w-0003Nb-2S; Thu, 18 Apr 2024 07:34:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6gSMNO49Wy91JYXLhuIoCpsxx5tAmn04WKSwwZoaUzo=; b=G7nOYS1CVK5Jx5oZwouJ X7to6/Qu4KcpqlhyO6CcIB+v8FYwJGTXRZ78OXxAp/TLCdLHpdSOTK1Z/d8lNjp3UPdOYsHCFLddl PfMhr5w07xcmK2J32drmwkLKpqhxhkCGQb0GyvAmiwKEF1WMZIQztxdrXw7OBrpcmy72k+SGVEbOW ekfyD46YZuzc3Eeres0V3XTkvL1RUcczvOVqGSERuaPEIQfIHsPI2knPyGiqXwDoy/e6/3Ed7+VAA lqiSPeqdDEhU51W60PNfskNN5D4Zq8uQ5IPbVjUhU204X2TShm62raHrhTIM12w7KY/mmlVPNKNpy mOGDns/T6ZlijQ==; Date: Thu, 18 Apr 2024 14:33:57 +0300 Message-Id: <86h6fyewgq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Mauro Aranda <maurooaranda@HIDDEN> In-Reply-To: <941f6565-203b-47bf-82a9-2bb7b0788b6a@HIDDEN> (message from Mauro Aranda on Thu, 18 Apr 2024 07:18:29 -0300) Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN> <51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN> <87wmprqxj3.fsf@HIDDEN> <8734s5w1mf.fsf@HIDDEN> <941f6565-203b-47bf-82a9-2bb7b0788b6a@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69941 Cc: 69941 <at> debbugs.gnu.org, stephen.berman@HIDDEN, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Thu, 18 Apr 2024 07:18:29 -0300 > Cc: Eli Zaretskii <eliz@HIDDEN>, 69941 <at> debbugs.gnu.org, > Stefan Monnier <monnier@HIDDEN> > From: Mauro Aranda <maurooaranda@HIDDEN> > > > To fix this bug, do you have a preference between this patch for > > widget-specify-inactive and the attached patch for > > widget-default-create? Or do you have a better fix? > > > > Steve Berman > > I don't really have a better fix. I mean, ideally, we'd find the reason > why the setting behaves differently for the radio-button-choice widget, > and only for the first one in a radio widget, as it seems to me. But > I'll need more time to be able to look into that. > > That said, if Eli is OK with installing a minor hack (with a FIXME, > please), I don't have problems. And since it's a hack (and hopefully > temporary), it's better if we keep it at widget-default-create then. My opinion doesn't matter much in this case. If you two agree on a solution, feel free to install it, even if it is not 110% clean. Thanks.
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.Received: (at 69941) by debbugs.gnu.org; 18 Apr 2024 10:19:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 18 06:19:23 2024 Received: from localhost ([127.0.0.1]:51532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rxOrI-0007fb-Ec for submit <at> debbugs.gnu.org; Thu, 18 Apr 2024 06:19:23 -0400 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]:54766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maurooaranda@HIDDEN>) id 1rxOqy-0007cb-LB for 69941 <at> debbugs.gnu.org; Thu, 18 Apr 2024 06:19:07 -0400 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-6ed627829e6so823923b3a.1 for <69941 <at> debbugs.gnu.org>; Thu, 18 Apr 2024 03:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713435513; x=1714040313; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=di0O0Y/jxf1MxlJfQpo5y/d3Uwp9OyL0E9hr5ywyOAQ=; b=PnR/PGoes0jkYaxCY2FFZKismneeAdFOuLhtcZJ4Zg4o7embkvYNV9VnJ/aeVStV8s NBHUkXhiEs7qgE6xO7lr3KnpJjcQVXkA60Sg8hXYJABifL8KYSoHnjfFNAcbQZ4XivsP 8FMzFBhIzithz4vFxmxscJUU5xyoxlGonf4Y58B1nate3os5jXY++vqIzuZSOIrOIy4i m2JH5Bge2sdbA8ahZ0n+RYX9HPkNEgjsDaQtCJVs5u7G2k5QTegmD4QAaHSfGYcauBj5 E/EiMhCpgjOKOfwboDKiAVvXfAxA6SZMtX/ys6pfonKFgKb3MATc2m2b5/g2YG777Z5/ 7fHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713435513; x=1714040313; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=di0O0Y/jxf1MxlJfQpo5y/d3Uwp9OyL0E9hr5ywyOAQ=; b=qBOo0ewD8ZwUnW0fjYcsh9QWBlH2X2dinjOEQ8vWQ73e/FZYLw0b3QvmU5Q1Qn7wrc Nj8g8UQtQIUrMyh4rdUa9WjBfBEX0nRwZUrfaMisfRzPp7EJ7JK+VMvpVwiwqmDoLauv hvxA/AgMM7PSeKVpvV6UxGFYJLITmcedFOWmzv3KAax4BTAsmtXi7VMDVA3hbpqZiZ4L FotbAay/QDBJSV2M9omb2p6h8puq54LwC/buKZmDwt+3oI9nU+fysBhd3zVmxS1/j9Ce o3UgEZYeMML5uB51sCEcVVo0lskKSrLj+LnVHdn6yRx5xVgi1vehie4E8pq+6kCt6LDv KWzQ== X-Forwarded-Encrypted: i=1; AJvYcCVSIF0Sy3x99KFQJVU3lkAIIeEO92ou9m4V3q/FYiDIFM5/mKJ6YUi8uEWR/w8dpIdqND9W+MnKbobXMp911/ex67/cpbM= X-Gm-Message-State: AOJu0YxUHmg8ndShAUvqtRGT3NiQLLZXvsrCn+vV+uvk5imWJOjH5kGW +VhuIuIShqefw8qBgtmF5gQMn3H5MBFhehhYF9bSYDUGMQsBtRAVQQ/8Vw== X-Google-Smtp-Source: AGHT+IHoyw+Sd/eDQuXnSum+fheMYFXNTFRq3jDYqe43SJesRlT5hJnRSH7chhFHQ3XqzYUC4D/vyQ== X-Received: by 2002:a05:6a21:8015:b0:1a9:a32c:f6d6 with SMTP id ou21-20020a056a21801500b001a9a32cf6d6mr2327151pzb.55.1713435512900; Thu, 18 Apr 2024 03:18:32 -0700 (PDT) Received: from [192.168.0.100] ([181.228.33.6]) by smtp.gmail.com with ESMTPSA id u3-20020a631403000000b005bdbe9a597fsm1098165pgl.57.2024.04.18.03.18.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Apr 2024 03:18:32 -0700 (PDT) Message-ID: <941f6565-203b-47bf-82a9-2bb7b0788b6a@HIDDEN> Date: Thu, 18 Apr 2024 07:18:29 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets To: Stephen Berman <stephen.berman@HIDDEN> References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN> <51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN> <87wmprqxj3.fsf@HIDDEN> <8734s5w1mf.fsf@HIDDEN> Content-Language: en-US From: Mauro Aranda <maurooaranda@HIDDEN> In-Reply-To: <8734s5w1mf.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69941 Cc: Eli Zaretskii <eliz@HIDDEN>, 69941 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > On Sun, 24 Mar 2024 19:45:20 +0100 Stephen Berman <stephen.berman@HIDDEN> wrote: > >> On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda <maurooaranda@HIDDEN> wrote: >> >>> Stephen Berman <stephen.berman@HIDDEN> writes: >>> >>>> 5. Tab back to "Activate" and press RET, again restoring the initial >>>> state. Now tab to radio button "Two" and press RET. >>>> => The fontification is the same as in step 4: radio button "Two" has >>>> the widget-inactive face but radio button "One" has the default (active) >>>> face, though it is again inactive. Repeatedly pressing either of the >>>> radio buttons (after activating them), does not change the fontification >>>> of "One" again. >>>> >>>> >>>> The faulty fontification of radio button "One" also obtains if there is >>>> just one radio button instead of two, and if there are more than two >>>> radio buttons, it is only the first one that displays the odd >>>> fontification (admittedly, I've only test up to three radio buttons). >>>> >>>> I've tried to debug this and found that the problem seems to be due to >>>> the sexp (set-marker-insertion-type from t) near the end of >>>> widget-default-create, which advances the marker specified by the >>>> widget's :from property. Changing t to nil fixes the faulty >>>> fontification of the first radio button. >>>> >>>> I investigated the history of this code, and while the value t for the >>>> marker insertion type was used in the initial commit, it was changed to >>>> nil in commit e0f956935, with the message "Insert new text at the :from >>>> marker _after_ the marker, not before it." But 18 days later it was >>>> changed back to t in commit 3bff434b8, that also added "Document need to >>>> put some text before the %v escape in :format string" of editable-field >>>> widgets. (I looked at the bug-gnu-emacs and emacs-devel mailing list >>>> archives but found nothing relevant at the time just prior to these >>>> commits.) >>> >>> I'm pretty sure it makes sense for user-editable widgets that the >>> value for insertion-type be t. >> >> Yes, if my understanding is correct, it's just radio-button-choice >> widgets that need (the effect of) insertion type nil (at least for >> setting the widget-inactive face), see below. >> >>>> So evidently the advancing marker insertion type is needed for at least >>>> some widgets, though it seems to be problematic for radio buttons. So I >>>> tried to conditionalize the choice of t or nil on the type of the >>>> widget. I used (not (eq 'radio-button (widget-type widget))), since the >>>> argument `widget' of widget-default-create is, according to Edebug, >>>> indeed radio-button, so negating the eq sexp returns nil, which I had >>>> found to be the value of the marker insertion type that fixes the >>>> fontification (however, I couldn't think of a way of limiting the >>>> conditioning to only the first radio button, but in my testing so far >>>> that lack doesn't appear to make a difference). >>> >>> I'm not sure if the right target is the radio-button widget. It could >>> be the radio-button-choice widget. Did you try to conditionalize the code >>> against the radio-button-choice widget? >> >> I didn't, because I got hung up on the radio-button widget, since in >> Edebug that is what I saw and (mistakenly) took to be the current widget >> when widget-inactive face is set. But the resulting marker insertion >> type discrepancy is really proof that I was looking at the wrong widget >> type (as I already realized in my comments cited below, but I didn't >> think to simply try it with radio-button-choice until now, so thanks for >> pointing me in the right direction!). And indeed, with >> radio-button-choice, negating the eq test DTRT, i.e., using (not (eq >> 'radio-button-choice (widget-type widget))) as the condtion results in >> the correct fontification. Since this sexp gives the >> radio-button-choice widget's :from property the marker insertion type >> nil, there is no discrepancy between using that sexp and directly using >> nil, so changing my patch to use that condition would be in improvement. >> Alternatively, ... >> >>>> But in fact, using the negation of the value of the eq sexp results in >>>> the same faulty fontification, while omitting the negation (as in the >>>> attached patch), which yields the advancing insertion type t, gives the >>>> correct fontification, just like using nil does. This makes no sense to >>>> me, yet it is reliably reproducible. The only possible explanation that >>>> occurs to me is that the bug is triggered elsewhere in the Emacs code >>>> and somehow using the sexp that evaluates to t as the marker insertion >>>> type affects that code, while using t itself does not (or rather, has >>>> the opposite effect); but how that could be and where the culpable code >>>> is, I don't know (as a guess, perhaps in the C code that adds faces, but >>>> I don't know how to debug that). If anyone knows or has an idea what's >>>> going on here, please communicate it. In the meantime I will continue >>>> to use the widget library with the patch to see whether it has unwanted >>>> consequences. >>> >>> I don't know much about that code in Emacs. If we find some hack that >>> works maybe we can use that until someone figures it out. But again, >>> given your analysis, I'd like to find out if using the condition on the >>> radio-button-choice widget works as expected. And of course, the hack >>> shouldn't be added to the widget-default-create, which should remain >>> type agnostic. >> >> ... since the issue is fontification with the widget-inactive face, >> perhaps a better location for the condition is widget-specify-inactive, >> as in the attached patch. It's still a hack though, since >> widget-specify-inactive is also type-agnostic by design. But if the >> issue really is confined to radio-button-choice widget's, I guess any >> solution will have to refer to that type. However, between adding the >> condition to widget-specify-inactive or to widget-default-create, I'm >> not sure which is less hacky: since the patch to widget-default-create >> effectively undoes the result of setting the marker insertion type to t, >> perhaps it is cleaner just to set it to nil for radio-button-choice >> widgets in widget-default-create. Or maybe someone will come up with a >> better fix... >> >> Steve Berman >> >> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el >> index 172da3db1e0..01319853edc 100644 >> --- a/lisp/wid-edit.el >> +++ b/lisp/wid-edit.el >> @@ -532,6 +532,17 @@ widget-inactive >> >> (defun widget-specify-inactive (widget from to) >> "Make WIDGET inactive for user modifications." >> + ;; When WIDGET is a radio-button-choice widget and its first child >> + ;; radio-button widget is inserted, the marker FROM, which has >> + ;; insertion type t, advances to the position after the radio button, >> + ;; and since the overlay setting the widget-inactive face begins at >> + ;; the position of FROM, this results in the first radio button >> + ;; incorrectly not being fontified with the widget-inactive face. To >> + ;; ensure it is correctly fontified, we move FROM backward by 3, >> + ;; i.e. the length of the radio-button widget (from its string >> + ;; representation "( )" or "(x)") (bug#69941). >> + (when (eq (widget-type widget) 'radio-button-choice) >> + (set-marker from (- from 3))) >> (unless (widget-get widget :inactive) >> (let ((overlay (make-overlay from to nil t nil))) >> (overlay-put overlay 'face 'widget-inactive) > > To fix this bug, do you have a preference between this patch for > widget-specify-inactive and the attached patch for > widget-default-create? Or do you have a better fix? > > Steve Berman I don't really have a better fix. I mean, ideally, we'd find the reason why the setting behaves differently for the radio-button-choice widget, and only for the first one in a radio widget, as it seems to me. But I'll need more time to be able to look into that. That said, if Eli is OK with installing a minor hack (with a FIXME, please), I don't have problems. And since it's a hack (and hopefully temporary), it's better if we keep it at widget-default-create then.
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.Received: (at 69941) by debbugs.gnu.org; 6 Apr 2024 10:18:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 06:18:48 2024 Received: from localhost ([127.0.0.1]:38357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt38J-0002Sy-OR for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 06:18:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rt38I-0002S5-0M for 69941 <at> debbugs.gnu.org; Sat, 06 Apr 2024 06:18:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rt386-0007Dq-E6; Sat, 06 Apr 2024 06:18:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=zmczGXcrhjuDj6JX8sr4zmTlpHuAHUt6GDGUom0SQsk=; b=J+VINpXNPH3ryUnuZTA7 44gbJXm9yXLNYD/gqdg+QveXys8USendaLClsxjlJsXnM5z2uDZ01m3t1hMoKwWg/UcK5H8P0IN3N jzjcb+FOLQ75ovHjiyhxiVKFrFxY66w7p+JpSu04X0PZm3Lyhx/1XuJyvXUm/FOnHyEzgxlx7BErg yn44Thtqhvoi9H3WiB31cVpeaZuVuVi63dKCUAS+njMuJGwgozg3txuW4FPmaqakGTxdXDIQ7i+Au Ff03qt/Kd0z770p1Pjj9ubmc2LcRBR8eRhz/vK107f+WyiU58Y4gTQ8Tm2C1C8hN/HIM+Cn8RweIe zNbFLfhE/LJXYg==; Date: Sat, 06 Apr 2024 13:18:31 +0300 Message-Id: <86plv23ibs.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: maurooaranda@HIDDEN, Stephen Berman <stephen.berman@HIDDEN> In-Reply-To: <8734s5w1mf.fsf@HIDDEN> (message from Stephen Berman on Mon, 01 Apr 2024 17:20:40 +0200) Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN> <51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN> <87wmprqxj3.fsf@HIDDEN> <8734s5w1mf.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69941 Cc: 69941 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Ping! > From: Stephen Berman <stephen.berman@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 69941 <at> debbugs.gnu.org, Stefan Monnier > <monnier@HIDDEN> > Date: Mon, 01 Apr 2024 17:20:40 +0200 > > On Sun, 24 Mar 2024 19:45:20 +0100 Stephen Berman <stephen.berman@HIDDEN> wrote: > > > On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda <maurooaranda@HIDDEN> wrote: > > > >> Stephen Berman <stephen.berman@HIDDEN> writes: > >> > >>> 5. Tab back to "Activate" and press RET, again restoring the initial > >>> state. Now tab to radio button "Two" and press RET. > >>> => The fontification is the same as in step 4: radio button "Two" has > >>> the widget-inactive face but radio button "One" has the default (active) > >>> face, though it is again inactive. Repeatedly pressing either of the > >>> radio buttons (after activating them), does not change the fontification > >>> of "One" again. > >>> > >>> > >>> The faulty fontification of radio button "One" also obtains if there is > >>> just one radio button instead of two, and if there are more than two > >>> radio buttons, it is only the first one that displays the odd > >>> fontification (admittedly, I've only test up to three radio buttons). > >>> > >>> I've tried to debug this and found that the problem seems to be due to > >>> the sexp (set-marker-insertion-type from t) near the end of > >>> widget-default-create, which advances the marker specified by the > >>> widget's :from property. Changing t to nil fixes the faulty > >>> fontification of the first radio button. > >>> > >>> I investigated the history of this code, and while the value t for the > >>> marker insertion type was used in the initial commit, it was changed to > >>> nil in commit e0f956935, with the message "Insert new text at the :from > >>> marker _after_ the marker, not before it." But 18 days later it was > >>> changed back to t in commit 3bff434b8, that also added "Document need to > >>> put some text before the %v escape in :format string" of editable-field > >>> widgets. (I looked at the bug-gnu-emacs and emacs-devel mailing list > >>> archives but found nothing relevant at the time just prior to these > >>> commits.) > >> > >> I'm pretty sure it makes sense for user-editable widgets that the > >> value for insertion-type be t. > > > > Yes, if my understanding is correct, it's just radio-button-choice > > widgets that need (the effect of) insertion type nil (at least for > > setting the widget-inactive face), see below. > > > >>> So evidently the advancing marker insertion type is needed for at least > >>> some widgets, though it seems to be problematic for radio buttons. So I > >>> tried to conditionalize the choice of t or nil on the type of the > >>> widget. I used (not (eq 'radio-button (widget-type widget))), since the > >>> argument `widget' of widget-default-create is, according to Edebug, > >>> indeed radio-button, so negating the eq sexp returns nil, which I had > >>> found to be the value of the marker insertion type that fixes the > >>> fontification (however, I couldn't think of a way of limiting the > >>> conditioning to only the first radio button, but in my testing so far > >>> that lack doesn't appear to make a difference). > >> > >> I'm not sure if the right target is the radio-button widget. It could > >> be the radio-button-choice widget. Did you try to conditionalize the code > >> against the radio-button-choice widget? > > > > I didn't, because I got hung up on the radio-button widget, since in > > Edebug that is what I saw and (mistakenly) took to be the current widget > > when widget-inactive face is set. But the resulting marker insertion > > type discrepancy is really proof that I was looking at the wrong widget > > type (as I already realized in my comments cited below, but I didn't > > think to simply try it with radio-button-choice until now, so thanks for > > pointing me in the right direction!). And indeed, with > > radio-button-choice, negating the eq test DTRT, i.e., using (not (eq > > 'radio-button-choice (widget-type widget))) as the condtion results in > > the correct fontification. Since this sexp gives the > > radio-button-choice widget's :from property the marker insertion type > > nil, there is no discrepancy between using that sexp and directly using > > nil, so changing my patch to use that condition would be in improvement. > > Alternatively, ... > > > >>> But in fact, using the negation of the value of the eq sexp results in > >>> the same faulty fontification, while omitting the negation (as in the > >>> attached patch), which yields the advancing insertion type t, gives the > >>> correct fontification, just like using nil does. This makes no sense to > >>> me, yet it is reliably reproducible. The only possible explanation that > >>> occurs to me is that the bug is triggered elsewhere in the Emacs code > >>> and somehow using the sexp that evaluates to t as the marker insertion > >>> type affects that code, while using t itself does not (or rather, has > >>> the opposite effect); but how that could be and where the culpable code > >>> is, I don't know (as a guess, perhaps in the C code that adds faces, but > >>> I don't know how to debug that). If anyone knows or has an idea what's > >>> going on here, please communicate it. In the meantime I will continue > >>> to use the widget library with the patch to see whether it has unwanted > >>> consequences. > >> > >> I don't know much about that code in Emacs. If we find some hack that > >> works maybe we can use that until someone figures it out. But again, > >> given your analysis, I'd like to find out if using the condition on the > >> radio-button-choice widget works as expected. And of course, the hack > >> shouldn't be added to the widget-default-create, which should remain > >> type agnostic. > > > > ... since the issue is fontification with the widget-inactive face, > > perhaps a better location for the condition is widget-specify-inactive, > > as in the attached patch. It's still a hack though, since > > widget-specify-inactive is also type-agnostic by design. But if the > > issue really is confined to radio-button-choice widget's, I guess any > > solution will have to refer to that type. However, between adding the > > condition to widget-specify-inactive or to widget-default-create, I'm > > not sure which is less hacky: since the patch to widget-default-create > > effectively undoes the result of setting the marker insertion type to t, > > perhaps it is cleaner just to set it to nil for radio-button-choice > > widgets in widget-default-create. Or maybe someone will come up with a > > better fix... > > > > Steve Berman > > > > diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el > > index 172da3db1e0..01319853edc 100644 > > --- a/lisp/wid-edit.el > > +++ b/lisp/wid-edit.el > > @@ -532,6 +532,17 @@ widget-inactive > > > > (defun widget-specify-inactive (widget from to) > > "Make WIDGET inactive for user modifications." > > + ;; When WIDGET is a radio-button-choice widget and its first child > > + ;; radio-button widget is inserted, the marker FROM, which has > > + ;; insertion type t, advances to the position after the radio button, > > + ;; and since the overlay setting the widget-inactive face begins at > > + ;; the position of FROM, this results in the first radio button > > + ;; incorrectly not being fontified with the widget-inactive face. To > > + ;; ensure it is correctly fontified, we move FROM backward by 3, > > + ;; i.e. the length of the radio-button widget (from its string > > + ;; representation "( )" or "(x)") (bug#69941). > > + (when (eq (widget-type widget) 'radio-button-choice) > > + (set-marker from (- from 3))) > > (unless (widget-get widget :inactive) > > (let ((overlay (make-overlay from to nil t nil))) > > (overlay-put overlay 'face 'widget-inactive) > > To fix this bug, do you have a preference between this patch for > widget-specify-inactive and the attached patch for > widget-default-create? Or do you have a better fix? > > Steve Berman
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.
Received: (at 69941) by debbugs.gnu.org; 1 Apr 2024 15:20:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 01 11:20:58 2024
Received: from localhost ([127.0.0.1]:51374 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rrJSz-0003fc-7t
for submit <at> debbugs.gnu.org; Mon, 01 Apr 2024 11:20:57 -0400
Received: from mout.gmx.net ([212.227.15.19]:51073)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1rrJSx-0003fP-M8
for 69941 <at> debbugs.gnu.org; Mon, 01 Apr 2024 11:20:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1711984842; x=1712589642; i=stephen.berman@HIDDEN;
bh=ff80F5P1vKxQG38joAlolyhVVnhfX3PY0zV595rYNwE=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:
Date;
b=raQo+S2tQAJcm1WzTip3r1qVY79R0BtFcGLqRC/0mM2GoIruRhgmvfMjZNrQOZM7
K1jpaYe8Cnroq91DzG3x1rnYUIvMx8qgHE8Srdm11JRWwk2/xNJbwi2BuBashxQny
2gbrcuztCoK4jMd36Y90OyUuRYfWPW1MoF7Ef6M4XbKOUzYr3qNim3Oruz0BNc5qq
8wJm5G2tC0jNNrUgkqsk8RWg+xzlzV5aFtsUDSfcyDFZcs740AGB5onxSj3iUIWAA
V5HbpPJgFT4Ozhhh/EvgMyrYxFfxckQa9jrq1sJPpwmEM+PB49l5cx+5KubcEVOYP
9S2JbZlAjMOaNvsTVw==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs ([94.134.95.171]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1MNbp3-1sAlKD0bql-00P8Ad; Mon, 01
Apr 2024 17:20:42 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
To: Mauro Aranda <maurooaranda@HIDDEN>
Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets
In-Reply-To: <87wmprqxj3.fsf@HIDDEN> (Stephen Berman's message of "Sun, 24
Mar 2024 19:45:20 +0100")
References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN>
<51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN>
<87wmprqxj3.fsf@HIDDEN>
Date: Mon, 01 Apr 2024 17:20:40 +0200
Message-ID: <8734s5w1mf.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Provags-ID: V03:K1:+2qLvW7p7pyS2JmciX6bIMpUPvIkmwZFTfdCvWPE2uomr6jtnk9
XqgiyDbbRTH7bHZ7Icy1fAWKOweNGKx1Zyee5cqIRAUlRyyzd9mk6CzJw0b2K3caweE2VUh
FzCQtxYPMz7A0ov3kgr0E9s+OIvzevpooZ7lxNLX7A5eip9BuYUvled5bM1IEnUToiamBjm
MBfidk/RdVvhSz2AySG8A==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:Vnr9gZ1dvVc=;aHEYg5SoFGlRJ0f4M5BDqHfULyf
66YtKzSSUpF9rfeKvlpBMTz+0PXx4Yv1+jaEBY0JNrrxQ/h69MB3zzVfA+aSGuz0GVtvbmXv3
66EpFd+MgmXEd7sNDBOS1YNceCV++YI4ztSaGiU9ejetqdc6wmQ5fhQkuUrI/BKd5umL/PqwB
MacrtLa3xRoI/wbJu1KBRwuG0rdRPJ4kdqH8TcgnVN2RmQO55j2E/Ln5g34s1QpvfqZxxLdeG
f7eDJDfULGwLMbLNwjpvV5+CcqWVmtUIviCsoogWg+CmJF/I0Ba0EteImB5XTWCXWpnGJj/nk
aTLbTrI3hfO1OQG8lk0ZlPdMIBiYvIBnqUjVge1FIRd5kwx8umZ1SIpRRZ6y1e20GdABwun4Z
p1fQt4kfMp0v41MxZcHKvexjyekQGJoyHWIAyMioDYhd4mfTZ/xpg0AI/q7n+A25dRS1HBqXd
b41pGOoRHjvJz9ULCrSwccn90A9Lg5JqnJ1YpGXpoCfM9V0s9KPCSIArPbpx4DZXpAxwjI9NL
3qSdAdPJwEH3HyXPyi5UJvDPCq4tfGRjqEMxD5GbdDFfKD+XTCLqfG2rsMcprHvTaHYQrfn0B
7sfBEYng/Zk/MCVz++f7+AKKs/Eon9NnB/3UoXvNdWRFmiRjgUccTXqLCFrAumhPtM2e6fwbG
4Rjv7fXOaWw3w9AOqzhZdAbdXuXXInLp0Fl6LbSuh+BW4jB+xXelXl6hk7TEzmhdfglOnF35M
CzcKTeseoCP3ve6K6/kRI3SJfyLij5xKYco7Lz41BYeKIgwSYMKZlbKXaJEtiP7OU/DeL8v5+
zc/n/yPeDC8mb2pMUWbzPk3KRIGztE1PamdRlj8UaTh6w=
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 69941
Cc: Eli Zaretskii <eliz@HIDDEN>, 69941 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On Sun, 24 Mar 2024 19:45:20 +0100 Stephen Berman <stephen.berman@HIDDEN> =
wrote:
> On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda <maurooaranda@HIDDEN> =
wrote:
>
>> Stephen Berman <stephen.berman@HIDDEN> writes:
>>
>>> 5. Tab back to "Activate" and press RET, again restoring the initial
>>> state.=C2=A0 Now tab to radio button "Two" and press RET.
>>> =3D> The fontification is the same as in step 4: radio button "Two" has
>>> the widget-inactive face but radio button "One" has the default (active)
>>> face, though it is again inactive.=C2=A0 Repeatedly pressing either of =
the
>>> radio buttons (after activating them), does not change the fontification
>>> of "One" again.
>>>
>>>
>>> The faulty fontification of radio button "One" also obtains if there is
>>> just one radio button instead of two, and if there are more than two
>>> radio buttons, it is only the first one that displays the odd
>>> fontification (admittedly, I've only test up to three radio buttons).
>>>
>>> I've tried to debug this and found that the problem seems to be due to
>>> the sexp (set-marker-insertion-type from t) near the end of
>>> widget-default-create, which advances the marker specified by the
>>> widget's :from property.=C2=A0 Changing t to nil fixes the faulty
>>> fontification of the first radio button.
>>>
>>> I investigated the history of this code, and while the value t for the
>>> marker insertion type was used in the initial commit, it was changed to
>>> nil in commit e0f956935, with the message "Insert new text at the :from
>>> marker _after_ the marker, not before it."=C2=A0 But 18 days later it w=
as
>>> changed back to t in commit 3bff434b8, that also added "Document need to
>>> put some text before the %v escape in :format string" of editable-field
>>> widgets.=C2=A0 (I looked at the bug-gnu-emacs and emacs-devel mailing l=
ist
>>> archives but found nothing relevant at the time just prior to these
>>> commits.)
>>
>> I'm pretty sure it makes sense for user-editable widgets that the
>> value for insertion-type be t.
>
> Yes, if my understanding is correct, it's just radio-button-choice
> widgets that need (the effect of) insertion type nil (at least for
> setting the widget-inactive face), see below.
>
>>> So evidently the advancing marker insertion type is needed for at least
>>> some widgets, though it seems to be problematic for radio buttons.=C2=
=A0 So I
>>> tried to conditionalize the choice of t or nil on the type of the
>>> widget.=C2=A0 I used (not (eq 'radio-button (widget-type widget))), sin=
ce the
>>> argument `widget' of widget-default-create is, according to Edebug,
>>> indeed radio-button, so negating the eq sexp returns nil, which I had
>>> found to be the value of the marker insertion type that fixes the
>>> fontification (however, I couldn't think of a way of limiting the
>>> conditioning to only the first radio button, but in my testing so far
>>> that lack doesn't appear to make a difference).
>>
>> I'm not sure if the right target is the radio-button widget.=C2=A0 It co=
uld
>> be the radio-button-choice widget.=C2=A0 Did you try to conditionalize t=
he code
>> against the radio-button-choice widget?
>
> I didn't, because I got hung up on the radio-button widget, since in
> Edebug that is what I saw and (mistakenly) took to be the current widget
> when widget-inactive face is set. But the resulting marker insertion
> type discrepancy is really proof that I was looking at the wrong widget
> type (as I already realized in my comments cited below, but I didn't
> think to simply try it with radio-button-choice until now, so thanks for
> pointing me in the right direction!). And indeed, with
> radio-button-choice, negating the eq test DTRT, i.e., using (not (eq
> 'radio-button-choice (widget-type widget))) as the condtion results in
> the correct fontification. Since this sexp gives the
> radio-button-choice widget's :from property the marker insertion type
> nil, there is no discrepancy between using that sexp and directly using
> nil, so changing my patch to use that condition would be in improvement.
> Alternatively, ...
>
>>> But in fact, using the negation of the value of the eq sexp results in
>>> the same faulty fontification, while omitting the negation (as in the
>>> attached patch), which yields the advancing insertion type t, gives the
>>> correct fontification, just like using nil does.=C2=A0 This makes no se=
nse to
>>> me, yet it is reliably reproducible.=C2=A0 The only possible explanatio=
n that
>>> occurs to me is that the bug is triggered elsewhere in the Emacs code
>>> and somehow using the sexp that evaluates to t as the marker insertion
>>> type affects that code, while using t itself does not (or rather, has
>>> the opposite effect); but how that could be and where the culpable code
>>> is, I don't know (as a guess, perhaps in the C code that adds faces, but
>>> I don't know how to debug that).=C2=A0 If anyone knows or has an idea w=
hat's
>>> going on here, please communicate it.=C2=A0 In the meantime I will cont=
inue
>>> to use the widget library with the patch to see whether it has unwanted
>>> consequences.
>>
>> I don't know much about that code in Emacs.=C2=A0 If we find some hack t=
hat
>> works maybe we can use that until someone figures it out.=C2=A0 But agai=
n,
>> given your analysis, I'd like to find out if using the condition on the
>> radio-button-choice widget works as expected.=C2=A0 And of course, the h=
ack
>> shouldn't be added to the widget-default-create, which should remain
>> type agnostic.
>
> ... since the issue is fontification with the widget-inactive face,
> perhaps a better location for the condition is widget-specify-inactive,
> as in the attached patch. It's still a hack though, since
> widget-specify-inactive is also type-agnostic by design. But if the
> issue really is confined to radio-button-choice widget's, I guess any
> solution will have to refer to that type. However, between adding the
> condition to widget-specify-inactive or to widget-default-create, I'm
> not sure which is less hacky: since the patch to widget-default-create
> effectively undoes the result of setting the marker insertion type to t,
> perhaps it is cleaner just to set it to nil for radio-button-choice
> widgets in widget-default-create. Or maybe someone will come up with a
> better fix...
>
> Steve Berman
>
> diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
> index 172da3db1e0..01319853edc 100644
> --- a/lisp/wid-edit.el
> +++ b/lisp/wid-edit.el
> @@ -532,6 +532,17 @@ widget-inactive
>=20=20
> (defun widget-specify-inactive (widget from to)
> "Make WIDGET inactive for user modifications."
> + ;; When WIDGET is a radio-button-choice widget and its first child
> + ;; radio-button widget is inserted, the marker FROM, which has
> + ;; insertion type t, advances to the position after the radio button,
> + ;; and since the overlay setting the widget-inactive face begins at
> + ;; the position of FROM, this results in the first radio button
> + ;; incorrectly not being fontified with the widget-inactive face. To
> + ;; ensure it is correctly fontified, we move FROM backward by 3,
> + ;; i.e. the length of the radio-button widget (from its string
> + ;; representation "( )" or "(x)") (bug#69941).
> + (when (eq (widget-type widget) 'radio-button-choice)
> + (set-marker from (- from 3)))
> (unless (widget-get widget :inactive)
> (let ((overlay (make-overlay from to nil t nil)))
> (overlay-put overlay 'face 'widget-inactive)
To fix this bug, do you have a preference between this patch for
widget-specify-inactive and the attached patch for
widget-default-create? Or do you have a better fix?
Steve Berman
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment
Content-Description: widget-default-create patch
Content-Transfer-Encoding: quoted-printable
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 172da3db1e0..7fc9ac59b0a 100644
=2D-- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -1733,8 +1733,17 @@ widget-default-create
(goto-char value-pos)
(widget-apply widget :value-create)))
(let ((from (point-min-marker))
- (to (point-max-marker)))
- (set-marker-insertion-type from t)
+ (to (point-max-marker))
+ ;; When WIDGET is a radio-button-choice widget and its first
+ ;; child radio-button widget is inserted, advancing the marker
+ ;; FROM would make the overlay setting the widget-inactive face
+ ;; begin right after the first radio button, which would hence
+ ;; incorrectly not be fontified with the widget-inactive face.
+ ;; To ensure it is correctly fontified, we set the marker
+ ;; insertion type of FROM to nil only when WIDGET is
+ ;; radio-button-choice, otherwise to t (bug#69941).
+ (from-mit (not (eq 'radio-button-choice (widget-type widget)))))
+ (set-marker-insertion-type from from-mit)
(set-marker-insertion-type to nil)
(widget-put widget :from from)
(widget-put widget :to to)))
diff --git a/test/lisp/wid-edit-tests.el b/test/lisp/wid-edit-tests.el
index 4b049478b29..d416eb99022 100644
=2D-- a/test/lisp/wid-edit-tests.el
+++ b/test/lisp/wid-edit-tests.el
@@ -336,7 +336,13 @@ widget-test-widget-move
(widget-forward 2)
(forward-char)
(widget-backward 1)
- (should (string=3D "Second" (widget-value (widget-at))))))
+ (should (string=3D "Second" (widget-value (widget-at))))
+ ;; Check that moving to a widget at beginning of buffer does not
+ ;; signal a beginning-of-buffer error (bug#69943).
+ (widget-backward 1) ; Should not signal beginning-of-buffer error.
+ (widget-forward 2)
+ (should (string=3D "Third" (widget-value (widget-at))))
+ (widget-forward 1))) ; Should not signal beginning-of-buffer error.
(ert-deftest widget-test-color-match ()
"Test that the :match function for the color widget works."
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.
Received: (at 69941) by debbugs.gnu.org; 24 Mar 2024 18:46:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 24 14:46:20 2024
Received: from localhost ([127.0.0.1]:47412 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1roSrM-00080a-3R
for submit <at> debbugs.gnu.org; Sun, 24 Mar 2024 14:46:20 -0400
Received: from mout.gmx.net ([212.227.15.18]:39777)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1roSrG-00080I-NB
for 69941 <at> debbugs.gnu.org; Sun, 24 Mar 2024 14:46:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1711305922; x=1711910722; i=stephen.berman@HIDDEN;
bh=Qaq0wPObH0uZYr4VirTrZYILcBDbFTp6AKH2U5xoKCg=;
h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:
Date;
b=hnGl7QG2POXQkHsDENOSvqkXydXUYKezWOBZocsVSLNak1fUXnS9ZJohqkqSVePr
6HQ7wT7bQTJi4856qVpiNLcbVLnXkEIn0MjzIBmZ5YQ8y5eeDw3TXKEU5hM56HMbI
L2jb7g+UthSksnvWaSO4MWPkYFVri4FvmMaaaroNBHiiOZkLBEZUgzUIMI+bWUJrI
6PeuIS3wwq2zuqKwbt/LaLXr1k1pC708EKoYrob2Yd5zBVmig6lSvqT8cjI1Rk3PF
Q/fKYILn51oa7C03yoBlzMId6oiBTIr0iB6UYv4VqOIuUAw/wnVTsWzRQBM1mgzpJ
Q+MYf3cuABQ2pogJ/g==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs2 ([88.130.49.213]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1Mplc7-1seWjP06uL-00q8pH; Sun, 24
Mar 2024 19:45:22 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: Mauro Aranda <maurooaranda@HIDDEN>
Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets
In-Reply-To: <51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN> (Mauro Aranda's
message of "Sat, 23 Mar 2024 17:49:53 -0300")
References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN>
<51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN>
Date: Sun, 24 Mar 2024 19:45:20 +0100
Message-ID: <87wmprqxj3.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Provags-ID: V03:K1:u5xgSeIUyhcZtVjRCnDx7p4HhZSXJ5UpoPYb0SCidWdt5nYDDde
fKtEpQOkX/4xmnvL8uiWk9KtKaJ5gcCbYe3oJL3UpGBmlYPy87YNJSTxzekComNJLa2QTwk
Xz4Mlqdzdx3tk7tfKnJR3jCl0xIX+CGMJtR4TNooeAOS0Jddg5Zxp/QM/E2lTIPcwNtAUDo
VbtkpQ48i1ksXUFQ3XwKA==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:WFEwqBJtTrM=;JYRd7getSvCWTlnMmCKhHXtkGgT
QwxmpvamKf7u0/71SbzdV6yUtepd7aBRlDutcJlV37VnasMA4SDkUoCeOgYoNOEt5fpp4518g
ut2u0kZNzh4kks4Y+0YLQ9KlUS3xu+DDehzcJnZpu1cDf90nopq2i92RYnepF20lXWuDThitD
h4dfeusiY33YOaP1ndhfrKBIb5CORzNQDOcIpSGfuMJioXM2rKBORKLTc04JvLGzKNCxt8RAd
ncpIKhzuiuEgpZkdrQiOOoExiox3QVadxITzglalHSO/op+3h2LKb7EfRYGr+FLI/+Sn1hbfr
TCqS3Elgd9t6jL2Fo0/2IwQ0/t5Y7GVk2jVJ4k8KCohB63NvWIhXKc33MLhtZmegdk0tqDF/b
0CPMezQY4oBbZXhXkyVicLdcOjo5kW1wP4JJvvaF/oAUcLzFRP6eLYc1nD425uMQqGZmUXA3g
+NcwkiZHUy+UxHEfKelVXzN/+FPfpObmubiwQtear9CDEGbX7ATdvSxAAVc3AkrxUcbkSpoHM
WBuh2Yle+g6IeiIHr+Yluu+JxgPGMwv5IiJT+NUWp2v8+5Rpm7dSSigEziwLV6Qhh+TTQhISu
w7hqE1FSz66pcVqxJygOWU2eqlbC6PvHPOTvxCJFuThDMjRWUTjtKbkDbv4xMpPCTW6RgRpRL
0S2sMEgiNhvNqQ7SyoMXp73qYrIzOIiyiGVlap3qEHv0zEAgj0+mZHICvKM8GHDa0IQtSDCzp
iTHYIU5gRZ/fdGlKevwFPjvJzukc88Xd664RUQ5Ynkg7jRomVUXJL4uXLU9bRkFvlR8FKyXaq
Dsce9e1RpC0hxlaPx7ZZVvcOEDfXlgY6lrbE4N8z/WC58=
X-Spam-Score: 2.8 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda wrote: > Stephen
Berman writes: > >> 5. Tab back to "Activate" and press RET, again restoring
the initial >> state. Now tab to radio button "Two" and press RET. >> =>
The fontification is the same as in [...]
Content analysis details: (2.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[88.130.49.213 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (stephen.berman[at]gmx.net)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 69941
Cc: Eli Zaretskii <eliz@HIDDEN>, 69941 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda wrote: > Stephen
Berman writes: > >> 5. Tab back to "Activate" and press RET, again restoring
the initial >> state. Now tab to radio button "Two" and press RET. >> =>
The fontification is the same as in [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.15.18 listed in wl.mailspike.net]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[88.130.49.213 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.15.18 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (stephen.berman[at]gmx.net)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda <maurooaranda@HIDDEN> wr=
ote:
> Stephen Berman <stephen.berman@HIDDEN> writes:
>
>> 5. Tab back to "Activate" and press RET, again restoring the initial
>> state.=C2=A0 Now tab to radio button "Two" and press RET.
>> =3D> The fontification is the same as in step 4: radio button "Two" has
>> the widget-inactive face but radio button "One" has the default (active)
>> face, though it is again inactive.=C2=A0 Repeatedly pressing either of t=
he
>> radio buttons (after activating them), does not change the fontification
>> of "One" again.
>>
>>
>> The faulty fontification of radio button "One" also obtains if there is
>> just one radio button instead of two, and if there are more than two
>> radio buttons, it is only the first one that displays the odd
>> fontification (admittedly, I've only test up to three radio buttons).
>>
>> I've tried to debug this and found that the problem seems to be due to
>> the sexp (set-marker-insertion-type from t) near the end of
>> widget-default-create, which advances the marker specified by the
>> widget's :from property.=C2=A0 Changing t to nil fixes the faulty
>> fontification of the first radio button.
>>
>> I investigated the history of this code, and while the value t for the
>> marker insertion type was used in the initial commit, it was changed to
>> nil in commit e0f956935, with the message "Insert new text at the :from
>> marker _after_ the marker, not before it."=C2=A0 But 18 days later it was
>> changed back to t in commit 3bff434b8, that also added "Document need to
>> put some text before the %v escape in :format string" of editable-field
>> widgets.=C2=A0 (I looked at the bug-gnu-emacs and emacs-devel mailing li=
st
>> archives but found nothing relevant at the time just prior to these
>> commits.)
>
> I'm pretty sure it makes sense for user-editable widgets that the
> value for insertion-type be t.
Yes, if my understanding is correct, it's just radio-button-choice
widgets that need (the effect of) insertion type nil (at least for
setting the widget-inactive face), see below.
>> So evidently the advancing marker insertion type is needed for at least
>> some widgets, though it seems to be problematic for radio buttons.=C2=A0=
So I
>> tried to conditionalize the choice of t or nil on the type of the
>> widget.=C2=A0 I used (not (eq 'radio-button (widget-type widget))), sinc=
e the
>> argument `widget' of widget-default-create is, according to Edebug,
>> indeed radio-button, so negating the eq sexp returns nil, which I had
>> found to be the value of the marker insertion type that fixes the
>> fontification (however, I couldn't think of a way of limiting the
>> conditioning to only the first radio button, but in my testing so far
>> that lack doesn't appear to make a difference).
>
> I'm not sure if the right target is the radio-button widget.=C2=A0 It cou=
ld
> be the radio-button-choice widget.=C2=A0 Did you try to conditionalize th=
e code
> against the radio-button-choice widget?
I didn't, because I got hung up on the radio-button widget, since in
Edebug that is what I saw and (mistakenly) took to be the current widget
when widget-inactive face is set. But the resulting marker insertion
type discrepancy is really proof that I was looking at the wrong widget
type (as I already realized in my comments cited below, but I didn't
think to simply try it with radio-button-choice until now, so thanks for
pointing me in the right direction!). And indeed, with
radio-button-choice, negating the eq test DTRT, i.e., using (not (eq
'radio-button-choice (widget-type widget))) as the condtion results in
the correct fontification. Since this sexp gives the
radio-button-choice widget's :from property the marker insertion type
nil, there is no discrepancy between using that sexp and directly using
nil, so changing my patch to use that condition would be in improvement.
Alternatively, ...
>> But in fact, using the negation of the value of the eq sexp results in
>> the same faulty fontification, while omitting the negation (as in the
>> attached patch), which yields the advancing insertion type t, gives the
>> correct fontification, just like using nil does.=C2=A0 This makes no sen=
se to
>> me, yet it is reliably reproducible.=C2=A0 The only possible explanation=
that
>> occurs to me is that the bug is triggered elsewhere in the Emacs code
>> and somehow using the sexp that evaluates to t as the marker insertion
>> type affects that code, while using t itself does not (or rather, has
>> the opposite effect); but how that could be and where the culpable code
>> is, I don't know (as a guess, perhaps in the C code that adds faces, but
>> I don't know how to debug that).=C2=A0 If anyone knows or has an idea wh=
at's
>> going on here, please communicate it.=C2=A0 In the meantime I will conti=
nue
>> to use the widget library with the patch to see whether it has unwanted
>> consequences.
>
> I don't know much about that code in Emacs.=C2=A0 If we find some hack th=
at
> works maybe we can use that until someone figures it out.=C2=A0 But again,
> given your analysis, I'd like to find out if using the condition on the
> radio-button-choice widget works as expected.=C2=A0 And of course, the ha=
ck
> shouldn't be added to the widget-default-create, which should remain
> type agnostic.
... since the issue is fontification with the widget-inactive face,
perhaps a better location for the condition is widget-specify-inactive,
as in the attached patch. It's still a hack though, since
widget-specify-inactive is also type-agnostic by design. But if the
issue really is confined to radio-button-choice widget's, I guess any
solution will have to refer to that type. However, between adding the
condition to widget-specify-inactive or to widget-default-create, I'm
not sure which is less hacky: since the patch to widget-default-create
effectively undoes the result of setting the marker insertion type to t,
perhaps it is cleaner just to set it to nil for radio-button-choice
widgets in widget-default-create. Or maybe someone will come up with a
better fix...
Steve Berman
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=widget-specify-inactive.diff
Content-Transfer-Encoding: quoted-printable
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 172da3db1e0..01319853edc 100644
=2D-- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -532,6 +532,17 @@ widget-inactive
(defun widget-specify-inactive (widget from to)
"Make WIDGET inactive for user modifications."
+ ;; When WIDGET is a radio-button-choice widget and its first child
+ ;; radio-button widget is inserted, the marker FROM, which has
+ ;; insertion type t, advances to the position after the radio button,
+ ;; and since the overlay setting the widget-inactive face begins at
+ ;; the position of FROM, this results in the first radio button
+ ;; incorrectly not being fontified with the widget-inactive face. To
+ ;; ensure it is correctly fontified, we move FROM backward by 3,
+ ;; i.e. the length of the radio-button widget (from its string
+ ;; representation "( )" or "(x)") (bug#69941).
+ (when (eq (widget-type widget) 'radio-button-choice)
+ (set-marker from (- from 3)))
(unless (widget-get widget :inactive)
(let ((overlay (make-overlay from to nil t nil)))
(overlay-put overlay 'face 'widget-inactive)
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.Received: (at 69941) by debbugs.gnu.org; 23 Mar 2024 21:25:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 23 17:25:20 2024 Received: from localhost ([127.0.0.1]:54751 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1ro8rf-0004iF-W5 for submit <at> debbugs.gnu.org; Sat, 23 Mar 2024 17:25:20 -0400 Received: from mail-oi1-f171.google.com ([209.85.167.171]:44511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <maurooaranda@HIDDEN>) id 1ro8SA-0003dr-VN for 69941 <at> debbugs.gnu.org; Sat, 23 Mar 2024 16:58:59 -0400 Received: by mail-oi1-f171.google.com with SMTP id 5614622812f47-3c3880cd471so1846286b6e.1 for <69941 <at> debbugs.gnu.org>; Sat, 23 Mar 2024 13:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711227432; x=1711832232; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WBS1uRNuEGR3GDIMTiO4qKAMOkVUa/jV745k82v7gac=; b=h1rL+qOnTY6aeiFSkBPJF8DaMt+6W+t9TT4GgOLC3erf/XHfYf0tKlW0dsDrqHoA6P 9JK94S8jWhXKrb8AzEs1ssmdFwJt/WcMKqyoKxKjf5rz+qzj9amO1SyTRu5px/6PuuzP p4uVxI9KxKH7YQ88lEm312sex4D5zZN5YtFvOG1LUBUedPfE8wSx1SiI93mGUj+AhyY0 uXhVlok9TWdXRk/HiE6qX802zk95rfBCB/iQsCvSnp9z5XMoahKG7xS0fk8T3jwOD5dF cYou5Jslhiu6LKJ3ogHR1m0bP63eZccQVXlyYJ/LmIeCyu3Bub1ok0QPxHoCADk7/5pw ftgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711227432; x=1711832232; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WBS1uRNuEGR3GDIMTiO4qKAMOkVUa/jV745k82v7gac=; b=LorOC6cMRbijhSxzK0lNfsliGjOiCRb0e1IUKd6g1Lb7MIPKG8EPTRqbkmdWU65nXY mw75yGD0DLXtgfpoyLKpkZFkULcBmM1MXxPrX4ds1dVmAh8DpCb2FW1FFlktIeyS6IxN q4IJXJEi5Kk/yn9+1IoPzJQ1VfKIj9J94MyMv2sKKxMII8IKEopYzlw6+SGdk9SnuQ1G yaUI0ZHOXnnUP1fjmYHy/eEI9zK3qwQ2/mxRuSvC4GcXJTWAo6zQwr0mHr0tgrAr1ObY wHBmJ2AyjlxxSCXMM/vrGenUvyrZaTGJ4sqNkStXaENAGqtgH/snrIBAR5khkTGNnOcs QTTw== X-Gm-Message-State: AOJu0Yy0VvxntbnU25UNOH72s6kIn8zLMDncXC0EE4uo7VUOzi2blYZw ctKJsvu3DIBSAbWxfZ8WjAOBtbOVDw7dMdhXBDaDBqdEt/IZ6a0y5Q2+wB+7 X-Google-Smtp-Source: AGHT+IHjOFBKJbJ9DWY2Da5rf9u+Mv+kMW+MZyISwdIJ+RmRbiARMi19rdEK4OTDg+FKtYuvQ3EGeA== X-Received: by 2002:a17:90b:1296:b0:2a0:38b5:bdc6 with SMTP id fw22-20020a17090b129600b002a038b5bdc6mr2384246pjb.22.1711226998611; Sat, 23 Mar 2024 13:49:58 -0700 (PDT) Received: from [192.168.0.234] ([181.228.33.6]) by smtp.gmail.com with ESMTPSA id nn11-20020a17090b38cb00b0029b32b85d3dsm7481628pjb.29.2024.03.23.13.49.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Mar 2024 13:49:58 -0700 (PDT) Message-ID: <51c20b56-4b82-4f5c-9559-cdbd0146df22@HIDDEN> Date: Sat, 23 Mar 2024 17:49:53 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets To: Eli Zaretskii <eliz@HIDDEN>, Stephen Berman <stephen.berman@HIDDEN> References: <87h6gynx49.fsf@HIDDEN> <865xxe1dwd.fsf@HIDDEN> Content-Language: en-US From: Mauro Aranda <maurooaranda@HIDDEN> In-Reply-To: <865xxe1dwd.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 69941 Cc: 69941 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stephen Berman <stephen.berman@HIDDEN> writes: > 5. Tab back to "Activate" and press RET, again restoring the initial > state. Now tab to radio button "Two" and press RET. > => The fontification is the same as in step 4: radio button "Two" has > the widget-inactive face but radio button "One" has the default (active) > face, though it is again inactive. Repeatedly pressing either of the > radio buttons (after activating them), does not change the fontification > of "One" again. > > > The faulty fontification of radio button "One" also obtains if there is > just one radio button instead of two, and if there are more than two > radio buttons, it is only the first one that displays the odd > fontification (admittedly, I've only test up to three radio buttons). > > I've tried to debug this and found that the problem seems to be due to > the sexp (set-marker-insertion-type from t) near the end of > widget-default-create, which advances the marker specified by the > widget's :from property. Changing t to nil fixes the faulty > fontification of the first radio button. > > I investigated the history of this code, and while the value t for the > marker insertion type was used in the initial commit, it was changed to > nil in commit e0f956935, with the message "Insert new text at the :from > marker _after_ the marker, not before it." But 18 days later it was > changed back to t in commit 3bff434b8, that also added "Document need to > put some text before the %v escape in :format string" of editable-field > widgets. (I looked at the bug-gnu-emacs and emacs-devel mailing list > archives but found nothing relevant at the time just prior to these > commits.) I'm pretty sure it makes sense for user-editable widgets that the value for insertion-type be t. > So evidently the advancing marker insertion type is needed for at least > some widgets, though it seems to be problematic for radio buttons. So I > tried to conditionalize the choice of t or nil on the type of the > widget. I used (not (eq 'radio-button (widget-type widget))), since the > argument `widget' of widget-default-create is, according to Edebug, > indeed radio-button, so negating the eq sexp returns nil, which I had > found to be the value of the marker insertion type that fixes the > fontification (however, I couldn't think of a way of limiting the > conditioning to only the first radio button, but in my testing so far > that lack doesn't appear to make a difference). I'm not sure if the right target is the radio-button widget. It could be the radio-button-choice widget. Did you try to conditionalize the code against the radio-button-choice widget? > But in fact, using the negation of the value of the eq sexp results in > the same faulty fontification, while omitting the negation (as in the > attached patch), which yields the advancing insertion type t, gives the > correct fontification, just like using nil does. This makes no sense to > me, yet it is reliably reproducible. The only possible explanation that > occurs to me is that the bug is triggered elsewhere in the Emacs code > and somehow using the sexp that evaluates to t as the marker insertion > type affects that code, while using t itself does not (or rather, has > the opposite effect); but how that could be and where the culpable code > is, I don't know (as a guess, perhaps in the C code that adds faces, but > I don't know how to debug that). If anyone knows or has an idea what's > going on here, please communicate it. In the meantime I will continue > to use the widget library with the patch to see whether it has unwanted > consequences. I don't know much about that code in Emacs. If we find some hack that works maybe we can use that until someone figures it out. But again, given your analysis, I'd like to find out if using the condition on the radio-button-choice widget works as expected. And of course, the hack shouldn't be added to the widget-default-create, which should remain type agnostic.
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.Received: (at 69941) by debbugs.gnu.org; 22 Mar 2024 15:33:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 22 11:33:23 2024 Received: from localhost ([127.0.0.1]:60775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rngtW-0003A1-L7 for submit <at> debbugs.gnu.org; Fri, 22 Mar 2024 11:33:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rngtS-00039c-R3 for 69941 <at> debbugs.gnu.org; Fri, 22 Mar 2024 11:33:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rngsh-0006yQ-9S; Fri, 22 Mar 2024 11:32:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CwWyTKOhkdVoX0dYgPG2sqLJgcJdmQkXpXkm2UGOw9U=; b=b7YSS73UIMSW YZ2XRzIPtf1bxpASUhlBRsQXOdZGNuzY+Ms/7KG9cySy1g4HBeN/hLv6Vn48dBbSIBixPBOUiNrMk bGKdsfoiuN59Em/f4R+Oy2XukWencDjaszZ5jvmFIl8xdxYuteb+AnBBSmAvNJYJUb7FNgr0FVL7i /vBpCWzVXbWooiDU7alBM+iJl9abeaQG5duBwlk+uXxbXumJEX/yhIjWA1t3ocaQc+zCGjJEInnTv WGq6X4R8qnekTfSnjfKsnx2VoI6wsTmu3nnF0Ag3q8vz6RfnXtoyaQO+NQ8EUlR2HuI5LBO7jR8ZJ 4fONXp+6WEDxt+oJRjO4Xw==; Date: Fri, 22 Mar 2024 17:31:46 +0200 Message-Id: <865xxe1dwd.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stephen Berman <stephen.berman@HIDDEN>, Mauro Aranda <maurooaranda@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <87h6gynx49.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#69941: 30.0.50; Faulty fontification of radio button widgets References: <87h6gynx49.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69941 Cc: 69941 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Fri, 22 Mar 2024 15:45:42 +0100 > From: Stephen Berman via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > 0. Save the following code (attached here to circumvent line breaks > added by the mail program) as widget-example.el: > > (custom-set-faces '(widget-inactive ((t (:foreground "magenta" > :background "yellow"))))) > > (defvar my-radio-widget) > (defvar my-activate-button) > > (defun my-widget-example () > (interactive) > (switch-to-buffer "*My Widget Example*") > (kill-all-local-variables) > (let ((inhibit-read-only t)) > (erase-buffer)) > (remove-overlays) > (setq my-radio-widget > (widget-create 'radio-button-choice > :notify (lambda (widget &rest _) > (widget-apply widget :deactivate) > (widget-apply my-activate-button :activate)) > '(item "One") '(item "Two"))) > (setq my-activate-button > (widget-create 'push-button > :notify (lambda (widget &rest _) > (widget-value-set my-radio-widget "") > (widget-apply my-radio-widget :activate) > (widget-apply widget :deactivate)) > "Activate")) > (widget-apply my-activate-button :deactivate) > (use-local-map widget-keymap) > (widget-setup)) > > 1. emacs -Q -l widget-example.el > 2. M-x my-widget-example > > In the buffer "*My Widget Example*" it easy to see (due to value of the > widget-inactive face set in widget-example.el) that the push-button > widget "Activate" is inactive and the radio-button widgets labelled > "One" and "Two" are active (the buttons have the default face; that the > labels next to the buttons have the widget-inactive face may seem odd, > but that's not the bug I'm reporting here; I address that issue in a > separate bug report). > > 3. Press TAB (or S-TAB) twice to put point on the radio button "Two", > then press RET. As the fontification shows, now both radio buttons are > inactive (so pressing RET on either raises the error "Attempt to perform > action on inactive widget"), and the "Activate" button is now active. > After tabbing to the "Activate" button and pressing RET, the initial > state is restored, with the two radio buttons active and "Activate" > inactive. > > 4. Now tab up to the radio buttone "One" and press RET. > => While radio button "Two" agains has the widget-inactive face, radio > button "One" (just the button, not its label) has the default face used > for active widgets, though it is in fact inactive (as pressing RET and > getting the corresponding error verifies). > > 5. Tab back to "Activate" and press RET, again restoring the initial > state. Now tab to radio button "Two" and press RET. > => The fontification is the same as in step 4: radio button "Two" has > the widget-inactive face but radio button "One" has the default (active) > face, though it is again inactive. Repeatedly pressing either of the > radio buttons (after activating them), does not change the fontification > of "One" again. > > > The faulty fontification of radio button "One" also obtains if there is > just one radio button instead of two, and if there are more than two > radio buttons, it is only the first one that displays the odd > fontification (admittedly, I've only test up to three radio buttons). > > I've tried to debug this and found that the problem seems to be due to > the sexp (set-marker-insertion-type from t) near the end of > widget-default-create, which advances the marker specified by the > widget's :from property. Changing t to nil fixes the faulty > fontification of the first radio button. > > I investigated the history of this code, and while the value t for the > marker insertion type was used in the initial commit, it was changed to > nil in commit e0f956935, with the message "Insert new text at the :from > marker _after_ the marker, not before it." But 18 days later it was > changed back to t in commit 3bff434b8, that also added "Document need to > put some text before the %v escape in :format string" of editable-field > widgets. (I looked at the bug-gnu-emacs and emacs-devel mailing list > archives but found nothing relevant at the time just prior to these > commits.) > > So evidently the advancing marker insertion type is needed for at least > some widgets, though it seems to be problematic for radio buttons. So I > tried to conditionalize the choice of t or nil on the type of the > widget. I used (not (eq 'radio-button (widget-type widget))), since the > argument `widget' of widget-default-create is, according to Edebug, > indeed radio-button, so negating the eq sexp returns nil, which I had > found to be the value of the marker insertion type that fixes the > fontification (however, I couldn't think of a way of limiting the > conditioning to only the first radio button, but in my testing so far > that lack doesn't appear to make a difference). > > But in fact, using the negation of the value of the eq sexp results in > the same faulty fontification, while omitting the negation (as in the > attached patch), which yields the advancing insertion type t, gives the > correct fontification, just like using nil does. This makes no sense to > me, yet it is reliably reproducible. The only possible explanation that > occurs to me is that the bug is triggered elsewhere in the Emacs code > and somehow using the sexp that evaluates to t as the marker insertion > type affects that code, while using t itself does not (or rather, has > the opposite effect); but how that could be and where the culpable code > is, I don't know (as a guess, perhaps in the C code that adds faces, but > I don't know how to debug that). If anyone knows or has an idea what's > going on here, please communicate it. In the meantime I will continue > to use the widget library with the patch to see whether it has unwanted > consequences. > > diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el > index 172da3db1e0..c2cd48e1551 100644 > --- a/lisp/wid-edit.el > +++ b/lisp/wid-edit.el > @@ -1733,8 +1733,9 @@ widget-default-create > (goto-char value-pos) > (widget-apply widget :value-create))) > (let ((from (point-min-marker)) > - (to (point-max-marker))) > - (set-marker-insertion-type from t) > + (to (point-max-marker)) > + (from-mit (eq 'radio-button (widget-type widget)))) > + (set-marker-insertion-type from from-mit) > (set-marker-insertion-type to nil) > (widget-put widget :from from) > (widget-put widget :to to))) > Mauro and Stefan, any comments or suggestions?
bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 22 Mar 2024 15:00:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 22 11:00:11 2024
Received: from localhost ([127.0.0.1]:58670 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rngNO-0001bG-RX
for submit <at> debbugs.gnu.org; Fri, 22 Mar 2024 11:00:11 -0400
Received: from lists.gnu.org ([209.51.188.17]:60984)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1rngNK-0001Xf-E8
for submit <at> debbugs.gnu.org; Fri, 22 Mar 2024 11:00:09 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <stephen.berman@HIDDEN>)
id 1rng9T-0004sX-3B
for bug-gnu-emacs@HIDDEN; Fri, 22 Mar 2024 10:45:49 -0400
Received: from mout.gmx.net ([212.227.15.19])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <stephen.berman@HIDDEN>)
id 1rng9R-0003jY-4T
for bug-gnu-emacs@HIDDEN; Fri, 22 Mar 2024 10:45:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1711118743; x=1711723543; i=stephen.berman@HIDDEN;
bh=9HnrS87+V75EG/mi/0+z2oI2w28pTBuld2yM4V3Qox8=;
h=X-UI-Sender-Class:From:To:Subject:Date;
b=Gft1R80KTQiBRe311sniDocD6FJpZZmqzmrRE6nBdsUiLqe6T1KHiVVOJ5s0iXML
s/nxxR+qCX3Uq85anL0JHbHzyOQazmodky27Uj0bXus4MBy9YMMlM+m6eCiRKVdYI
HCXI6k6t7BOwQDRpMCLzOx+dL4r9iqWZyTzXKbK/2rH0+SOzQkECbGhdOEt4UH3en
6yxRj20vimXxfmRVnBwU7fLaUOlIMMNfBj1wVqKs7Dg+bDgNsdYMftnV4Y7Sw8f6O
jv+W2dyxnV8lapJg6/S1Lmp8iN5xFhS924Li+XRUbAVpfRPDT8D/bWLSTsAj9mdXp
+Ptj3GMRBr3RylWSPA==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from strobelfs2 ([88.130.50.228]) by mail.gmx.net (mrgmx004
[212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ob6-1qj5VJ1ft8-015sjs for
<bug-gnu-emacs@HIDDEN>; Fri, 22 Mar 2024 15:45:43 +0100
From: Stephen Berman <stephen.berman@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.0.50; Faulty fontification of radio button widgets
X-Debbugs-Cc:
Date: Fri, 22 Mar 2024 15:45:42 +0100
Message-ID: <87h6gynx49.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Provags-ID: V03:K1:r3Wjr09sdLqkknsiYCL5cGFHCX/DGR3vBs470dPAA5Xys7FM1tx
aBsERhAzhM8KTAtbPuUaotMhc1HLikZ4XOH2YNIm9mI3sIu9AIhnpEowLox4ybrqU4aw5hn
imvdCmtcenBR6UQYbh9I3gHQ5iGdjyGz8DDc6LrrrLakOICcJtAootRxdmnC9usQuVLmgCS
RnPB2AgGwskcNS+dg2sfw==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:zOlArsquE3M=;+A0VjoyWeOC5R7oyOJRwiQ7mVao
a2YXFlf+dW+kAj2SsayzTkzooqCwg1bbDha5516sOc59XLaWLPkdEIs8d1CculuUYgY4a9U6H
DRNWLtFJlW0tDTP8A13lD1pzNAeR13v8N4GwXP7HIdLLE8W/3d6RhxU/GFKJ8OrvQGS/ZTuFC
yOT32ZWzvASgVYHkGz66nKn+Yt3ynA/Z2tM+nA1EPZDvqAs4MOrGDYC7VYDldYPwMVSCTd2qN
82GPgipsVufxqlXtfNOXaPSTilIgk8lXV69KiRTo2MzHFW8S42PWXX+VYQs3rEUhLSzOSYMcL
X1sLCTM7LktGuuhAqYRU1Zkg1ko4wSbRgd5p7ceSuHAK5kDrsLg1VjMv0T3nnh2hOF5YB4EKY
qHYiw5PJgeyJloK9qQR1s6K3D2TAz6ogLiCO0VAhdhtKnK79YhiWRN2Twop1rQnG0LSscoNWf
+N1UeALGdJTsIVbNv1VSQN/tGsn/2dtJgtU/4GLHH/zhqw+Ju7NAM7+QScoUgCIUW0fXjydYY
SNkUPKtxlJjQYWeSvdF5UUP4qNmFs0Gn2QMzLLionwE1dOknp4RKP+NvxzZffx4eka+XMWckg
ZAfcx55ABOxb+dLRFLTGSwleZ6GgVBpT0xl4iWgNLtSgaGiF7ji0uhLk5AsnU/zp02Mw25Nhb
2kzPrAsdwbfHfr9XRD0izJrkQILynjP5YA5GH+UFNItLLb2egtZduj0MNbKekk1HK/r0TYwp6
FnKBvR6QeF/ZNpB6sVC/sncx8E+P2FtWf7ZvXj+I30gHa9t7DqSNb1DcD9wHS3s+2Bx2iwGss
/C+3mT/yOK3GrCLZfdpmz3HdXB4dM2RteXpSnq/SDaBro=
Received-SPF: pass client-ip=212.227.15.19;
envelope-from=stephen.berman@HIDDEN; helo=mout.gmx.net
X-Spam_score_int: 5
X-Spam_score: 0.5
X-Spam_bar: /
X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 4.2 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 0. Save the following code (attached here to circumvent line
breaks added by the mail program) as widget-example.el: 1. emacs -Q -l
widget-example.el
2. M-x my-widget-example In the buffer "*My Widget Example*" it easy to see
(due to value of the widget-inactive face set in widget-example.el) that
the push-button widget "Activate" is inactive and the radio-button widgets
l [...] Content analysis details: (4.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,
medium trust [209.51.188.17 listed in list.dnswl.org]
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[88.130.50.228 listed in zen.spamhaus.org]
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (stephen.berman[at]gmx.net)
-0.0 T_SCC_BODY_TEXT_LINE No description available.
2.0 SPOOFED_FREEMAIL No description available.
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: 0. Save the following code (attached here to circumvent line
breaks added by the mail program) as widget-example.el: 1. emacs -Q -l widget-example.el
2. M-x my-widget-example In the buffer "*My Widget Example*" it easy to see
(due to value of the widget-inactive face set in widget-example.el) that
the push-button widget "Activate" is inactive and the radio-button widgets
l [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[88.130.50.228 listed in zen.spamhaus.org]
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/,
medium trust
[209.51.188.17 listed in list.dnswl.org]
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (stephen.berman[at]gmx.net)
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
--=-=-=
Content-Type: text/plain
0. Save the following code (attached here to circumvent line breaks
added by the mail program) as widget-example.el:
--=-=-=
Content-Type: application/emacs-lisp
Content-Disposition: attachment; filename=widget-example.el
Content-Transfer-Encoding: quoted-printable
(custom-set-faces '(widget-inactive ((t (:foreground "magenta"
:background "yellow")))))
(defvar my-radio-widget)
(defvar my-activate-button)
(defun my-widget-example ()
(interactive)
(switch-to-buffer "*My Widget Example*")
(kill-all-local-variables)
(let ((inhibit-read-only t))
(erase-buffer))
(remove-overlays)
(setq my-radio-widget
(widget-create 'radio-button-choice
:notify (lambda (widget &rest _)
(widget-apply widget :deactivate)
(widget-apply my-activate-button :activate))
'(item "One") '(item "Two")))
(setq my-activate-button
(widget-create 'push-button
:notify (lambda (widget &rest _)
(widget-value-set my-radio-widget "")
(widget-apply my-radio-widget :activate)
(widget-apply widget :deactivate))
"Activate"))
(widget-apply my-activate-button :deactivate)
(use-local-map widget-keymap)
(widget-setup))
--=-=-=
Content-Type: text/plain
1. emacs -Q -l widget-example.el
2. M-x my-widget-example
In the buffer "*My Widget Example*" it easy to see (due to value of the
widget-inactive face set in widget-example.el) that the push-button
widget "Activate" is inactive and the radio-button widgets labelled
"One" and "Two" are active (the buttons have the default face; that the
labels next to the buttons have the widget-inactive face may seem odd,
but that's not the bug I'm reporting here; I address that issue in a
separate bug report).
3. Press TAB (or S-TAB) twice to put point on the radio button "Two",
then press RET. As the fontification shows, now both radio buttons are
inactive (so pressing RET on either raises the error "Attempt to perform
action on inactive widget"), and the "Activate" button is now active.
After tabbing to the "Activate" button and pressing RET, the initial
state is restored, with the two radio buttons active and "Activate"
inactive.
4. Now tab up to the radio buttone "One" and press RET.
=> While radio button "Two" agains has the widget-inactive face, radio
button "One" (just the button, not its label) has the default face used
for active widgets, though it is in fact inactive (as pressing RET and
getting the corresponding error verifies).
5. Tab back to "Activate" and press RET, again restoring the initial
state. Now tab to radio button "Two" and press RET.
=> The fontification is the same as in step 4: radio button "Two" has
the widget-inactive face but radio button "One" has the default (active)
face, though it is again inactive. Repeatedly pressing either of the
radio buttons (after activating them), does not change the fontification
of "One" again.
The faulty fontification of radio button "One" also obtains if there is
just one radio button instead of two, and if there are more than two
radio buttons, it is only the first one that displays the odd
fontification (admittedly, I've only test up to three radio buttons).
I've tried to debug this and found that the problem seems to be due to
the sexp (set-marker-insertion-type from t) near the end of
widget-default-create, which advances the marker specified by the
widget's :from property. Changing t to nil fixes the faulty
fontification of the first radio button.
I investigated the history of this code, and while the value t for the
marker insertion type was used in the initial commit, it was changed to
nil in commit e0f956935, with the message "Insert new text at the :from
marker _after_ the marker, not before it." But 18 days later it was
changed back to t in commit 3bff434b8, that also added "Document need to
put some text before the %v escape in :format string" of editable-field
widgets. (I looked at the bug-gnu-emacs and emacs-devel mailing list
archives but found nothing relevant at the time just prior to these
commits.)
So evidently the advancing marker insertion type is needed for at least
some widgets, though it seems to be problematic for radio buttons. So I
tried to conditionalize the choice of t or nil on the type of the
widget. I used (not (eq 'radio-button (widget-type widget))), since the
argument `widget' of widget-default-create is, according to Edebug,
indeed radio-button, so negating the eq sexp returns nil, which I had
found to be the value of the marker insertion type that fixes the
fontification (however, I couldn't think of a way of limiting the
conditioning to only the first radio button, but in my testing so far
that lack doesn't appear to make a difference).
But in fact, using the negation of the value of the eq sexp results in
the same faulty fontification, while omitting the negation (as in the
attached patch), which yields the advancing insertion type t, gives the
correct fontification, just like using nil does. This makes no sense to
me, yet it is reliably reproducible. The only possible explanation that
occurs to me is that the bug is triggered elsewhere in the Emacs code
and somehow using the sexp that evaluates to t as the marker insertion
type affects that code, while using t itself does not (or rather, has
the opposite effect); but how that could be and where the culpable code
is, I don't know (as a guess, perhaps in the C code that adds faces, but
I don't know how to debug that). If anyone knows or has an idea what's
going on here, please communicate it. In the meantime I will continue
to use the widget library with the patch to see whether it has unwanted
consequences.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=widget-default-create.diff
diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el
index 172da3db1e0..c2cd48e1551 100644
--- a/lisp/wid-edit.el
+++ b/lisp/wid-edit.el
@@ -1733,8 +1733,9 @@ widget-default-create
(goto-char value-pos)
(widget-apply widget :value-create)))
(let ((from (point-min-marker))
- (to (point-max-marker)))
- (set-marker-insertion-type from t)
+ (to (point-max-marker))
+ (from-mit (eq 'radio-button (widget-type widget))))
+ (set-marker-insertion-type from from-mit)
(set-marker-insertion-type to nil)
(widget-put widget :from from)
(widget-put widget :to to)))
--=-=-=
Content-Type: text/plain
In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.18.0) of 2024-03-22 built on strobelfs2
Repository revision: c1530a2e4973005633ebe00d447f1f3aa1200301
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: Linux From Scratch r12.0-112
Configured using:
'configure -C --with-xwidgets 'CFLAGS=-Og -g3'
PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER
PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB
--=-=-=--
Stephen Berman <stephen.berman@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#69941; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.