From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#69941: 30.0.50; Faulty fontification of radio button widgets Date: Sun, 24 Mar 2024 19:45:20 +0100 Message-ID: <87wmprqxj3.fsf@gmx.net> References: <87h6gynx49.fsf@rub.de> <865xxe1dwd.fsf@gnu.org> <51c20b56-4b82-4f5c-9559-cdbd0146df22@gmail.com> Reply-To: Stephen Berman Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19547"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 69941@debbugs.gnu.org, Stefan Monnier To: Mauro Aranda Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 24 19:46:55 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1roSrv-0004rp-L2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Mar 2024 19:46:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1roSrW-0001KF-1z; Sun, 24 Mar 2024 14:46:30 -0400 Original-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 ) id 1roSrM-0001JP-SJ for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 14:46:22 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1roSrM-0008BB-Jn for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 14:46:20 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1roSs2-00081e-A7 for bug-gnu-emacs@gnu.org; Sun, 24 Mar 2024 14:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Mar 2024 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69941 X-GNU-PR-Package: emacs Original-Received: via spool by 69941-submit@debbugs.gnu.org id=B69941.171130598030793 (code B ref 69941); Sun, 24 Mar 2024 18:47:02 +0000 Original-Received: (at 69941) by debbugs.gnu.org; 24 Mar 2024 18:46:20 +0000 Original-Received: from localhost ([127.0.0.1]:47412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1roSrM-00080a-3R for submit@debbugs.gnu.org; Sun, 24 Mar 2024 14:46:20 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:39777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1roSrG-00080I-NB for 69941@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@gmx.net; 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 Original-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 In-Reply-To: <51c20b56-4b82-4f5c-9559-cdbd0146df22@gmail.com> (Mauro Aranda's message of "Sat, 23 Mar 2024 17:49:53 -0300") X-Provags-ID: V03:K1:u5xgSeIUyhcZtVjRCnDx7p4HhZSXJ5UpoPYb0SCidWdt5nYDDde fKtEpQOkX/4xmnvL8uiWk9KtKaJ5gcCbYe3oJL3UpGBmlYPy87YNJSTxzekComNJLa2QTwk Xz4Mlqdzdx3tk7tfKnJR3jCl0xIX+CGMJtR4TNooeAOS0Jddg5Zxp/QM/E2lTIPcwNtAUDo VbtkpQ48i1ksXUFQ3XwKA== 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/fdGlKevwFPjvJzukc88Xd664RUQ5Ynkg7jRomVUXJL4uXLU9bRkFvlR8FKyXa X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282029 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, 23 Mar 2024 17:49:53 -0300 Mauro Aranda wr= ote: > Stephen Berman 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) --=-=-=--