From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#47832: 28.0.50; define-fringe-bitmap and emacs --daemon Date: Wed, 26 May 2021 16:27:37 +0300 Message-ID: <83r1htaaly.fsf@gnu.org> References: <7dee3f4235cf450a3254@heytings.org> <83mttxwgm8.fsf@gnu.org> <1869622e16688e6aedec@heytings.org> <83h7k5w54l.fsf@gnu.org> <83fszpw40t.fsf@gnu.org> <1869622e16c60dc2ce0d@heytings.org> <83eef9w0xd.fsf@gnu.org> <1869622e16270efbc7e8@heytings.org> <87im3778ao.fsf@gnus.org> <83eedvc9jm.fsf@gnu.org> <835yz7c6p0.fsf@gnu.org> <83zgwjar91.fsf@gnu.org> <83sg2bapwj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14023"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 47832@debbugs.gnu.org To: gregory@heytings.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 26 15:28:10 2021 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 1lltZx-0003Te-PV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 15:28:09 +0200 Original-Received: from localhost ([::1]:59420 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lltZw-00042v-Sr for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 May 2021 09:28:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lltZq-00042k-Gr for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 09:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36371) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lltZq-0004gl-9U for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 09:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lltZq-0004CN-5q for bug-gnu-emacs@gnu.org; Wed, 26 May 2021 09:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 May 2021 13:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 47832 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed patch Original-Received: via spool by 47832-submit@debbugs.gnu.org id=B47832.162203566616105 (code B ref 47832); Wed, 26 May 2021 13:28:02 +0000 Original-Received: (at 47832) by debbugs.gnu.org; 26 May 2021 13:27:46 +0000 Original-Received: from localhost ([127.0.0.1]:47917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lltZZ-0004Bh-8H for submit@debbugs.gnu.org; Wed, 26 May 2021 09:27:45 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lltZX-0004BU-Je for 47832@debbugs.gnu.org; Wed, 26 May 2021 09:27:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33920) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lltZR-0004Q0-Rm; Wed, 26 May 2021 09:27:37 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1760 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lltZR-00075M-B0; Wed, 26 May 2021 09:27:37 -0400 In-Reply-To: <83sg2bapwj.fsf@gnu.org> (message from Eli Zaretskii on Tue, 25 May 2021 16:45:00 +0300) 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" Xref: news.gmane.io gmane.emacs.bugs:207288 Archived-At: > Date: Tue, 25 May 2021 16:45:00 +0300 > From: Eli Zaretskii > Cc: larsi@gnus.org, 47832@debbugs.gnu.org > > > Date: Tue, 25 May 2021 13:24:14 +0000 > > From: Gregory Heytings > > cc: larsi@gnus.org, 47832@debbugs.gnu.org > > > > > I'm asking why do we need to process the second kind here. That kind > > > was already set up when user initializations defined replacements for > > > those standard bitmaps. Right? So why do we need to set them up again? > > > > What you write is correct when you call "emacs", not when you call "emacs > > --daemon". In the latter case the user-defined bitmaps have not yet been > > set up. It's explained in the comment: > > > > /* Set up user-defined fringe bitmaps that might have been defined > > before the frame of this kind was initialized. This can happen > > if Emacs is started as a daemon and the init files define fringe > > bitmaps. */ > > OK, but then perhaps we should only do that in a daemon? Or at least > say in a comment there that the second loop does some redundant > initializations except under --daemon. Actually, I still think that either I misunderstand something, or disagree with what you say. So let me step back and explain what bothers me. AFAIR, the original bug was that the call to gui_init_fringe, made when the first GUI frame is created, would overwrite any standard bitmaps that were modified by previous calls to define-fringe-bitmap, because the first loop in gui_init_fringe re-installs the original standard bitmaps. Your original patch then fixed this by making the _second_ loop go over _all_ of the bitmaps, not just non-standard ones: diff --git a/src/fringe.c b/src/fringe.c index 65c9a84ac9..f2b60b5c8e 100644 --- a/src/fringe.c +++ b/src/fringe.c @@ -1783,7 +1783,7 @@ gui_init_fringe (struct redisplay_interface *rif) before the frame of this kind was initialized. This can happen if Emacs is started as a daemon and the init files define fringe bitmaps. */ - for ( ; bt < max_used_fringe_bitmap; bt++) + for (bt = NO_FRINGE_BITMAP + 1; bt < max_used_fringe_bitmap; bt++) { struct fringe_bitmap *fb = fringe_bitmaps[bt]; if (fb) This would reinstate the user-defined bitmaps for the standard ones. I responded saying that the original patch is sub-optimal: And in any case, the patch for gui_init_fringe is sub-optimal: it unnecessarily loops over the standard bitmaps that were superseded. It is better to leave the first loop go over the standard bitmaps, whether superseded or not, and the second loop go over non-standard bitmaps only. Then your modified patch attempted to fix this: diff --git a/src/fringe.c b/src/fringe.c index 65c9a84ac9..47615f51f9 100644 --- a/src/fringe.c +++ b/src/fringe.c @@ -1776,14 +1776,15 @@ gui_init_fringe (struct redisplay_interface *rif) for (bt = NO_FRINGE_BITMAP + 1; bt < MAX_STANDARD_FRINGE_BITMAPS; bt++) { struct fringe_bitmap *fb = &standard_bitmaps[bt]; - rif->define_fringe_bitmap (bt, fb->bits, fb->height, fb->width); + if (!fringe_bitmaps[bt]) + rif->define_fringe_bitmap (bt, fb->bits, fb->height, fb->width); } /* Set up user-defined fringe bitmaps that might have been defined before the frame of this kind was initialized. This can happen if Emacs is started as a daemon and the init files define fringe bitmaps. */ - for ( ; bt < max_used_fringe_bitmap; bt++) + for (bt = NO_FRINGE_BITMAP + 1; bt < max_used_fringe_bitmap; bt++) { struct fringe_bitmap *fb = fringe_bitmaps[bt]; if (fb) With this patch, the first loop only modifies the standard bitmaps that were not defined by previous calls, for example by a previous call to define-fringe-bitmap. But the second loop still reinstalls the standard bitmaps, although they will no longer be overwritten by the first loop. So why should the second loop again start from the first bitmap, when we know that all the standard bitmaps are at that point set up correctly: either by the standard values or by modified user-defined values? If you disagree with my analysis, please describe the sequence of calls that would require the second loop to go over all the bitmaps again, and please describe in detail the effect of those calls on the fringe_bitmaps[] and standard_bitmaps[] arrays. The sequence of calls that I have in mind is as described in the original report of this bug: . define-fringe-bitmap is called in .emacs to modify the standard bitmaps . .emacs is read by a --daemon session of Emacs . emacsclient opens a GUI frame, which calls gui_init_fringe Thanks.