Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 12:22:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 08:22:38 2023 Received: from localhost ([127.0.0.1]:49298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLNFN-00017E-RE for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:22:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qLNFL-00016x-NU for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:22:36 -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 1qLNFG-0002hW-CL; Mon, 17 Jul 2023 08:22:30 -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=27XZxaEeKT/VQlfDEtvBCkf9U+BeN61niPqsT/2lrZo=; b=XUyYxoB2XiqN uwad02S6OBAhvKU2KZtE/pv88fcqJM42xMzZpitGz68X+DdRD0JNGHvBUy58KZ8sXeTEROl1/Gqmr sNB7F/XtwHhj8nPIhTL8CklOBP2esFn7Js0KE0zDS2eqCtOnDze92/MHqsBxH8/rhCjZ4EUy0mrQQ +tu7JmNHbXUEJkC+67DMgUPlUCBdUTdCNiEYso7W0mJyyCZwf8cHMTJ6McKgg29MgQfcnkuv/1i6j FEibKzVoV/q8dX6MbPAZ3/1WC8abGew+9HKb27KXywy/EEjkey28gk54xACckcF35iKzumjbbjToc jqEtsZxhIXVliHc5Mq+rgw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qLNFF-0004wm-S8; Mon, 17 Jul 2023 08:22:30 -0400 Date: Mon, 17 Jul 2023 15:22:55 +0300 Message-Id: <831qh6917k.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87y1jeiw8t.fsf@localhost> (message from Ihor Radchenko on Mon, 17 Jul 2023 12:00:02 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost> <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost> <83351m92jl.fsf@HIDDEN> <87y1jeiw8t.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Mon, 17 Jul 2023 12:00:02 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> This does not help the confusion, unfortunately. > >> Or maybe the terms "redisplay" and "update" should be explained better > >> somewhere near the top of xdisp.c. They clearly have different meaning, > >> but not for untrained eye. > > > > "Update" is the general name of the 3rd step of "redisplay cycle". It > > takes its name from the function which enters this step: update_frame. > > May someone then detail these steps in the top commentary in xdisp.c + > highlight that redisplay term is generally used when deciding if we need > to update. It's already in the large commentary at the beginning of xdisp.c (search for "update_window" to find the description of "update"). It just "drowns" in the sea of the information there > And update is an actual process of putting desired matrix onto the > glass. That's a very simplistic description of what "update" does. Even the comment in xdisp.c says more.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 12:00:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 08:00:04 2023 Received: from localhost ([127.0.0.1]:49229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLMtX-0000G2-WB for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:00:04 -0400 Received: from mout02.posteo.de ([185.67.36.66]:53371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qLMtR-0000Ev-RE for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:00:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E64A2240105 for <64596 <at> debbugs.gnu.org>; Mon, 17 Jul 2023 13:59:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689595191; bh=Gt2/0dbjxYafnZodPgMxyAx8tSUafVMTs81ux+1Bxn0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=huwDZmeWcoiwP9bx6bABPKMDXPNwh85kr4X/9lviEEK+F08II+m11rst3sMT3p0sw YMVco+/w0VTpAutW1Vh81Lc+fVHnBOPxD3iuZXaqXb22NEhcrigclq+xfqxUumulvX TTVIY3lH4JsxTAwwpij6ni+Ix1kHM+2t6ZsnXa15sKnf2qs6c9DduSzukeyOqbrAbw 5Rft8f/IsvDsDiyiE/I1/8VIafHD1vYRpUGYx4EzQ91UffFVAi10/ju3orh9qedxGl cIQiQn2rcJFwsoAk6Bbok+zZpk1Sqh7wkP+vSbA1Gu04A9GObPF4sAouFn0zTObovM UjsaDeG0qRzfw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R4LHB45hMz6twS; Mon, 17 Jul 2023 13:59:50 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83351m92jl.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost> <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost> <83351m92jl.fsf@HIDDEN> Date: Mon, 17 Jul 2023 12:00:02 +0000 Message-ID: <87y1jeiw8t.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> This does not help the confusion, unfortunately. >> Or maybe the terms "redisplay" and "update" should be explained better >> somewhere near the top of xdisp.c. They clearly have different meaning, >> but not for untrained eye. > > "Update" is the general name of the 3rd step of "redisplay cycle". It > takes its name from the function which enters this step: update_frame. May someone then detail these steps in the top commentary in xdisp.c + highlight that redisplay term is generally used when deciding if we need to update. And update is an actual process of putting desired matrix onto the glass. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 11:53:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 07:53:53 2023 Received: from localhost ([127.0.0.1]:49222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLMnY-00006N-DJ for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:53:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qLMnT-000067-Dh for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:53:51 -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 1qLMnN-0003rw-Rc; Mon, 17 Jul 2023 07:53:41 -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=+OBqOVDViVeEta57hFN8DMqOn52k76PwHUYCtuCD9nM=; b=Vcr1Ox+4baLP FsKSH1VH4sMuwjMSufqlpuNYZsBoRSqIyfRDUz2RWSdlZDOdVffbcVW8RJSx4WzhTzJMcB5lbt2LE h+tRX4m9/pf+m7uOwqMYRDSmJOwA+wXOunI75mb/BgTtuHRG+budwWVLqjx2E1+MIVcnaJxSfZhsr TPT6vjo8JYY5GwPNiCxlGqpXTtHJkVC7dzd76QbeH74xHcZM5zKtOPALH6TyGRuPmzS+qidiGWy2G KY/4qUdUVf8ezhlw66Ib+KwHg4R2w1K5HN3YuDq+r8pd+EFm9IX9wmaroAkT9RSvJ94Mk801sx91H 9+EvmrXiV91+fgEuzUanaQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qLMnM-00050D-Ut; Mon, 17 Jul 2023 07:53:41 -0400 Date: Mon, 17 Jul 2023 14:54:06 +0300 Message-Id: <83351m92jl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87ttu2zydc.fsf@localhost> (message from Ihor Radchenko on Mon, 17 Jul 2023 09:22:07 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost> <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Mon, 17 Jul 2023 09:22:07 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for > >> > redisplay_window and its subroutines. It is for update_window, which > >> > is the last, 3rd, stage of a redisplay cycle, most of the code of > >> > which is in dispnew.c... > >> > >> I have to say that these flag names are very disorienting. > >> I have first seen this flag while reading xdisp.c, and it was not obvious > >> at all what it does. > > > > Well, update_frame and update_window are the relevant functions in > > dispnew.c, so "must_be_updated_p" kind-of points to them. > > This does not help the confusion, unfortunately. > Or maybe the terms "redisplay" and "update" should be explained better > somewhere near the top of xdisp.c. They clearly have different meaning, > but not for untrained eye. "Update" is the general name of the 3rd step of "redisplay cycle". It takes its name from the function which enters this step: update_frame.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 11:19:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 07:19:48 2023 Received: from localhost ([127.0.0.1]:49138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLMGZ-00056K-MX for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:19:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qLMGX-000564-63 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:19: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 1qLMGQ-0003OS-QO; Mon, 17 Jul 2023 07:19:38 -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=NCBsiLfVDzxZZsYm25kKVof6D4AUH33s4tgjBswGl4Q=; b=Zq0Q80HCbbjN uZNE5A6jTUTRiZTRd2muZ0KHDftMndTy9RxbOLH9OV/7NmqCJE7H08fmepe819UevRPhE1LqpX0Wh vVK3iyF29uUR5AzbrggKej3Jo6aftfjkiz2Tck88Y0JYPWPCJFjbWFoyrgYi8gqDOWhiEaNsQ72lc Vv9DsXC36A86QiS5NQaUK3XFyCimiAGydNztv61xKmJZ0BA7matwWzfnoltKMEJeQ+PD99JRfpaWo ImOPqwyWGIyjfdGXjBWISKY7EmlhsRGoSDf1Kk9x3pOCvWvfWOl7P5gyY0QTFoipNq5QIKEUUwBSK 0MW3hyB+Oxr34yR5EPiGfQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qLMGQ-00052q-AD; Mon, 17 Jul 2023 07:19:38 -0400 Date: Mon, 17 Jul 2023 14:20:04 +0300 Message-Id: <838rbe944b.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 16 Jul 2023 18:19:57 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN> <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN> <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN> <83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN> <83edl78yly.fsf@HIDDEN> <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 18:19:57 -0400 > > > That's not all of the uses of this flag. Here's one example of other > > uses: > > > > if (some_windows > > && !f->redisplay > > && !w->redisplay > > && !XBUFFER (w->contents)->text->redisplay) > > continue; > > > > (This avoids updating the tool bar and the tab bar of the frame, and > > there's a similar condition that avoids updating the frame's title.) > > Right, but notice that what we're fundamentally checking is whether `w` > (which is the frame's selected window here) needs to be updated, because > that's the one currently "occupying" the tool-bar. But testing the frame's redisplay flag will produce false positives, because many changes that require to redraw the frame's windows don't affect the tool bar or the frame's title. > FWIW, I don't know why we don't also check > `XBUFFER(w->contents)->redisplay` here. We do: if (some_windows && !f->redisplay && !w->redisplay && !XBUFFER (w->contents)->text->redisplay) <<<<<<<<<<< continue; > Also, I still don't see why that makes you think: > > frame's redisplay flag is what causes us to consider a frame in the > first place. > > Indeed, a frame's redisplay flag may be such a reason, but a window's > flag or its text buffer's may be the reason instead. A frame's > `redisplay` flag does not need to be set for us to consider it. No, my point is that fset_redisplay shouldn't set windows_or_buffers_changed.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 09:22:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 05:22:04 2023 Received: from localhost ([127.0.0.1]:49078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLKQe-0001cC-86 for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 05:22:04 -0400 Received: from mout01.posteo.de ([185.67.36.65]:60083) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qLKQb-0001bh-Un for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 05:22:03 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 0BA6124002B for <64596 <at> debbugs.gnu.org>; Mon, 17 Jul 2023 11:21:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689585716; bh=gb8iJYc6cj1lH247gUq33hrfvzYKt55dm+11CD7z0z8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=mUKpgS5v203C4B/TfYYSQTsP/v1cDoA+SE/AutjGJkfsG8meGw/PcuHW985wmK1Gk Tz0aItHsMECYMjmv6XCPrABLlxzW/XE93nhukx3dNFUF6SjmCowFwTP/8wPGmyRJNU MjI0fjwQx1TCfo5c6lWJRE/yx6cF/Zf2o+/B3UPfmtkeUE/RI06m5FpKmq6F8Ntb5r WfeYet1ooe3BhXolIC/15xNRNyllm2URXFbCBG5/U1GTY+JorO4rrEgKgTzvtS7jXI lWs0M/gmuysHUsR0rMc12ZEQbz6vNrjteZiQBJDp8YK3HVzma+SF4L/KikQ4xM3LZo 30cAgzdJH9vsA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R4Gmy6l7dz6ty2; Mon, 17 Jul 2023 11:21:54 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83a5vv8edp.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost> <83a5vv8edp.fsf@HIDDEN> Date: Mon, 17 Jul 2023 09:22:07 +0000 Message-ID: <87ttu2zydc.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for >> > redisplay_window and its subroutines. It is for update_window, which >> > is the last, 3rd, stage of a redisplay cycle, most of the code of >> > which is in dispnew.c... >> >> I have to say that these flag names are very disorienting. >> I have first seen this flag while reading xdisp.c, and it was not obvious >> at all what it does. > > Well, update_frame and update_window are the relevant functions in > dispnew.c, so "must_be_updated_p" kind-of points to them. This does not help the confusion, unfortunately. Or maybe the terms "redisplay" and "update" should be explained better somewhere near the top of xdisp.c. They clearly have different meaning, but not for untrained eye. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 08:30:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jul 17 04:30:40 2023
Received: from localhost ([127.0.0.1]:49020 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qLJcu-0008BU-8X
for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 04:30:40 -0400
Received: from mout.gmx.net ([212.227.17.22]:44757)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <rudalics@HIDDEN>) id 1qLJcq-0007mW-7o
for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 04:30:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at;
s=s31663417; t=1689582625; x=1690187425; i=rudalics@HIDDEN;
bh=RW3Dfxm+BcU5w8WgAuokLAKH42vd3tkBjuZ17YjU4AU=;
h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To;
b=UrMVDPqqKGfDNbbKdsrTKBUMOGkHUJ5ePZPJPBdCHgfdO4mbYbXigK/XQ/qKXsDr6hhbdnf
Lz+WLTiizldrv7GuPUELfiioLxG/2ZE9l8ck4TEQqdZsDvvPfcz5f/cu/t93026akW6ary67I
FwO2LM1ihLQy/Zr6Ky/7279y+ccsA6Je76tImkqEqSccxrUgPaFADFd8GaFWupVZgFPTGU2MC
3JzcraqKKiVYU28WvBYMe3dnqiT2Tpx2QsJWL9gZX0oZya42M3Hx34Yhaj/RUvMifq/LTbr+F
oxkpHQvKLJQxVVkPXyQ6sMofVty6BLckWSTOi1Yn43VhCIzCqAaQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([46.125.249.31]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1Mxm3K-1q0jXj1zjC-00zJMC; Mon, 17
Jul 2023 10:30:25 +0200
Message-ID: <edfda92f-91c4-5c7b-ec32-5ca486a28eaa@HIDDEN>
Date: Mon, 17 Jul 2023 10:30:23 +0200
MIME-Version: 1.0
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
<jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
<jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
<jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
<877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
<682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <83fs5o9r5l.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <83fs5o9r5l.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:g/lqA41Wg46TV5QKcKk0ATukofKczgB1Xlx43QkB5nyIfXDdLGB
G+Y1YqYEVypiimZbzKpLAHCKVwAlYInXlhb9GBRbR9RgzdULz4puAO0ZwI8PeFkHrDhIYpa
6RmDD5m8cg0w2CcwY2CoQ9ys9XLF9TBbOdQvZJri/dLrH8UqA5QA5soQh7K64Z+9Xu63Ejw
+4yFGS+HCCuXyWghi1epQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:B0DGzwH/Mbc=;rWqhcpUfGU1VQxQQdNHGDOdsBJm
5YniWqzIv9suwBXSOE7RTZ5dxkPhhJNw631irX/ONdcXXhsLwNfgeXyuGtAnDdhEls709ZmGG
NOF+IrsLLVdr9Kdeik6B+zczNfeasl2+WMSuesSDgIm0MMl7J5URp18TFiiEt0OB/IorzpliJ
yLhKn/nNqKYbH6WA81OWrZE44+b4Q5WtVyEeckeW8P1Velj1pLcIO0EvlrLUHqK2oUWAlNMGu
+vBoqJJwdHqCG7LonjI8dA2aLmUapRSU+3DqlwGne5D/c3H04l3kiBffvrLl+3FyUch2Xbrw6
nJXUsOkHM3oE9iHOpWWT9Pj6FllTJ5/bLHwBkKomX6nuzTaYZtuqFhLp9oNtjjIlXvZxO9kuZ
Y5IEi9TvGnaKZ/ABtOtPF0LYiYvsD87o+IsqhVzUgyRHALEtNrjVArJZERzUf6k1vOMovE/yk
d8TyDEBb4VAIpkyN+xlvX4r8fVz0LevrU+IFVgjtxnyLzzN9dXwFr/DlSF3l4TCQxDhxmT4WM
ZRrie3KKC2Lq4nr/yeD+c6U8oQ4MOEcm/VvbnN4asYaeSc3T2YG30o8fYW4Qcjry6XhX3aB0S
1xoOZbzSDBLseZdUekHaloRwL4YfknYXvIfO/yau6ysA+TbU2hFasTujP4EIWVryHRAceOhPU
dGKZ/+00mdGIpC3NTtVtIqYyt3yv6yRHY1soiC2ogqZGQv6FRgbnDFbvSF9Bo4qiEYOWrq8HO
j9UzCxBuUULmqssUSPQjRXN+6vz7UAjS6QarcAaLUun6o8BAwhsELbAxu5t8811WMzArRQoMG
h8rig6+1M1PBB5hFKJdlIsk0x002rQvnODB2XtPi/pzTTlos8L++riVberAfHchWJs/MTMBVO
eCuECIOFeIpMvtJB0bLVwHQURR7gXLlA9GY9hwT0NGApDbP9/52jZ+A6ZHGcngT49niPF61hN
RJ/0RezGcDWiCHbR418bgjvaZIU=
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: > The information flow is > unidirectional: the functions
which change the windows should tell > what they changed, and redisplay will
then decide what that requires. > For example, if some windows c [...]
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
[46.125.249.31 listed in zen.spamhaus.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust [212.227.17.22 listed in list.dnswl.org]
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, monnier@HIDDEN, 64596 <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: 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: > The information flow is > unidirectional: the functions
which change the windows should tell > what they changed, and redisplay will
then decide what that requires. > For example, if some windows c [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
[46.125.249.31 listed in zen.spamhaus.org]
-0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/,
low trust
[212.227.17.22 listed in list.dnswl.org]
-0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[212.227.17.22 listed in wl.mailspike.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (rudalics[at]gmx.at)
-0.0 T_SCC_BODY_TEXT_LINE No description available.
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
> The information flow is
> unidirectional: the functions which change the windows should tell
> what they changed, and redisplay will then decide what that requires.
> For example, if some windows changed their dimensions, redisplay would
> need to know which dimension changed.
The window code should have all necessary information at hand (but for
the final height of the mode lines) when redisplay starts but would have
to know what redisplay wants it to tell. It would be easy to reserve
one bit on each window to tell that its width, left scroll bar, left
margin, left fringe, body width, right fringe, right margin, right
scroll bar or the height, header, tab, mode line, body and scroll bar
height changed. And one bit for each of font, line spacing, start and
point position and the scrolling statuses of the window. Maybe also one
bit for the left and top edge within the frame and the left and top body
edge of the window.
Once it has been established what redisplay wants to know, it would be
easy to transfer practically all notifications currently performed by
frame.c to window.c. That is, gui_set_left_fringe would no longer
SET_FRAME_GARBAGED because the window code would decide whether the
width of any left fringe of any window affected should really change and
set the left_fringe_width_changed, the body_width_changed and maybe also
the left_body_edge_changed bit accordingly.
In addition there would probably be one window_changed bit per window to
tell redisplay that one of the bits above changed and one frame_changed
bit to tell redisplay that at least one window has its window_changed
bit set. Then we probably should try to remove any special treatment of
the selected window in this regard, since with all our excursions, code
can never tell anyway which window will be the selected one at the time
redisplay starts.
Finally, redisplay would have to merge in all buffer text and position
changes for each window showing that buffer mostly as it does now and
separately consider a few frame changes like visibility.
Information flow would still be bidirectional for the mode lines: As
soon as redisplay has calculated their respective heights and these
should change (a rare case), the window code would have to be informed
about that, store the new heights, adjust the body height, recalculate
scroll bar dimensions and leave it to redisplay to decide whether to
calculate mode line heights again to avoid infinite recursion.
martin
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 02:23:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 22:23:33 2023 Received: from localhost ([127.0.0.1]:48775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qLDtc-0004JM-TV for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 22:23:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qLDtX-0004J6-On for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 22:23:31 -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 1qLDtS-0000Xn-7b; Sun, 16 Jul 2023 22:23:22 -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=ZNpJd8yFIarfrv30WEjSX53CLHu/yzOB+DM9eyYdK4A=; b=n/UVdt5X2M2T IY2qQiPTEe/8lxmr71Arcf4heMGW3EPBrC2rjOKsK7fnPpYWRnfxiAPbGijAQKItq5InclHn1JzW5 g48KtbhEIsgp9zLjGXH+KnfdYB83iah32uISLCdZCFX/JxVFuEaeaVN0Xi2V14f85X/Iy3WQR280E yvfqUi//MZ5054dcXNCIjIjGd/BjKfEbEP6hZDiJQvH0nG3vZxO3E88a2tm2AsvsQAcFBSUw803QI 2pm5KGdQHPaF/QzvbmwXvHJyVKl7Y7xDMUSEnFJuAr8K97dKiJ+sNBUA9S/dlGeUYPSqGhS2nXyjw DR9pw4Y7pjimu6wru8gegA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qLDtR-0000xT-So; Sun, 16 Jul 2023 22:23:22 -0400 Date: Mon, 17 Jul 2023 05:23:46 +0300 Message-Id: <83a5vv8edp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87jzuz1uq5.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 20:12:34 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 20:12:34 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for > > redisplay_window and its subroutines. It is for update_window, which > > is the last, 3rd, stage of a redisplay cycle, most of the code of > > which is in dispnew.c. That's where the newly computed glyph matrix > > of a window is compared to its current matrix, and Emacs decides what, > > if anything, should be actually written to the glass. What happens > > with this flag is that redisplay_window and friends _set_ this flag > > for windows that dispnew.c _must_ update. The flag is tested in > > dispnew.c, see there for its use and comments. > > I see. > > I have to say that these flag names are very disorienting. > I have first seen this flag while reading xdisp.c, and it was not obvious > at all what it does. Well, update_frame and update_window are the relevant functions in dispnew.c, so "must_be_updated_p" kind-of points to them.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 22:20:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 18:20:07 2023
Received: from localhost ([127.0.0.1]:48714 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qLA63-0006iQ-3w
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 18:20:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48980)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qLA60-0006hn-QN
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 18:20:06 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 86C981000C4;
Sun, 16 Jul 2023 18:19:59 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 96E09100097;
Sun, 16 Jul 2023 18:19:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689545998;
bh=LfJ/rb0myeZg6oAhsDPyxICFqd79PENcJ9RuaI/V8Dc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=GINk6S3Q5kuw598mudQo4pomFfqkuoP5nlifgXIdQynzfj9qioizXb4rO/KJkFelz
5p+tuvhhBax3ig/h65JcwdC4xrGEJKbyHpH0oYxT/qdk00p7s8dxhr+Rs8l6vrQ4DQ
3Cey54oFOXp2HE0cm+C1GtA+hOkIWqu1YmOTqS7V4FmWtQEOoCHqHzyGQrVUrmmjQ/
0nbJnu/le4B7PWKbHZKlF/4jKD+vO93i9fHirZ3em9c+Fd8yIaAvoQY9SAbUxCWExs
g/9HzOamrUlI7ct9IMWD8FPm0U2PWblyXuomaE234AQkKMmT0vuA0yFGWtJmB7GSPX
+axCr9Ro/6rMQ==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68A101202B9;
Sun, 16 Jul 2023 18:19:58 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83edl78yly.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
2023 22:06:49 +0300")
Message-ID: <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
<83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
<83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
<83edl78yly.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 18:19:57 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.182 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> That's not all of the uses of this flag. Here's one example of other
> uses:
>
> if (some_windows
> && !f->redisplay
> && !w->redisplay
> && !XBUFFER (w->contents)->text->redisplay)
> continue;
>
> (This avoids updating the tool bar and the tab bar of the frame, and
> there's a similar condition that avoids updating the frame's title.)
Right, but notice that what we're fundamentally checking is whether `w`
(which is the frame's selected window here) needs to be updated, because
that's the one currently "occupying" the tool-bar.
FWIW, I don't know why we don't also check
`XBUFFER(w->contents)->redisplay` here.
Also, I still don't see why that makes you think:
frame's redisplay flag is what causes us to consider a frame in the
first place.
Indeed, a frame's redisplay flag may be such a reason, but a window's
flag or its text buffer's may be the reason instead. A frame's
`redisplay` flag does not need to be set for us to consider it.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 20:12:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 16:12:35 2023 Received: from localhost ([127.0.0.1]:48636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qL86c-0003Li-TQ for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 16:12:35 -0400 Received: from mout02.posteo.de ([185.67.36.66]:52787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qL86Z-0003LQ-HW for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 16:12:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 60346240103 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 22:12:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689538345; bh=sW3T6KA74iidfobHcIckChVUfHvLqjpWpeGbPxHrZd4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=RDq7RhXp4wzVnmw/TEFcpSNBEcnFmpN4Mz+pMP7KgJUOqdEi9TmCsKFhPG/NHqA8f +gFu2YnKw7/NnpYG1vG5E1RT3aBkVXUk6K5SNrTIhoI5O0ber8lnjGPu7zeAAAm0B+ pxY19h0awc2w+KYkHSaHsQsOa20bTVU2FM9RbFWAvhtlInlSINqSL7Q2g/EVhNZnVT fFhyaX7SIWLM5LSLvGuKQvWi4eAJ/Jwt4EXhWVWm/KF9jh9ICkkdmJxht9PQHr6Coj 7E925nR5r/lbJMKnTWsNWB/KXfJ6o9E/eyjcjexlAVrJXyGj6Uwp6o9vSEMZtDeGkO npz1rnlqetYVw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3xG043c2z9rxL; Sun, 16 Jul 2023 22:12:24 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83bkgb8xo5.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@HIDDEN> Date: Sun, 16 Jul 2023 20:12:34 +0000 Message-ID: <87jzuz1uq5.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Ihor Radchenko <yantar92@HIDDEN> >> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org >> Date: Sun, 16 Jul 2023 10:22:38 +0000 >> >> Stefan Monnier <monnier@HIDDEN> writes: >> >> >> . prevent_redisplay_optimizations_p flag of a buffer >> >> . must_be_updated_p flag of a window >> > >> > No idea what these mean. >> > The name `must_be_updated_p` makes it sound to me like it's redundant >> > with the `redisplay` flag above. >> >> I agree about must_be_updated_p. I had exactly same though that it is >> redundant with redisplay flag when reading the code. > > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for > redisplay_window and its subroutines. It is for update_window, which > is the last, 3rd, stage of a redisplay cycle, most of the code of > which is in dispnew.c. That's where the newly computed glyph matrix > of a window is compared to its current matrix, and Emacs decides what, > if anything, should be actually written to the glass. What happens > with this flag is that redisplay_window and friends _set_ this flag > for windows that dispnew.c _must_ update. The flag is tested in > dispnew.c, see there for its use and comments. I see. I have to say that these flag names are very disorienting. I have first seen this flag while reading xdisp.c, and it was not obvious at all what it does. The name must_be_updated has no link with glyph matrix terminology, and it is only explained in the commentary in window.h. But then, at the point of reading commentary I was not yet familiar with xdisp... -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 19:26:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 15:26:51 2023 Received: from localhost ([127.0.0.1]:48603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qL7ON-0002A9-Hh for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:26:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qL7OL-00029v-07 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:26:50 -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 1qL7OE-00080D-5u; Sun, 16 Jul 2023 15:26:42 -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=AMtrYx7FMM516/INED63gKFEJuadvCVYYU2J9xCwfbc=; b=cMDxVrWvCdMI IS278VNvaxh7d53lyO4tYECNVxcZG6TwZ/KR41b366PyB7QLzWZ+E1yPPcULL5TS6/dKYHt8y2C1W 7R1jHiBiGNT4bn9ugsjY7RILgVzJILuZok2sMnSXDuzYJJSjpKikiqR3HpcZtxR4ZisQ+HYYRsbKS xUPMiZ07I6MNmoJAc07JTXLkWjDq+WwOMncKZnPoa7E6ffd5etp58ofFCVYEM6uj6TJ7wtooI0Zgf pnblst+JkbqpeMlbZsGXoY3Gn4vOCJQr8bEpajSi8oZDr9KLz/BluBeiGGPPPpvhlqmqeJKGLz5sq ydSunfFkRaVGp5QVkRYGkA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qL7OD-000690-MG; Sun, 16 Jul 2023 15:26:41 -0400 Date: Sun, 16 Jul 2023 22:27:06 +0300 Message-Id: <83bkgb8xo5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87ttu4gnpt.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 10:22:38 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 10:22:38 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > >> . prevent_redisplay_optimizations_p flag of a buffer > >> . must_be_updated_p flag of a window > > > > No idea what these mean. > > The name `must_be_updated_p` makes it sound to me like it's redundant > > with the `redisplay` flag above. > > I agree about must_be_updated_p. I had exactly same though that it is > redundant with redisplay flag when reading the code. Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for redisplay_window and its subroutines. It is for update_window, which is the last, 3rd, stage of a redisplay cycle, most of the code of which is in dispnew.c. That's where the newly computed glyph matrix of a window is compared to its current matrix, and Emacs decides what, if anything, should be actually written to the glass. What happens with this flag is that redisplay_window and friends _set_ this flag for windows that dispnew.c _must_ update. The flag is tested in dispnew.c, see there for its use and comments. So it was wrong for me to include that flag in the list which started this sub-thread. Sorry about that.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 19:06:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 15:06:42 2023
Received: from localhost ([127.0.0.1]:48598 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL74p-0001iP-D8
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:06:42 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60312)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qL74h-0001i6-5J
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:06: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 1qL74b-0001Ww-MP; Sun, 16 Jul 2023 15:06:25 -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=PDbHjc83tXtd0LmMg9fxHlVZNtO7C9e5wfc8zIY9Bi8=; b=buZBFE152KOQ
MfOiB6RMhpjOX+/viveExuo3YPKP7HzOscytqa19xrjvEj+Imv0HXWrh8DovH6tS0lYljFq3hapVo
gmmSsvVpsGLhZ6hXWN3w6YL0MeM/uhbYpELUmvXfANBGMV3hKgdwpDHR9HQCax3nwhbpTyWNmGmO8
itEry8skle7Dh/GEejEA/wVhVZY8GTspPuCjysWxDRralX8ZyvYFdZa4nHZd1HvDbzmQRGsDpoT9Q
3iqC3esTIC/kASbQhK4NWKoHdV8l5W63xZuLC1rmc/pnQE9RSxL4ofFlt8+OZ/30Co0RWHUwBasyj
0BXiFi5cZ71eDFMty6Y/PQ==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qL74b-0003tk-6f; Sun, 16 Jul 2023 15:06:25 -0400
Date: Sun, 16 Jul 2023 22:06:49 +0300
Message-Id: <83edl78yly.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sun, 16 Jul 2023 14:53:03 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
<83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
<83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 14:53:03 -0400
>
> >> Hmm... I'm not sure why you're saying
> >>
> >> frame's redisplay flag is what causes us to consider a frame in the
> >> first place.
> >
> > Because fset_redisplay does this:
> >
> > void
> > fset_redisplay (struct frame *f)
> > {
> > redisplay_other_windows ();
> > f->redisplay = true;
> > }
> >
> > and redisplay_other_windows sets windows_or_buffers_changed, which
> > then causes consider_all_windows_p to be true upon the next redisplay
> > cycle:
> >
> > consider_all_windows_p = (update_mode_lines
> > || windows_or_buffers_changed);
>
> Yes, most calls to `[fbw]set_redisplay` will call
> `redisplay_other_windows` and once that function has been called, all
> the frames will be "considered", but that happens regardless of the
> `redisplay` bit of any particular frame.
If we always set these flags by calling these functions, then we will
end up doing more in redisplay than needed, because update_mode_lines
and windows_or_buffers_changed also disable certain optimizations.
When someone writes code that calls fset_redisplay, he or she are
likely to think that all this does is set the redisplay flag. Which
is not true. If every call to fset_redisplay indeed needs to disable
those optimizations, we should have more flags, and should probably
not call the function fset_redisplay, but something else.
> The `redisplay` bit is consulted later, once we loop over all the
> windows in all those frames, where we decide which of those windows are
> updated depending on the `redisplay` bits of the window, the window's
> buffer, and the window's frame.
That's not all of the uses of this flag. Here's one example of other
uses:
if (some_windows
&& !f->redisplay
&& !w->redisplay
&& !XBUFFER (w->contents)->text->redisplay)
continue;
(This avoids updating the tool bar and the tab bar of the frame, and
there's a similar condition that avoids updating the frame's title.)
> Are you maybe confused by the name of the `FRAME_REDISPLAY_P` macro,
> which does *not* pay attention to the `redisplay` bit?
No, I don't think I'm confused about that.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 18:53:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 14:53:13 2023
Received: from localhost ([127.0.0.1]:48578 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL6ro-0001OJ-TD
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 14:53:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54614)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qL6rm-0001O5-J6
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 14:53:11 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 10EAC803B1;
Sun, 16 Jul 2023 14:53:05 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EBAA780057;
Sun, 16 Jul 2023 14:53:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689533584;
bh=yKmtTpMO3CJ5SfUn6QmpjwHQQ7wevZzWwIvBpf2mSj8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=agMPKG4pnAGYaEa3CaNxGjA05GRAXxVdNNmX0NfRaASlBd47a2a9naXL1t4SZMnbu
efrwl99hbFFxVb3K13lnKI2M6u+fbOJCV0NaEpPvH5hKKxv1kPCcdpznj/Zz+abrBY
FGvQ1NoUbJnBj/InDfg5NjIbpRVA92NKvIz+F8eR1RymB/a+yKDDxjkl8ijU9Rjowm
XMNMvkBLRHY1FS08vOMVo/6K/BWqGLZWqbAzyPkQq8iVRdlvMnLm76iiyvelNNy82r
AaRo8oM41zwxeE79Ur+cL61p+8vSoYjwCGb9I3PWPj2TJfyZIbzkANDkdPxv1RV6Q3
h4Y/ZuJtTEmOw==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BF59D12031C;
Sun, 16 Jul 2023 14:53:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83mszv93yb.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
2023 20:11:24 +0300")
Message-ID: <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
<83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
<83mszv93yb.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 14:53:03 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.042 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
>> Hmm... I'm not sure why you're saying
>>
>> frame's redisplay flag is what causes us to consider a frame in the
>> first place.
>
> Because fset_redisplay does this:
>
> void
> fset_redisplay (struct frame *f)
> {
> redisplay_other_windows ();
> f->redisplay = true;
> }
>
> and redisplay_other_windows sets windows_or_buffers_changed, which
> then causes consider_all_windows_p to be true upon the next redisplay
> cycle:
>
> consider_all_windows_p = (update_mode_lines
> || windows_or_buffers_changed);
Yes, most calls to `[fbw]set_redisplay` will call
`redisplay_other_windows` and once that function has been called, all
the frames will be "considered", but that happens regardless of the
`redisplay` bit of any particular frame.
The `redisplay` bit is consulted later, once we loop over all the
windows in all those frames, where we decide which of those windows are
updated depending on the `redisplay` bits of the window, the window's
buffer, and the window's frame.
Are you maybe confused by the name of the `FRAME_REDISPLAY_P` macro,
which does *not* pay attention to the `redisplay` bit?
> IOW, this is not just a matter of exposing a small number of functions
> to Lisp, IMO.
I'm sorry if I made you think I suggested it would be a simple matter.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 17:19:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 13:19:48 2023 Received: from localhost ([127.0.0.1]:48499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qL5PP-0004Zb-VD for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:19:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qL5PO-0004ZQ-FY for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:19:47 -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 1qL5PI-0005iD-5m; Sun, 16 Jul 2023 13:19:40 -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=KtZevbWlsK+q6I7ulIyHKFSkqEt2YBqr7Y56Ri447lQ=; b=e+1iQYrMPRnR eP1HhifGDrWb4mhwWKowKL5zCzFLvQzo032Iqb4yJv7dILjkIw4wsctUxjnS7PcUQAtEVHMX7HALX 1QrmXQ2wxitlwpRTEMFZi8ulSgGAotg2ocSatZk5y1DgDJdUkUUI7RFPKKY8q/zXZQQ96f7NPLWq8 S91Fr6lxDUquLOPe18T95fsMo0hkvWTHXC7pk0nx1V+tT1kbadlUlxI0EbI1TuXoMakYXI1bY4iKX 8+n2QOj8disxcfwlf721nd+dUxpgzdVVwX4FoWuahYFfFtQLOCye6oNAMHxKblAOJ98IndCo2OLo7 2iuJDm9sXKZwSeU3D5Fi5g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qL5PH-000764-HY; Sun, 16 Jul 2023 13:19:39 -0400 Date: Sun, 16 Jul 2023 20:20:04 +0300 Message-Id: <83ilaj93jv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: monnier@HIDDEN In-Reply-To: <83mszv93yb.fsf@HIDDEN> (message from Eli Zaretskii on Sun, 16 Jul 2023 20:11:24 +0300) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN> <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN> <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN> <83mszv93yb.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 20:11:24 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > > But if you want to be able to tell redisplay "update only this window > > > and nothing else", I think it should be easy to accomplish by adding > > > a single function and no other changes: all you need is to call > > > 'redisplay' (which is already exposed) after setting the redisplay > > > flag of a single window. Another easy-to-implement idea: give redisplay_internal a list of windows in the order you want them redisplayed, in which case it will follow that order instead of the current depth-first order implemented by redisplay_windows.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 17:11:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 13:11:25 2023
Received: from localhost ([127.0.0.1]:48483 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL5HJ-0004MU-AW
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:11:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40052)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qL5HF-0004MF-MC
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:11:23 -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 1qL5H9-0003B1-6V; Sun, 16 Jul 2023 13:11:15 -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=za777tUu9XN7z6MU2nJrtc+W3AqV2/F/R3aG40buUGQ=; b=huFp+H8EDyJt
rGxjChgH8H994kDldky5ktzJSBHmmJD+qZNLbMQP3fWYUghcrWqkGr2BUU6nOXqSN5smO0UY6HGM8
l4TuJHwNaQwgX3Ck2IRrR6xi99nRhT81VhAhg+t2gmYHP6UtCwHnOJDy16n96RlhcjhMspmM94WWM
VcImLc+X/s6we6t1FYOtqNS8A3NoKjjkbgtLGYrI7Cr3o8WfS1ygOCorI+8cChA8Ic3SbaRHMdrLk
W4lu7luXoES/OU45O5FYKem1h283xa+dLiZbLuw17V2IyDwfpap2SQOdRnWQ1YVG7tgL3GTRfbg5d
fxgd5/PO5IpeeopaSpczhg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qL5Gu-0006Jt-Ju; Sun, 16 Jul 2023 13:11:14 -0400
Date: Sun, 16 Jul 2023 20:11:24 +0300
Message-Id: <83mszv93yb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvsf9n969o.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sun, 16 Jul 2023 12:44:08 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
<83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 12:44:08 -0400
>
> > 1a - decide whether all the windows need to be considered, or just
> > the selected window
> > 1b - if all the windows need to be considered, decide for each frame
> > whether it needs to be considered, and if so, consider all of
> > that frame's windows
> >
> > Considering a window can sometimes decide very quickly that the window
> > doesn't need to be redisplayed, but, as I mentioned elsewhere, when
> > its frame's redisplay flag is set, we never decide that, and the
> > frame's redisplay flag is what causes us to consider a frame in the
> > first place.
>
> Hmm... I'm not sure why you're saying
>
> frame's redisplay flag is what causes us to consider a frame in the
> first place.
Because fset_redisplay does this:
void
fset_redisplay (struct frame *f)
{
redisplay_other_windows ();
f->redisplay = true;
}
and redisplay_other_windows sets windows_or_buffers_changed, which
then causes consider_all_windows_p to be true upon the next redisplay
cycle:
consider_all_windows_p = (update_mode_lines
|| windows_or_buffers_changed);
> If the redisplay toplevel could be hacked in ELisp, follow-mode could
> call the `update-window-glyph-matrix` on the "main window" of its
> window-set first, then get the resulting window-end/start and use that
> to adjust/scroll its next/prev windows, and then call
> `update-window-glyph-matrix` on them, thus propagating the information
> in the right direction and avoiding unnecessary redisplay computations.
>
> > But if you want to be able to tell redisplay "update only this window
> > and nothing else", I think it should be easy to accomplish by adding
> > a single function and no other changes: all you need is to call
> > 'redisplay' (which is already exposed) after setting the redisplay
> > flag of a single window.
>
> That won't avoid redisplaying the other windows whose `redisplay` bits
> had been set already for other reasons.
Yes, it will: when a window is redisplayed by redisplay_window, its
redisplay flag is reset, and it will not be redisplayed during this
cycle. So if you have a way to redisplay a single window, you can do
that in any order you want, one window at a time, and those windows
which you redisplayed in this way will not be redisplayed until the
next cycle.
As for update-window-glyph-matrix, I don't see why that would help,
because updating the matrix without calling update_window fairly soon
after that will not produce the effect that you want.
> I guess we could try to "save the redisplay bit" of other
> windows/buffers/frames, and restore them afterwards.
What for?
> Also, it would be good to be able to compute the glyph matrices of
> the various affected windows before we do the actual glass update
> (especially if we want to handle iteration where some part of the
> redisplay (e.g. jit-lock, evaluation of mode-lines and menu bars,
> point moving out of scope forcing a scroll, you name it) causes
> changes which require recomputing a glyph matrix we just computed).
Sounds like an unnecessary complication to me, and for some situations
I'm not even sure how you can handle them, unless you thoroughly
redesign the display code.
IOW, this is not just a matter of exposing a small number of functions
to Lisp, IMO.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 16:44:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 12:44:18 2023
Received: from localhost ([127.0.0.1]:48445 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL4r4-00010W-2X
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 12:44:18 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63451)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qL4r2-00010G-03
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 12:44:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ADC54805BA;
Sun, 16 Jul 2023 12:44:10 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 61EFC8044C;
Sun, 16 Jul 2023 12:44:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689525849;
bh=PyVCZqLJQk5HeInVemtP2RyftT+JSA1sBmBQ2a1Rz8M=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=NdDqaZWctgu3w6R5RjtunIGfT65LLDhN8lPJfZToA9gXaweOSfQnCwdX+koVgl7N7
T/u0ZGdkGgAJjgXhUk2X4MtTGvnkEBMlnupv1et30YwJDmGPpFnDF05GtP/1W3JHxE
RYgtI2I9SLI9DJLnXOwZkfuEDAzYNVlm7snz1/dKQCMAyzphgZ9p9ivAAQ1JmlcS7Q
On0UEYj/X9tsuEdIhgeLGgCeJIZMfx6yrIOi37dtaDSEZ/gCx8JooKl5o6GzGw8/jx
Jh8DwdPwQ+Xd1otReW7CLDmP6QSgAUJq2l+I97LsMxQikT4eIH4yfAKpr1cxAGF6kh
ow6oeE4T5Wdeg==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B21C1202B9;
Sun, 16 Jul 2023 12:44:09 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83pm4r9apt.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
2023 17:45:18 +0300")
Message-ID: <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
<83pm4r9apt.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 12:44:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.050 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
>> 1- decide which windows may need to be updated.
>
> More accurately:
>
> 1a - decide whether all the windows need to be considered, or just
> the selected window
> 1b - if all the windows need to be considered, decide for each frame
> whether it needs to be considered, and if so, consider all of
> that frame's windows
>
> Considering a window can sometimes decide very quickly that the window
> doesn't need to be redisplayed, but, as I mentioned elsewhere, when
> its frame's redisplay flag is set, we never decide that, and the
> frame's redisplay flag is what causes us to consider a frame in the
> first place.
Hmm... I'm not sure why you're saying
frame's redisplay flag is what causes us to consider a frame in the
first place.
AFAICT the main place where we check a frame's `redisplay` bit is in
`needs_no_redisplay` which operates on a window.
In most cases a frame's `redisplay` bit should not be set, tho some of
its windows' `redisplay` bits may be set, and we will consider this
frame and all its windows (to find those that need to be updated).
>> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
>> redisplay could be moved to ELisp. This would allow for example
>> `follow-mode` to pick a more appropriate order in which to process the
>> windows at step 2.
>
> follow-mode needs much more than that.
If the redisplay toplevel could be hacked in ELisp, follow-mode could
call the `update-window-glyph-matrix` on the "main window" of its
window-set first, then get the resulting window-end/start and use that
to adjust/scroll its next/prev windows, and then call
`update-window-glyph-matrix` on them, thus propagating the information
in the right direction and avoiding unnecessary redisplay computations.
> But if you want to be able to tell redisplay "update only this window
> and nothing else", I think it should be easy to accomplish by adding
> a single function and no other changes: all you need is to call
> 'redisplay' (which is already exposed) after setting the redisplay
> flag of a single window.
That won't avoid redisplaying the other windows whose `redisplay` bits
had been set already for other reasons.
I guess we could try to "save the redisplay bit" of other
windows/buffers/frames, and restore them afterwards. Also, it would be
good to be able to compute the glyph matrices of the various affected
windows before we do the actual glass update (especially if we want to
handle iteration where some part of the redisplay (e.g. jit-lock,
evaluation of mode-lines and menu bars, point moving out of scope
forcing a scroll, you name it) causes changes which require
recomputing a glyph matrix we just computed).
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:49:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 10:49:25 2023
Received: from localhost ([127.0.0.1]:48393 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL33t-0006OT-8G
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:49:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13241)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qL33r-0006OA-V0
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:49:24 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4B22B1000C4;
Sun, 16 Jul 2023 10:49:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5FCF5100097;
Sun, 16 Jul 2023 10:49:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689518957;
bh=R3zygOJtMTDta3gIdysw7HG/GMQZoYAWGI9Y4wq0QV8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=JFmxJucESAm6mZGDUQ6Q2xKCQ67Fcp2OYP1LjbAkLYrsyFJYixXhCiz3Yi0IPLnrt
KH3gVuFz9jYwdMK9CKox+OO+7LsLC7FyJ1b7Uzv+U8pbfUbuFN7bidcJc0B/JXGoEw
EpTMton2OVNJ2SnO/6dWlUE2NzcSdIfEXI/cpT/rO1exWpVzkGs1chzXc2RRtkCjoq
3pGgcCtAsX6aAXDvyXmg6m7LUqlwY36FUTvKSBob/NLS9q+jj2bOASZgAKFAZr2umU
VpWrcNaoskQGfPp0VcT277Y0xXBI+HOK/Wy7zt7q4ot584JKvs1u5yEiWDO2jzKccN
YIljMB3JPXvJQ==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 321451202E0;
Sun, 16 Jul 2023 10:49:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83r0p87wyq.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
2023 17:27:41 +0300")
Message-ID: <jwvy1jf9aww.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
<83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
<871qh8o12z.fsf@localhost> <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN>
<83r0p87wyq.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 10:49:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.228 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> So it sounds like we should make sure we don't set the frame's
> redisplay flag unless most or all of its windows actually need to be
> considered. Is this so with the current code?
Indeed, the frame's `redisplay` bit means "*all* windows in that frame
need to be redisplayed", so it should be set with care. But since the
code before that only had a single boolean for "redisplay all windows on
all frames", I was often happy enough to replace the global redisplay with
`fset_redisplay` even though it might be possible to be more specific.
`fset_redisplay` is typically used when windows are added/deleted/resized,
because it's hard at that point to know which windows really need to
be updated.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:45:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 10:45:07 2023
Received: from localhost ([127.0.0.1]:48388 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL2zj-0006AC-C4
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:45:07 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47770)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qL2zd-000697-H4
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:45:05 -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 1qL2zX-000246-Nd; Sun, 16 Jul 2023 10:44:55 -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=pd4R7tzzZSS21bj49fhQEZKAPOowKqkM3xEFVdU+QvA=; b=lR07At887/+T
0Z+wNfeq5Rs7I8sGKTHyKKZcfTVJJ6BHNeqrwFMlzuKlCqS2IP2Q/2D9za4Lu9f2bPUP8ndQOAKv1
9zZLv4JYc13jZ5aRqyJdmbtl5QBRA4QsEssySPPVBmfBqDEmoFJCsd/Sc6/kzQE7YYDq2z2SdNhkf
asf9Up2FXh1kJ7yUkUj6MSC5bzkVrXSL+X/7zpMKvUBAeizxx3jhH3iVzRVEmlG5abBUogi/tICal
otUzeHgaSRvHn49VrXaczLCECIWuZnH4dTboR/X/yYLG4pn3hrSBWaCMpysXDb8zD2Bf2TUx0e+1p
TiCtUl2iMVJ5JC29VLtlwg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qL2zX-0005GB-8P; Sun, 16 Jul 2023 10:44:55 -0400
Date: Sun, 16 Jul 2023 17:45:18 +0300
Message-Id: <83pm4r9apt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sun, 16 Jul 2023 10:26:10 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:26:10 -0400
>
> My understanding of the redisplay code is that it's split into 3 part:
>
> 1- decide which windows may need to be updated.
More accurately:
1a - decide whether all the windows need to be considered, or just
the selected window
1b - if all the windows need to be considered, decide for each frame
whether it needs to be considered, and if so, consider all of
that frame's windows
Considering a window can sometimes decide very quickly that the window
doesn't need to be redisplayed, but, as I mentioned elsewhere, when
its frame's redisplay flag is set, we never decide that, and the
frame's redisplay flag is what causes us to consider a frame in the
first place.
> 2- update the glyph matrix of a window.
This update can be partial -- that's one of the redisplay
optimizations. That is, we update only a very small part of the glyph
matrix, as small as a single glyph row (= screen line).
> 3- update the glass by comparing the old glyph matrix and the new one.
>
> [ The point between 1 and 2 is made visible to ELisp via
> `pre-redisplay-function`. ]
>
> The `redisplay` bits belong to step (1).
> The `prevent_display_optimizations_p` OTOH belong to step 2, AFAIU.
Yes.
> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
> redisplay could be moved to ELisp. This would allow for example
> `follow-mode` to pick a more appropriate order in which to process the
> windows at step 2.
follow-mode needs much more than that. But if you want to be able to
tell redisplay "update only this window and nothing else", I think it
should be easy to accomplish by adding a single function and no other
changes: all you need is to call 'redisplay' (which is already
exposed) after setting the redisplay flag of a single window.
> > Then, why not use uniform naming scheme and have the buffer/window/frame
> > flags names as maybe_redisplay and must_redisplay instead of different
> > flag name for different object type?
>
> For that someone first needs to have a clear idea of what these things
> do and how they relate to each other :-)
Right.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:27:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 10:27:29 2023 Received: from localhost ([127.0.0.1]:48371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qL2if-0005Tz-8e for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:27:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qL2ia-0005Td-Hj for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:27:28 -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 1qL2iU-0006E7-Sg; Sun, 16 Jul 2023 10:27:18 -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=NEgPeovDXXlCv5BSlayFQ1HpF9a+wcJ4I3dkhK6iToA=; b=Ou9eg6snQWkh An4o84rsQAeRdLV6R64WzpA4udPgXirTcaELJqDGFWB1tVG/m8Xi1duXhwNpPfsqyoOi7Z22fH94n xlFHK/locBpiha2NFuNjkdVzwaVShfgil/SFASyt3sKeTIZb6lTIVrUNklO6tOVZ1Ktb+hRh8XDv0 Lio5Q4lrcQZq7aEZixo6Z8fien97LAaRMrL2OVYHGjgTTD/oePABmY9lKz3+JZS2IHOI4z9HrK3PM 8E3CZ782zG90cfzBcHXIBzotPuw9xEolami9GZ1Vq2LQiMe9LIHQugNRYqlHekxMb/ZtIaTxO4mC4 X/vlHMU08bA6V/GtI5UDJA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qL2iU-0001ku-CR; Sun, 16 Jul 2023 10:27:18 -0400 Date: Sun, 16 Jul 2023 17:27:41 +0300 Message-Id: <83r0p87wyq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 16 Jul 2023 10:04:30 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost> <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 10:04:30 -0400 > > >> - /* True means redisplay has to consider all windows on all > >> - frames. False, only selected_window is considered. */ > >> + /* False, means that only the selected_window needs to be updated. > >> + True means that other windows may need to be updated as well, > >> + so we need to consult the `redisplay` bits of > >> + all windows/buffer/frames. */ > >> bool consider_all_windows_p; > > > > BTW, is there any particular reason why windows_or_buffers_changed is > > not a queue of windows/buffer to be re-displayed? > > FWIW, I suspect that the loop over all windows is always > insignificant, so (in theory) we could get rid of the optimization that > looks only at the selected window in most cases and we wouldn't notice > any slowdown or measurable increase in CPU use. True, but with one caveat: the loop over all windows will not trivially return from redisplay_window if the window's frame has its redisplay flag set. So it is enough for the frame to have this flag set, for redisplay to have to consider all of its windows, even if the redisplay flag of each and every one of that frame's windows is reset. And once we decided not to return immediately after entering redisplay_window, the processing is not insignificant, since it involves making the window's buffer the current one, and as result setting all the values of buffer-local variables. So it sounds like we should make sure we don't set the frame's redisplay flag unless most or all of its windows actually need to be considered. Is this so with the current code? > So, replacing the `redisplay` bits with a queue is probably not a great > idea (especially since setting a bit is much faster than adding an > element to a queue where you need to try and avoid adding the same > element a hundred times). Agreed.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:26:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 10:26:25 2023
Received: from localhost ([127.0.0.1]:48366 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL2hc-0005RK-PB
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:26:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10350)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qL2ha-0005Qy-LN
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:26:23 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 09DB11000C4;
Sun, 16 Jul 2023 10:26:17 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 14E42100097;
Sun, 16 Jul 2023 10:26:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689517576;
bh=x7QlzWnSuJyoL9mTQKol6LAvX8C3G5epleB0ubRv3O0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=N+P+UX9OuqFFXc/neZ05LylixTo3USuchVYxphCXAnC+9QmI+y6kuMi4QarRaOucj
Dy6FIsPyXS2RtkCgPRkHKwNwinZFY0Sj6stK1pA9g3bIsR5rKROWh+7UtPhXEdpKfG
KgbAcWw36cmCy6Wn7pCk78SkZOIWrRQMtmKoZcwp+L55YAcswapqX2HQKbrLx07A2N
5BL63ZJoMGWkKXZt33rAN2LOwPfIgplrL7cesqfyoGfPZxbVrpMOVhIw9phn/NVRZ6
Ro/fq1gfrF2QfsV4iadxyiwP6nTFoEmvnwPLBYAeKh1YR9NU0PlrB7/zdGiKuz0vC8
UEJmz2JwCsPvQ==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DD63612030C;
Sun, 16 Jul 2023 10:26:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <87ilakgmjo.fsf@localhost> (Ihor Radchenko's message of "Sun, 16
Jul 2023 10:47:55 +0000")
Message-ID: <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
<87ilakgmjo.fsf@localhost>
Date: Sun, 16 Jul 2023 10:26:10 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.260 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---)
>>> I agree about must_be_updated_p. I had exactly same though that it is
>>> redundant with redisplay flag when reading the code.
>> Look closer, please. The name of the flag might suggest what you say,
>> but its usage suggests otherwise.
> Do I understand correctly that prevent_display_optimizations_p in
> buffer, must_be_updated_p in window, and garbaged in frames all serve
> the same purpose of forcing the redisplay?
My understanding of the redisplay code is that it's split into 3 part:
1- decide which windows may need to be updated.
2- update the glyph matrix of a window.
3- update the glass by comparing the old glyph matrix and the new one.
[ The point between 1 and 2 is made visible to ELisp via
`pre-redisplay-function`. ]
The `redisplay` bits belong to step (1).
The `prevent_display_optimizations_p` OTOH belong to step 2, AFAIU.
BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
redisplay could be moved to ELisp. This would allow for example
`follow-mode` to pick a more appropriate order in which to process the
windows at step 2.
> Then, why not use uniform naming scheme and have the buffer/window/frame
> flags names as maybe_redisplay and must_redisplay instead of different
> flag name for different object type?
For that someone first needs to have a clear idea of what these things
do and how they relate to each other :-)
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:04:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 10:04:43 2023
Received: from localhost ([127.0.0.1]:48335 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qL2Md-0004ZJ-BQ
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:04:43 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7479)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qL2MY-0004Yu-Dw
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:04:42 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1D98A442854;
Sun, 16 Jul 2023 10:04:33 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D0B7944284E;
Sun, 16 Jul 2023 10:04:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689516271;
bh=cIaUwIGQOb4vf/MZMp1xcfzso8EDp4gG2HQeNrvU5b0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=iJ1rQadE3wkhaxVAyU2tKVE9KaPzFhDjfqGmhcVmZaoSiAcRcDFYN6fqhpf8CAHBa
396o0Tat9lLrgzGIQ8EmwBUqcJJBHHGGGfdwGd4KrG2ucJqePQfXkXKFgRlcihCr8B
fGYjDfIf64KiaIfKSSdsgnjWnEms+RNy5wLFzmNtqUS7Z026YvmFvldPBvVu1poeum
MpnjBp+6Zqeg5pzYizO0Oyf71DuVcPF8iftyg2rz5KMP8zdx/B5rzdAuBKkq2Y1tLt
obM1DNPR0YcTZUdLZ1ALy/0cbN0ECdLMw7ZsOENtWZuQlhZmDkTuXpGhtreA4/EIhL
xlwqvFSxT0kAQ==
Received: from pastel (unknown [108.175.226.218])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A40501202FC;
Sun, 16 Jul 2023 10:04:31 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <871qh8o12z.fsf@localhost> (Ihor Radchenko's message of "Sun, 16
Jul 2023 05:52:04 +0000")
Message-ID: <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
<83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
<871qh8o12z.fsf@localhost>
Date: Sun, 16 Jul 2023 10:04:30 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.159 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---)
>> - /* True means redisplay has to consider all windows on all
>> - frames. False, only selected_window is considered. */
>> + /* False, means that only the selected_window needs to be updated.
>> + True means that other windows may need to be updated as well,
>> + so we need to consult the `redisplay` bits of
>> + all windows/buffer/frames. */
>> bool consider_all_windows_p;
>
> BTW, is there any particular reason why windows_or_buffers_changed is
> not a queue of windows/buffer to be re-displayed?
FWIW, I suspect that the loop over all windows is always
insignificant, so (in theory) we could get rid of the optimization that
looks only at the selected window in most cases and we wouldn't notice
any slowdown or measurable increase in CPU use.
So, replacing the `redisplay` bits with a queue is probably not a great
idea (especially since setting a bit is much faster than adding an
element to a queue where you need to try and avoid adding the same
element a hundred times).
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 11:31:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 07:31:13 2023 Received: from localhost ([127.0.0.1]:46965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKzy4-0007tR-VO for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:31:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKzy3-0007tC-JA for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:31:12 -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 1qKzxy-0003Nt-4x; Sun, 16 Jul 2023 07:31:06 -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=XD7I2+GWqW6AuO4HPWsWRGL7GCqUP53erinBlrqEnKw=; b=lmaplxz9PthM c4+M1k6ZHSfYEeK2G6/NZO5rEIWqZU+trszZNpW7POsZjhxylJm6gLyhBXNFtBH2NpFdWw1YaWuSi V3lP4UgUd2jhG7nz5fjj2VAEsBx+ITzKSNdD9ErnaD32rs3+z29UjKnyRKY7sPzqBRZgBSqCvmL/0 qStuA41qnl52Cxpet26n1fSjkrxcL/QZwX0oxaHlXK2i+UoH9BdB7IckMOVzyV5Y67bDIl9n6H9uj 0mRdsZZ4iRS7u/z8Ft5FmdhhIoQEZliVRBghIDH6RiJzXjAP60qnD8XuK7C85o68G7z4whgUYhAVS WoeOc255ihbH0QwQFk+Wkw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKzxx-0000x9-3L; Sun, 16 Jul 2023 07:31:05 -0400 Date: Sun, 16 Jul 2023 14:31:29 +0300 Message-Id: <83zg3w854e.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87ilakgmjo.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 10:47:55 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN> <87ilakgmjo.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 10:47:55 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> I agree about must_be_updated_p. I had exactly same though that it is > >> redundant with redisplay flag when reading the code. > > > > Look closer, please. The name of the flag might suggest what you say, > > but its usage suggests otherwise. > > Do I understand correctly that prevent_display_optimizations_p in > buffer, must_be_updated_p in window, and garbaged in frames all serve > the same purpose of forcing the redisplay? They all force redisplay, yes, but in different ways. For example, the frame's garbaged flag means the entire frame with all its windows and decorations might need to be redrawn. By contrast, prevent_redisplay_optimizations_p just means "don't use some of the redisplay optimizations that we otherwise could be tempted to try". IOW, not redisplaying a window at all is not an "optimization". > > IOW, prevent_redisplay_optimizations_p must come with the redisplay > > flag set on the buffer/window/frame, but after that it says a > > different thing. > > Then, why not use uniform naming scheme and have the buffer/window/frame > flags names as maybe_redisplay and must_redisplay instead of different > flag name for different object type? Historical reasons. But such naming convention is of secondary importance, IME. As long as the names are not completely misleading, and their effects are well documented, 90% of the job is done.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 11:26:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 07:26:35 2023
Received: from localhost ([127.0.0.1]:46960 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKztb-0005EC-7d
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:26:35 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41298)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKztZ-0005E0-7K
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:26:34 -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 1qKztS-0001rW-0G; Sun, 16 Jul 2023 07:26:26 -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=aRgN6D2nWkjHJj23Y0f+LZmsQhVSPlZmz5kHjcucsmc=; b=YD+RJU+J9Uvd
EoAKRZ7gzNyVmUDzP3NbPNfKJKgDpmXQFdPwXPr6/MTBtPilOz3vTN/hSnm2IfmUw6GTsnOUJNmTM
GsieUGXVivrKwetvDbUFYO0EBvj5nFtgWt5ovXbjkmUBeB6QKDSoJr36c19EWX1mGqXPUSPBN3QIr
toM5Mps8jor6mNCd20gYrx7Gg0QWY8/3D/0HCHZfQwkAZB+yCDBkJ4aoEX7fv4NYdeJUwGv19L0fb
yuhdrLBDUcuFwGmpKv4oc2QkiruWpdrUKmqrh7CmgEN9mgs76EbKL0NiI3jiqVUb0EnvRft1zPCby
yAUbSJmQ5jI86z1VdCVpTQ==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKztR-0005yk-Fb; Sun, 16 Jul 2023 07:26:25 -0400
Date: Sun, 16 Jul 2023 14:26:48 +0300
Message-Id: <831qh89jwn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <87lefggmzt.fsf@localhost> (message from Ihor Radchenko on Sun,
16 Jul 2023 10:38:14 +0000)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost>
<jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
<jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
<jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
<jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
<83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
<jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
<jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
<jwvilalayz0.fsf-monnier+emacs@HIDDEN> <87lefggmzt.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: monnier@HIDDEN, 64596 <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 (---)
> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:38:14 +0000
>
> It would be even better if *-mode-lines functions were renamed to
> something more explicit. It is very disorienting that "mode-line" may
> mean actual mode-line, but sometimes more than that.
> A clarifying comment is an improvement, but does not make the code in
> other places more readable.
If we want to do this, the job is larger yet. We also have this:
struct glyph_row
{
[...]
/* True means row is a mode or header/tab-line. */
bool_bf mode_line_p : 1;
/* True means row is a tab-line. */
bool_bf tab_line_p : 1;
struct it
{
[...]
/* True means window has a tab line at its top. */
bool_bf tab_line_p : 1;
/* True means window has a mode line at its top. */
bool_bf header_line_p : 1;
struct glyph_matrix
{
[...]
/* True means window displayed in this matrix has a tab line. */
bool_bf tab_line_p : 1;
/* True means window displayed in this matrix has a header
line. */
bool_bf header_line_p : 1;
and the code which deals with these. (Note that the bits are
inconsistent between glyph_row and the other two structures, and all
of them mention only 2 out of 3 attributes.)
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:47:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 06:47:53 2023 Received: from localhost ([127.0.0.1]:46932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKzI9-0004Eq-BI for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:47:53 -0400 Received: from mout02.posteo.de ([185.67.36.66]:44541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKzI5-0004Do-A2 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:47:51 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C27CD240101 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:47:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689504463; bh=Ixz8djm218elIv7793+a0oUezef6n5X15I5Z1myMekQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=KIBkgNexwD7dtgIBFy3w/6wkcaus8s6bbNUUt7cH4xaZzwaXMiQFauWoloq7IwopW ySM3icQ5lolIrAl56VFhCCj2BUt55UdykK/UoPcg6yhF0FKUFupA6pxRTLE0TKpTc9 8FacSeX3qviaxBVT8wxZUNhtdH/tD/dnz7mYo4XC4iK9RrVwOYFbnalkr6b75urSMM KC6V3u7tnkUHkc3Iee3WpFPT7TaKCyMAtcTTR8EMJKYrNWZVqT0nXNcLs3uIdlpmBQ 10pXZMvN1tbMVu5pTLQB+jmOxsvzKkns1rsy7kExbufsmazJXLaV75Tx+euHi8IO7b 1Npx7rVKIXtZg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3hkQ6Bf3z9rxM; Sun, 16 Jul 2023 12:47:42 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83351o9m6h.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN> Date: Sun, 16 Jul 2023 10:47:55 +0000 Message-ID: <87ilakgmjo.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> I agree about must_be_updated_p. I had exactly same though that it is >> redundant with redisplay flag when reading the code. > > Look closer, please. The name of the flag might suggest what you say, > but its usage suggests otherwise. Do I understand correctly that prevent_display_optimizations_p in buffer, must_be_updated_p in window, and garbaged in frames all serve the same purpose of forcing the redisplay? >> prevent_redisplay_optimizations_p is intuitively logical, but I still >> feel confused because it appears to be redundant upon seeing redisplay >> flag in the buffer. It raises a question what redisplay flag really >> means - it is causing redisplay of a window/buffer or not necessarily? > > Neither. > > The redisplay flag means that a window or a buffer or a frame need to > be _considered_ for potential redisplay. (Whether the consideration > will conclude there's a need to actually redraw the corresponding part > of the Emacs display is another matter -- it could conclude that all, > some parts of, or none of the objects marked for redisplay actually > need it.) > > prevent_redisplay_optimizations_p says that while considering which > parts of the buffer need to cause redisplay, certain shortcuts and > optimizations designed to make redisplay faster and less expensive > must not be taken/used. > > IOW, prevent_redisplay_optimizations_p must come with the redisplay > flag set on the buffer/window/frame, but after that it says a > different thing. Then, why not use uniform naming scheme and have the buffer/window/frame flags names as maybe_redisplay and must_redisplay instead of different flag name for different object type? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:38:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 06:38:10 2023 Received: from localhost ([127.0.0.1]:46923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKz8j-0003xn-RX for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:38:10 -0400 Received: from mout01.posteo.de ([185.67.36.65]:34991) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKz8h-0003xK-Oa for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:38:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1D657240029 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:38:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689503882; bh=oRqb/lYW5DRVbwkJmrSXETtRXTID110mYg+uag7vra4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=djY0XaY7lUu0I6879FcRUHG7oiULLSRDEd0E7ZCsDhhexi0koeivnsDNiidZq34Gb zyIDNR2/TPhKdGX4ob4KPFQ8FewfP9SuWe82ndlykeRYSlPJi0TlZluO1JiUvBgZK6 QxPG9m3QM+LTh0+PM5iZW56FNJHjaj0E7yM2J/XC5krtRGDTt9b924AwNJxqSWN5Bp PXNq8p/0eJ6iaD84EMBuSrOI4kPVgahhSvonUbIvfJrJhLGGxrTIR7IobCC83i+13i J2yEskgkmvLfUO3f1qKfrFZ+Ado//lHepOSDgh/JRT82ue3uZBOIT9gbFBLNhgkztU vzds7uPG9a5Tg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3hWF3406z6txR; Sun, 16 Jul 2023 12:38:01 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <jwvilalayz0.fsf-monnier+emacs@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwvilalayz0.fsf-monnier+emacs@HIDDEN> Date: Sun, 16 Jul 2023 10:38:14 +0000 Message-ID: <87lefggmzt.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---) Stefan Monnier <monnier@HIDDEN> writes: > -/* Non-zero if we should redraw the mode lines on the next redisplay. > +/* Non-zero if we should redraw the mode line*s* on the next redisplay. > Usually set to a unique small integer so we can track the main causes of > - full redisplays in `redisplay--mode-lines-cause'. */ > + full redisplays in `redisplay--mode-lines-cause'. > + Here "mode lines" includes also header-lines and frame names, and > + apparently also menu-bars. The link with header-lines is clear, > + but a bit less so for frame names and the menu-bar. */ It would be even better if *-mode-lines functions were renamed to something more explicit. It is very disorienting that "mode-line" may mean actual mode-line, but sometimes more than that. A clarifying comment is an improvement, but does not make the code in other places more readable. Maybe use a term like "info-lines" to avoid confusion of using the same term for multiple different meanings? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:37:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 06:37:30 2023 Received: from localhost ([127.0.0.1]:46918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKz86-0003wR-9H for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:37:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKz81-0003tL-BM for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:37:28 -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 1qKz7v-0002Yz-PX; Sun, 16 Jul 2023 06:37:19 -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=/c8suefAl+Ank3WQNHSMZ4ZQX7JYY6D83wj65abPV1s=; b=cCCk3MySNOcW RkL6xiWKry4Tyn9lPEOLgi1S2V6/fhgPs09+x5A3j3ONo86D6UNpQbKklN/zVaUq13PeHlzUQc0yT R7agamLxOMT7VnvojB3BRfvVlRFiX/rqANcIfsLyvfjOQqRMinX8thw/8b+A01gfmj3ocfrlJKPk0 Y+4DR14FEc3aAj3xD1YbLKz9kebWYslDy2c4U0Kz0vUcoKvZJ0cjmWQfKWUevlt3rkEE1le23qwd2 kY0x+BfkVSLGpTFTxcDTYrydu4NJuyoQX18NG+DBgjZu1E7g9TJdWlV9cjBM7iCvChApNzYbApvSf +t2NhRLhK7L0ifLIL58NLQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKz7v-0005UD-8o; Sun, 16 Jul 2023 06:37:19 -0400 Date: Sun, 16 Jul 2023 13:37:42 +0300 Message-Id: <83351o9m6h.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87ttu4gnpt.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 10:22:38 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 10:22:38 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > >> . prevent_redisplay_optimizations_p flag of a buffer > >> . must_be_updated_p flag of a window > > > > No idea what these mean. > > The name `must_be_updated_p` makes it sound to me like it's redundant > > with the `redisplay` flag above. > > I agree about must_be_updated_p. I had exactly same though that it is > redundant with redisplay flag when reading the code. Look closer, please. The name of the flag might suggest what you say, but its usage suggests otherwise. > prevent_redisplay_optimizations_p is intuitively logical, but I still > feel confused because it appears to be redundant upon seeing redisplay > flag in the buffer. It raises a question what redisplay flag really > means - it is causing redisplay of a window/buffer or not necessarily? Neither. The redisplay flag means that a window or a buffer or a frame need to be _considered_ for potential redisplay. (Whether the consideration will conclude there's a need to actually redraw the corresponding part of the Emacs display is another matter -- it could conclude that all, some parts of, or none of the objects marked for redisplay actually need it.) prevent_redisplay_optimizations_p says that while considering which parts of the buffer need to cause redisplay, certain shortcuts and optimizations designed to make redisplay faster and less expensive must not be taken/used. IOW, prevent_redisplay_optimizations_p must come with the redisplay flag set on the buffer/window/frame, but after that it says a different thing.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:31:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 06:31:22 2023 Received: from localhost ([127.0.0.1]:46909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKz2A-0003ix-Cw for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:31:22 -0400 Received: from mout02.posteo.de ([185.67.36.66]:34201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKz28-0003il-R7 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:31:21 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0B52924010E for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:22:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689502948; bh=p9FQY8lzZrovUou/MKMGxE/j4PErW9Qvs2VRn4hok1g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=QOcl0YqeiCltU8gtUf87JaD+ijU+LaP55qhoGFSdNihJPKG24iinBHafPS0/yCvny b/q7g8/uMKz22rfjeUDw/BvGQ8geXCECr2Jm2bPPIyUMNSWH7OYn88N5ieSbyXQHMx kYeazZT8Q/nu0qk/qa8M8ujjn9n0/Q6V/Q30VJTda93Gz0r93hOe6pLcezRoO/WL/l pFN9cXgEkYXRwjwnNTAnNuQIiaOS6xiEcamDgric0SohUWxaf8pYvK3On11K+riXez 0lgOZHoez1qQSjQl6mDcFSHr5ecJbEfC6cRPkiZWV8HYIhqIitCgF4cB0LawVJlpOx Q4ZC4E4IaropQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3h9G0p0hz6txQ; Sun, 16 Jul 2023 12:22:25 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> Date: Sun, 16 Jul 2023 10:22:38 +0000 Message-ID: <87ttu4gnpt.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---) Stefan Monnier <monnier@HIDDEN> writes: >> . prevent_redisplay_optimizations_p flag of a buffer >> . must_be_updated_p flag of a window > > No idea what these mean. > The name `must_be_updated_p` makes it sound to me like it's redundant > with the `redisplay` flag above. I agree about must_be_updated_p. I had exactly same though that it is redundant with redisplay flag when reading the code. prevent_redisplay_optimizations_p is intuitively logical, but I still feel confused because it appears to be redundant upon seeing redisplay flag in the buffer. It raises a question what redisplay flag really means - it is causing redisplay of a window/buffer or not necessarily? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:29:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 06:29:52 2023 Received: from localhost ([127.0.0.1]:46905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKz0h-0003el-R5 for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:29:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKz0f-0003eW-65 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:29:50 -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 1qKz0Z-00006J-6q; Sun, 16 Jul 2023 06:29:43 -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=4XZ7JzybYfweWxXyjFdDs7jNgdX6gAB+JHQnsRMbA/0=; b=inKU80Y0HoED AOR4Y4oofXWeJSb4vJlpsaAw4QdGrFLcQB/BBvS29zz3LihXkDNsV7wPQSSJ8NQDngLvU1DnkVJsw vRpoNhAAiyD/H5osKQTVc8IpBejgbOdj13jnntjKawZVhT6+ByWhcKsTgiYUCojAmOuQb2DVtK6ir jzPA1QTUHyVm8mylkIs+I1x1A8o/tG/ZAp+texoeYbK+uS3eyW1rbhcEZUw5bm49hasc72FU3UXWb 6NsRHOrk5W9XHVsOQzXiSH4GVb4XvbeVjrMk8hxAbynzvzoG/6HOB7k6itQGAvMuSNqf7w1VOvn+r uhf/ogwzUji1+IUVR/GSqQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKz0Y-0004f4-Pd; Sun, 16 Jul 2023 06:29:43 -0400 Date: Sun, 16 Jul 2023 13:30:06 +0300 Message-Id: <835y6k9mj5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87a5vwi46v.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 09:41:28 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost> <83edl89qvd.fsf@HIDDEN> <87a5vwi46v.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 09:41:28 +0000 > > The top commentary in xdisp.c defines "display elements" as elements in > glyph matrix. These include characters (possibly composed) and images. They include more than that, see enum glyph_type in dispextern.h. > However, not everything drawn in Emacs frame is represented by display > elements : > > 1. Title bar is not using glyphs at all > 2. Same for scroll bars These two are window-system/toolkit widgets. > 3. and menu bars This is either a toolkit widget or an Emacs-produced text; in the latter case it does use our glyphs. > 4. and tool bars Depending on whether the tool bar is "external" or not, this could be a special kind of window with our glyphs. > 5. and window boundaries On TTY frames, these are character glyphs. > 6. and things like fill-column-indicator (AFAIU) Those are fringe bitmaps, so they belong to the fringe. > Further, some display elements are grouped: > 1. per frame > 2. per window > 3. within fringes > 4. within mode-line > 5. within buffer text area > 6. within a line of text > 7. within header line > 8. within tab-line The latter 5 are in display-engine realm, and some of them are only calculated as part of redisplay, so other code should not try to handle that. But yes, we definitely need (and already have) buffer flags, window flags, and frame flags. > I think that the flags should provide a way to mark each of the groups > or individual glyphs for future redisplay. Nothing knows (or should know) about glyphs except the display code.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 09:41:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 05:41:27 2023 Received: from localhost ([127.0.0.1]:46866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKyFr-0002Fd-3T for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 05:41:27 -0400 Received: from mout02.posteo.de ([185.67.36.66]:47813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKyFm-0002FN-JJ for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 05:41:26 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C7CB0240104 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 11:41:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689500476; bh=eIEW9AucfmzAyH4FD+vcPTUouqKRrZqyQbTMrvIIxD8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=CEfz+PASrKubirSOW5MEr2VkQOqomc54B+xJy3uPkXHT5aA3gUMOMTiSQZCqigr5I D8hxIi5FrHPQTNnDiMbVi6JWiSAdLLwHeFoQKRlgVaBxvK6G6ThYjqRxAy+E03hQdq uDw2t+ez1eHyWF96lEsg7yXBrcImFks6llJx0si29HNpsyS/upW0S10PBe2QIQ32Fw 4yEcNuW+DXlq0TEUft5eMbSv/7G9JytoGdOtKhnnPHZmn50V7wA/TDNwAzr49Y6v80 bUA+lp2gEOHd5GrFTddoLtuxp1rVEITYCq+SzYxbRTMi8lBvDa4XPgloY9z2zt9t17 OX3CItQug668Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3gFl6H6yz6tws; Sun, 16 Jul 2023 11:41:15 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83edl89qvd.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost> <83edl89qvd.fsf@HIDDEN> Date: Sun, 16 Jul 2023 09:41:28 +0000 Message-ID: <87a5vwi46v.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> May someone list all the possible displayed elements Emacs considers? > > What do you mean by "display element" here? The Emacs display engine > already has a term "display element", but I think it means something > very different: character glyphs, images, compositions, etc. See the > function get_next_display_element in xdisp.c. > > So we had better agreed on clear terminology here to avoid terrible > confusion. Fair point. The top commentary in xdisp.c defines "display elements" as elements in glyph matrix. These include characters (possibly composed) and images. However, not everything drawn in Emacs frame is represented by display elements : 1. Title bar is not using glyphs at all 2. Same for scroll bars 3. and menu bars 4. and tool bars 5. and window boundaries 6. and things like fill-column-indicator (AFAIU) Further, some display elements are grouped: 1. per frame 2. per window 3. within fringes 4. within mode-line 5. within buffer text area 6. within a line of text 7. within header line 8. within tab-line I think that the flags should provide a way to mark each of the groups or individual glyphs for future redisplay. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:56:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 04:56:08 2023 Received: from localhost ([127.0.0.1]:46782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKxXz-00012v-Pm for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:56:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKxXw-00012F-Uo for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:56:05 -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 1qKxXr-0004lA-0B; Sun, 16 Jul 2023 04:55:59 -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=KP20kCGSPsyvyYusPbNoKJ6elG2vEd4Hdhd4wAHSdY0=; b=nSe7uxcxzH0J 4EVU2URa1uqxOCK7mwsxIDdmUFnWSki659KXUvEgEkDUSAqg7PJ3TiS8c4wRZ2FtDjlghqomBcWcq ILTg3Nz1orIY3333gUOIcw5IyJOmpUUWpnHH2hdjJrOdo7Xr/+W8l3QRemt8tjif1HtHW3eou2x8M EVSjte4Irwc1cmm/OrreJ4VlyE1H1yClxqWK0s/BEZHq0XxR7ia/bzpbFzr1VV2LJn07owGfgLM/e QVvBwa9w05WhI7R/S+RJoWYg7ITiAqXJmsflfSCe+EzNJX4eoq1of4M6aQDhyAgc6r6trS07AjPxP yucz3n7594s1g8gXdTW5EQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKxXq-0003LN-G9; Sun, 16 Jul 2023 04:55:58 -0400 Date: Sun, 16 Jul 2023 11:56:22 +0300 Message-Id: <83edl89qvd.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87wmz0i709.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 08:40:38 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, > 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 08:40:38 +0000 > > martin rudalics <rudalics@HIDDEN> writes: > > > Here 'set-window-configuration' should be able to tell redisplay that it > > should redisplay the window but it should be able to tell that iff the > > fringe really changed which is fairly easy to find out. Once it found > > out, which kind of flag would it set? > > May someone list all the possible displayed elements Emacs considers? What do you mean by "display element" here? The Emacs display engine already has a term "display element", but I think it means something very different: character glyphs, images, compositions, etc. See the function get_next_display_element in xdisp.c. So we had better agreed on clear terminology here to avoid terrible confusion. > I think that it might be a good new API to have a single function that > marks things for redisplay. That function will accept arguments > indicating what exactly may need to be redisplayed: CURRENT_TEXT_LINE, > FRINGE, LINE_NUMBERS, CURRENT_BUFFER_TEXT, CURRENT_BUFFER_MODELINES, > ALL_MODELINES, CURRENT_FRAME, etc. The first step is to identify the changes in which the display engine is interested, and design the flag(s) to communicate this information to it. The actual API, whether a single function or a set of macros or something else, comes later, and is not a complicated decision to make. Please note that whether current text line needs to be redisplayed, or if line numbers need to be redisplayed, or if mode line needs to be redisplayed, is in many cases a decision that only the display engine can make. So you seem to be thinking in terms that are not entirely correct.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:50:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 04:50:06 2023 Received: from localhost ([127.0.0.1]:46772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKxS7-0000tI-LN for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:50:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKxS3-0000se-3f for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:50:02 -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 1qKxRw-00032Q-7E; Sun, 16 Jul 2023 04:49:52 -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=I56FnZqhEJ0mPPUaC9LV8IAZEAzEDya+cx+ofN+YIEY=; b=hufqSodAiKoK 5uqyJVvDXwmQEa67zhL1Iesy2T8XgsXzfVGR8wc+1sYnGBKBPKgp7ozTVe2PM1t0EJxBTaD8GKnzC 58lZEfRXtgufSTWFOYEM1jGy7BtjI1PnNZDJuGzqFITHWuIqj4Ht70ZLh0k/BQmE3C4BGJrXjR8/R dfjDhE590XT/9tUBZSJ1u6xMaqv0VjxNO882VSA1eFUhx4rpw42bqKoYJ678hHWb8cvDtvxnzdoN7 Q+7ZsI1EldbOR3fQGYlNhsYt2/1dAZvCKqU2IWmUofU/4kMofoRhxhmARtxgK1j+SoD2y5apfHv+f 6VTJhBOivK3tH5WYSI8TCw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKxRv-0002Ua-Nm; Sun, 16 Jul 2023 04:49:52 -0400 Date: Sun, 16 Jul 2023 11:50:14 +0300 Message-Id: <83fs5o9r5l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: martin rudalics <rudalics@HIDDEN> In-Reply-To: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> (message from martin rudalics on Sun, 16 Jul 2023 10:26:04 +0200) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, monnier@HIDDEN, 64596 <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: Sun, 16 Jul 2023 10:26:04 +0200 > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > From: martin rudalics <rudalics@HIDDEN> > > From the POV of window management the situation is simple: When the size > of a window or a decoration changes, it would like to tell redisplay > about it. But redisplay would have to tell it first which kind of > changes it's able to accept. I don't think this is required. The information flow is unidirectional: the functions which change the windows should tell what they changed, and redisplay will then decide what that requires. For example, if some windows changed their dimensions, redisplay would need to know which dimension changed. > For example, I don't even know whether, when running without window > matrices, redisplay is capable of doing something reasonable with > the fact that the border between two adjacent windows shifted and a > third window not affected by that shift can be spared by redisplay. If the third window displays a buffer that didn't change in any way, then yes, the display engine should be capable of doing the above. On TTY frames, the display engine considers the entire frame, so it should see that the portion corresponding to that third window didn't change, and refrain from redrawing it. > As an example: one of the worst things the window code does is saving a > window configuration, reading something from the minibuffer and > restoring the window configuration when done. In nine out of ten cases > the restored configuration will not have changed and redisplay wouldn't > have to do anything. Now Fset_window_configuration is awful in the > regard that it deletes all windows on the frame regardless of whether > the configuration changed only to "restore" them later (including that > n_leaf_windows allocation hack to find out which glyph matrices can be > safely freed). While it is fairly easy to fix that, it's by no means > clear what and how to tell redisplay that some window did change in one > of those rare cases where it did. We need to add flags that convey the information about which windows changed what dimensions. > (let (config) > (set-frame-parameter nil 'left-fringe 50) > (y-or-n-p "?") > (setq config (current-window-configuration)) > (setq left-fringe-width 0) > (set-window-buffer nil (window-buffer)) > (y-or-n-p "?") > (set-window-configuration config)) > > Here 'set-window-configuration' should be able to tell redisplay that it > should redisplay the window but it should be able to tell that iff the > fringe really changed which is fairly easy to find out. Once it found > out, which kind of flag would it set? I'm not even sure it must find that out. It could simply tell redisplay that the fringe really changed. The rest is up to the display engine to decide.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:40:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 04:40:35 2023 Received: from localhost ([127.0.0.1]:46762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKxIw-0000YO-US for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:40:35 -0400 Received: from mout02.posteo.de ([185.67.36.66]:55093) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKxIu-0000Y8-Te for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:40:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 634F7240101 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 10:40:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689496827; bh=fqp5oCkRzXe3LTZirCqpGbwUzRg8BAeEvx5UaFstpnY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=PEGx6OkB7ZIN2hit5cHgN/NhaBlmHxTUDwLaZnAnip80RYsp32F1ETHBLR21I6uck I1E/AVRBNUEpIF/FWW6VjjYwp4J+79rbsSyASRBhZDKB/S+WHBCPjUCN5WSyEGKR+j uEH6o81IZ0rzm/wtPRKCLNLQCuQt1YQPwabp0BUlTGfpgyRRIN60LYprDeAbLT6UZw 4MExE8lDMYHwjZ5w/sd/9hYEDGy6WDqr02Luz+bWv04IjOUVeLVd5spbxuA5ErVOwH ObnthfmA4moxDFtbm4/olYVStHZmoRNjCEL8K9xeTnOM32WGtdmz5QUl8AkJw1qlrV gSW1rhBlfKM2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3dvZ0S74z9rxM; Sun, 16 Jul 2023 10:40:25 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: martin rudalics <rudalics@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> Date: Sun, 16 Jul 2023 08:40:38 +0000 Message-ID: <87wmz0i709.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 64596 <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 (---) martin rudalics <rudalics@HIDDEN> writes: > Here 'set-window-configuration' should be able to tell redisplay that it > should redisplay the window but it should be able to tell that iff the > fringe really changed which is fairly easy to find out. Once it found > out, which kind of flag would it set? May someone list all the possible displayed elements Emacs considers? I think that it might be a good new API to have a single function that marks things for redisplay. That function will accept arguments indicating what exactly may need to be redisplayed: CURRENT_TEXT_LINE, FRINGE, LINE_NUMBERS, CURRENT_BUFFER_TEXT, CURRENT_BUFFER_MODELINES, ALL_MODELINES, CURRENT_FRAME, etc. Then, every place where we request redisplay will call that single API function, while being very explicit what kind of redisplay it has in mind. That API function may be implemented in backwards-compatible way - we can just hide the existing logic inside for now and simplify later instead of directly manipulating global and local flag variables. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:26:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 04:26:21 2023 Received: from localhost ([127.0.0.1]:46738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKx5B-00009x-0e for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:26:21 -0400 Received: from mout.gmx.net ([212.227.15.18]:46401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <rudalics@HIDDEN>) id 1qKx58-00009j-KU for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:26:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1689495967; x=1690100767; i=rudalics@HIDDEN; bh=NG4Q5wQ1Y4st5ouzhYjUFCrCZ8m4KoIn6xuGAUZVJT0=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=PQcp3XLGmfoG0W43i0ISTCuhbGiufbNq31oHiQZIQs95owwJPQ8yVqPa0I/W6fdg+nuOYzZ x/awZkHZ4Yy7W14gU2cStRjw4az6CeDGo13dQMjD4exc4QdG9ELqVPUnII6tCMVbR2LB+Q0sU OTEZ1BWdnrdYSJua4kWPFSRb34Etqdz+1SjRXB0Cjet9XM0FYAmx+Pq6aNGnfgmCd7tVF6wRk GQceghkax8sGNGs6mh1B7/AMgI/cl18wnuujbwG/EsDS0VXFwugRIlWiD7RDZi88DqJrzdUY0 LUpbh8r6EXywEDhsmrgGzt13cKWYw3tLeNSG+OF/0fgXbEnH5i7w== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.1.100] ([212.95.8.133]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ofE-1pqckz2102-015oEI; Sun, 16 Jul 2023 10:26:07 +0200 Message-ID: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> Date: Sun, 16 Jul 2023 10:26:04 +0200 MIME-Version: 1.0 Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> From: martin rudalics <rudalics@HIDDEN> In-Reply-To: <835y6kbgik.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:HlAGhleFpWj/XO1oMlEI8Pbq23BTMhyShjGAThPDSYVXZze7M7T JKgeBFYO98a8MfqWd3ZwKS/3JQ2yuBcvlbvncqEkSAEpabAurVy4+A0N3CEuqSePoBt0iRn fqcFi70DjYpVli7MCZ/XrQSd8KzqZ9uSViOlDFxDjxcZ/eWdrZ2J4c7kV6Vy3jSUXkNEHJJ i+zmvt48yed1lbjraKTvQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:lMYrvFqY/4w=;y8SlwzX4YU87UphBBK3zaY83CXN LJJ+tMWe1oq6Eakeg+SbFLt1kMm6WqC1tS32TggQZ9lliDOBHn4bMYqVhuVPlpSPAYGrWwjRw iVgxuO49B7qVI4xwWDrrrfATA5n34oGBaA/H9eQVGrbLDVp+P6kTH6/61Z2XWm+jQtjAECy0C 1abZ9rKFzuSc/cypW8sNqinzyVa881ofuANAgEbyhud0b+JLiiBOEtPxXVjvS8PDD5j6S7u2k /Qkyppu/ruvwxSP3ypSX3w6rrFW0Hhh/b3LsqKY3zdv9RnlRDPhjAp7GOGFOZlBuCevRuCo2w pUfXusz2tkKg4nmvFXrmrc9rha9SUBAhz/WntYf9x9TwaosQeqT9ap731pB3mw4xUBc8XYwij Etnix+tKnhcgE6YTGeks5Xn+SAobyzUdCDAANmAy1mkzIskMlNuB9lu1t84wy9Opah5/SU//b GlUmMfqDDjB4qltnesYLLHghBoSbBmdAM+xni3Xwq4avBxMTHwnpxj9yTecTEcz3IU55pnTCU DYEcGgTmbmygPNemqgEJzymb+OrlbT0F3Z6Yz1isRHV5lCcS9I3iLhKs2lATS8k/UADXTUTTj d+MvKOBba/7zTtS/HDs7IQ1ZQou5NyEdpHXnmjBYL3U6VgEhGH0Wk1TqkFkIfVkFSwGzUGw5S flM5yWC7fAKVslMuh8zMMh/kaSo4/agM3kYUrt6a0R4xIQHG8ZmuzK9Q8woDVPXR8DjUTl91z RyTCh/yhlVGHQ6rFrCgcD69soF2D9tUFuF2W7EbyIo+u3khJLjqUZflfhLn1Ia4fO117schuh rZWyW8rhNAs9A83aKPF+tGUHM/xoimIqe7+0y8HtzgGBrZ3JM/EGjrzwQ5MKh5t3aCLnincsu FeP+eVeNR/r5diTsi5/5K1hQwzWqU+wu9pRU1rHjqbgZg+deRNa1IhsYlOQNLeHLkftdyLqmn f6lkvw== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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: -1.7 (-) > These global variables come from the time when the Emacs redisplay was > much less selective. It basically has only two modes: either > redisplay only the selected window, or redisplay all the windows on > all the frames. (Here "redisplay" means "examine for redisplay and > decide whether and which parts need that", not necessarily "actually > redraw".) When the various 'redisplay' flags were added, the intent > was to make redisplay more selective, so that it could completely > refrain from examining windows on a certain frame, for example. The > right way to keep advancing in that direction is to extend these flags > and maybe introduce more flags that will describe the need to > redisplay in more detail. Global variables such as update_mode_lines > can do that only if they provide specific values to describe each > required aspect of redisplay. But in any case, the code which sets > the variable cannot make decisions for redisplay, it can only describe > the changes for redisplay to consider. From the POV of window management the situation is simple: When the size of a window or a decoration changes, it would like to tell redisplay about it. But redisplay would have to tell it first which kind of changes it's able to accept. For example, I don't even know whether, when running without window matrices, redisplay is capable of doing something reasonable with the fact that the border between two adjacent windows shifted and a third window not affected by that shift can be spared by redisplay. So from the POV of window management, redisplay would have to offer a list of such flags it is able to handle and do something reasonable about. As an example: one of the worst things the window code does is saving a window configuration, reading something from the minibuffer and restoring the window configuration when done. In nine out of ten cases the restored configuration will not have changed and redisplay wouldn't have to do anything. Now Fset_window_configuration is awful in the regard that it deletes all windows on the frame regardless of whether the configuration changed only to "restore" them later (including that n_leaf_windows allocation hack to find out which glyph matrices can be safely freed). While it is fairly easy to fix that, it's by no means clear what and how to tell redisplay that some window did change in one of those rare cases where it did. Try the following simple scenario which currently breaks redisplay: (let (config) (set-frame-parameter nil 'left-fringe 50) (y-or-n-p "?") (setq config (current-window-configuration)) (setq left-fringe-width 0) (set-window-buffer nil (window-buffer)) (y-or-n-p "?") (set-window-configuration config)) Here 'set-window-configuration' should be able to tell redisplay that it should redisplay the window but it should be able to tell that iff the fringe really changed which is fairly easy to find out. Once it found out, which kind of flag would it set? martin
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:35:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 03:35:34 2023 Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKwI2-00078Y-Fq for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:35:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKwI0-00078L-1c for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:35:33 -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 1qKwHt-0002Fr-UG; Sun, 16 Jul 2023 03:35:25 -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=4H/v7A6ODAPkKJKE7picPeT18VayrG+PHsPtU0DVpMc=; b=ZLkaJqpdbpNU 4X7ObEBP4F5Y2k0VfmPlSaURlUdQcawcNAUvVh6VNtRPOFtnzeGp6JrAshi0pv5HoFdu/F4jMbGoP g0c7Vy3a3mqDSW88tLNoEi/fv8C7e6vT7w1EibKG48Uqt4OqseaMjEt19vXNeM8hbCW2DlaIetSEH p6SVS6O0wPcSpr3Xmd2tU82GUZW1c25hyLaawFdBG47gBGsLjqEMaQzf+5lZyaK1R/RBgct3AJGCs MMYAyCdlCYiaVfGFPs+G+qIGLXI0Oo35j3dBwDqrWo1+RgODkSwvevgFucQfOUPZPDg/itsEW3DOJ M/K6SBKBjDercLHZ0KIPjA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKwHt-0002rI-Cf; Sun, 16 Jul 2023 03:35:25 -0400 Date: Sun, 16 Jul 2023 10:35:49 +0300 Message-Id: <83lefg9ulm.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87edl8mi2e.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 07:28:09 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost> <83ttu49vhn.fsf@HIDDEN> <87edl8mi2e.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 07:28:09 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> BTW, is there any particular reason why windows_or_buffers_changed is > >> not a queue of windows/buffer to be re-displayed? > > > > Why do we need such a queue, when the redisplay flags of buffers and > > windows are supposed to tell us that already? > > To not loop over all the existing windows and frames in xdisp.c:506 > redisplay branch. Someone will have to demonstrate that this is worth our while. Testing a single boolean flag is not an expensive operation, while maintaining that queue also takes CPU. Also, some changes in a window can affect other windows on the same frame, for example if the window is resized. IOW, maybe it's a good idea and maybe it isn't, but it definitely doesn't affect the most expensive parts of redisplay.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:28:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 03:28:06 2023 Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKwAo-0006tI-3j for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:28:06 -0400 Received: from mout01.posteo.de ([185.67.36.65]:37189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKwAl-0006sm-Nh for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:28:04 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 05D84240027 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 09:27:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689492478; bh=2nH/j/WTNFa8sbCbzpjPe88ZWfTBOr2CIjOwZ73ikIM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=EAZlcePZ8ytxLO1dlMTsUP7uuZvahxMFfZego+ecs7NylzT2xKDYIw8jJZyVwLpCE svx5oWyxlEaFSzuqn4bMiNVpwM9mP8/sfObZpRXoPY7d4ueZvz/nF5Cy1BcTVUTVAS MH4V2HsOvuC4zvbC7VZj8DCY7KYrM3aTc/lTlOITbVUpMWqZRGsHlkBjYfQ2CqT4rw xifVp795oul9pqUQpFKTrQui+JW8EJ0CGpd6vRrGU7bbU6Chx0c0BeKrHOVoBsfnMM velOZTxTtFP+OZe3s3Wh6iKmAhHTeATSI1rwnFxJ/0S50ixKCSKEenPYfexn7kTrcx 0z3V+TvQ16YBA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3cHx0nJJz6txm; Sun, 16 Jul 2023 09:27:56 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83ttu49vhn.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost> <83ttu49vhn.fsf@HIDDEN> Date: Sun, 16 Jul 2023 07:28:09 +0000 Message-ID: <87edl8mi2e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> BTW, is there any particular reason why windows_or_buffers_changed is >> not a queue of windows/buffer to be re-displayed? > > Why do we need such a queue, when the redisplay flags of buffers and > windows are supposed to tell us that already? To not loop over all the existing windows and frames in xdisp.c:506 redisplay branch. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:16:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 03:16:20 2023 Received: from localhost ([127.0.0.1]:46546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKvzP-0006XQ-KO for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:16:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKvzO-0006XC-0N for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:16:18 -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 1qKvzI-0004iP-QA; Sun, 16 Jul 2023 03:16:12 -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=b9LxLShADQXCJ0g7IcdlyL1gCmX6QiiPFiM/sm0T/J4=; b=T1MEUoqdZVoX XOO/WFnMP7RaWUPKwLOpWnU5iQvhqQt1px0o2/nFFYOET7W1KwasZ3iYnrRwSNwfd9A1PxDwrzQtq ZeYvYclZJu7ABTNDXj4EX64GgB/APl+oHcqYMlr6xx5zG6AXfVbOdD3OliBj02QN/cA8kPEDYwXcA XoYDUufvp12sIO8mOKazXZxCGpBCiE15eX3t/5pYD02hjyjnAl1hcTGqwy/YBOOUdORsneI6rvz/B o7FAIyIUbGQo/ETYQqVHckKnXlYSS4+KvgYYWU+VNNtGMEu/73oJx5wnrVyoernlExxihXh7OG3Fy bG37x2zYbmw8TTV0TYtO5w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKvzI-0005bX-Aw; Sun, 16 Jul 2023 03:16:12 -0400 Date: Sun, 16 Jul 2023 10:16:36 +0300 Message-Id: <83ttu49vhn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <871qh8o12z.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 05:52:04 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 05:52:04 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > > - /* True means redisplay has to consider all windows on all > > - frames. False, only selected_window is considered. */ > > + /* False, means that only the selected_window needs to be updated. > > + True means that other windows may need to be updated as well, > > + so we need to consult the `redisplay` bits of > > + all windows/buffer/frames. */ > > bool consider_all_windows_p; > > BTW, is there any particular reason why windows_or_buffers_changed is > not a queue of windows/buffer to be re-displayed? Why do we need such a queue, when the redisplay flags of buffers and windows are supposed to tell us that already?
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:15:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 03:15:17 2023 Received: from localhost ([127.0.0.1]:46537 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKvyM-0006V5-KH for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:15:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKvyJ-0006Uo-SZ for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:15:13 -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 1qKvyE-0004Xj-2x; Sun, 16 Jul 2023 03:15:06 -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=xK8EFX5/ypo3HFJr5BPjQjJTkG44TO2A5jBfdSX4KkM=; b=gg2+rAzz0aS8 l6AcySKQxDHHfA2qPSqNwRWg8yhm8aSh0uorN9zq3de2n/Ej43GotweVm5F551UnzlVb9VP2paFTS c788l7QzyTmGbvkxPgxqqM4lQfoRqsNxprMDF8AEJfhEBjaYMPtRsoFXo09vnjGq1RCcD2epx7TLR IPJKtN83mXqOa7ztkBHFRBYPcuytaVLUADrqIqekGGOODIndVnFRT/WJvi7+rGe0ahWBgM+Jrit8h wO3owL0wvLrdYt0PwgkQZ3YBWbR3Koz5IDz7NS1BpwqAr9Hd3sR2R/NmHEm5k6ULQSg/E8gctfvxl yoDF0+Co5UXrmMFrVc/3nA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKvyD-0005PR-Fc; Sun, 16 Jul 2023 03:15:05 -0400 Date: Sun, 16 Jul 2023 10:15:28 +0300 Message-Id: <83v8ek9vjj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <874jm4o16u.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 05:49:45 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <874jm4o16u.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sun, 16 Jul 2023 05:49:45 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> At least, when the current buffer is only displayed in a single, > >> selected window, checking every window should not be necessary. > > > > The code which sets update_mode_lines doesn't know whether the current > > buffer will be displayed in a single window by the time redisplay > > kicks in. It doesn't even know whether it will still be the current > > buffer by that time. Because the Lisp program that is running and > > making the changes which cause update_mode_lines to be set can change > > these things before it finishes. > > If the selected window changes for any reason, redisplaying the > previously selected window will be queued by select_window: Yes, but what does this have to do with what I wrote? My point is that where we set update_mode_lines we cannot yet know whether only the selected window will have to be redisplayed.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:52:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 01:52:01 2023 Received: from localhost ([127.0.0.1]:46404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKufp-00041O-70 for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:52:01 -0400 Received: from mout02.posteo.de ([185.67.36.66]:60981) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKufm-000415-K4 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:51:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1822A240103 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 07:51:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689486713; bh=cHkSOdtApEdfNQtwrf92qQ03LQATzP0/RbLcmhD1gRA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=BRnX4YllZBGyMeqz6te+rthElTjtwN5qlZ82pMOgknKmbIBEGcl6NSACzQs3XA7y1 V3IE4buBCvkBHnfSTgAKFlS7Gvx2FPCWJbpJukyPzuM1D+ON8QfpHyG59AdZO8ghOF xUrcSA3vY0onGT8WVuNhKlZv+xQfNgY6Mf87xcdyDuS/1tzHhpbQHsTGYsju+sDYe0 ZC4Yc69O3WRUF8foEO/rKvkjNq3nMf2rj8wiGOuOvZZSWqwYUDfl1wlFleGwnb4JND cyD5CcQUZ2zUtpYGavMclkGZm+EMUcsL06/9emUtL7POMjKYGtHAhzVORJq4psvEza z0LDKKbfti22A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3Z942tkHz9rxF; Sun, 16 Jul 2023 07:51:52 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> Date: Sun, 16 Jul 2023 05:52:04 +0000 Message-ID: <871qh8o12z.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---) Stefan Monnier <monnier@HIDDEN> writes: > - /* True means redisplay has to consider all windows on all > - frames. False, only selected_window is considered. */ > + /* False, means that only the selected_window needs to be updated. > + True means that other windows may need to be updated as well, > + so we need to consult the `redisplay` bits of > + all windows/buffer/frames. */ > bool consider_all_windows_p; BTW, is there any particular reason why windows_or_buffers_changed is not a queue of windows/buffer to be re-displayed? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:49:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 01:49:52 2023
Received: from localhost ([127.0.0.1]:46400 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKudj-0003ku-Lt
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:49:51 -0400
Received: from mout02.posteo.de ([185.67.36.66]:49407)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qKudf-0003ka-A4
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:49:50 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id 5D3A2240103
for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 07:49:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1689486581; bh=ADE8PfVsGdNHizkB4cSDWudkIHsdaucPnACEp2FsOnE=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
b=fbSpTdWVlXUQsDwAnhS0ytRyb627Kn7aQ75xTnF1dNJxE+D9dBoUvFIuk6CCia5Qv
pWMKIKDh2v8+mIVNqQ16k0WJ7zvpmMbrUBsD1cyFGZkbaFbiVH6YmkZWw8yDTkBd42
Pt4LTAkvwWIMUFa5M7EVcBxDbWiRi/vbruO3+kc29RZXhhf1Mpr3ezbP22OGkMeN6p
j04bL+YS51Cr8EOxk8eFUELk7SL6dG2wDL35A1MOMeGgAMpQE2V2kHIEtb+HZBmhTz
1vVbU4kM26Y+knMhTrkpD0osVPtnQ0h9sqLC2SOVjooF2z1MqScg4WZRNhAbY3nhpN
qGwpCVubUd+ow==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4R3Z6V3X3mz6txj;
Sun, 16 Jul 2023 07:49:38 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <835y6kbgik.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
<jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
<jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
<jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
<jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
<83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
<jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
<jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
<jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
<877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 05:49:45 +0000
Message-ID: <874jm4o16u.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: monnier@HIDDEN, 64596 <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 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> At least, when the current buffer is only displayed in a single,
>> selected window, checking every window should not be necessary.
>
> The code which sets update_mode_lines doesn't know whether the current
> buffer will be displayed in a single window by the time redisplay
> kicks in. It doesn't even know whether it will still be the current
> buffer by that time. Because the Lisp program that is running and
> making the changes which cause update_mode_lines to be set can change
> these things before it finishes.
If the selected window changes for any reason, redisplaying the
previously selected window will be queued by select_window:
if (NILP (norecord) || EQ (norecord, Qmark_for_redisplay))
{ /* Mark the window for redisplay since the selected-window has
a different mode-line. */
wset_redisplay (XWINDOW (selected_window));
wset_redisplay (w);
}
else
redisplay_other_windows ();
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:17:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 01:17:12 2023
Received: from localhost ([127.0.0.1]:46382 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKu87-0002ox-4w
for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:17:12 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51338)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKu81-0002oM-OA
for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:17:09 -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 1qKu7t-0000ed-QB; Sun, 16 Jul 2023 01:16:57 -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=djeeENSdKel2rwfUnBMyv7fOOZzJKi461iim1kLtq+4=; b=seBXyuBmI44L
6ZvnOxkjdT3tEY/RubxgLcQo7u+fHY6JEJ1mXny2KqHudKKdu7qHrKnrqipn7xZfq2STPwwJVh5hj
fP5KeEA419CyDth0yNfN6OMluLJxeOLMjZgtwpOIgs9g/OmAddM7retYG78d/iO2BHIDS579RHrxw
OK2gEgu7uDNdg5LgtFKiH9JTHjG2agBU2rebFZMLwC/r+/z1DmO/aID8738HM+/OdIdvhN6K40PwP
jP0nR53NUU6JdWKNNg1ev/nNQ1VDS9kP9We6Buu4zODMJXBaMHqN3nTicNhl9QS0OpAL50yCb1U3w
aZUHkSNfLDdM5tln9uNCjg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKu7r-0003D1-KN; Sun, 16 Jul 2023 01:16:57 -0400
Date: Sun, 16 Jul 2023 08:17:19 +0300
Message-Id: <83zg3wa10g.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sat, 15 Jul 2023 18:53:19 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
<83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 18:53:19 -0400
>
> > The actual issue with the above is different: it implies that
> > update_mode_lines _always_ indicates that more than a single mode line
> > should be updated (which is why we need to "consider all windows").
>
> How 'bout the wording below, then?
OK, provided that you remove that redundant comma
> + /* False, means that only the selected_window needs to be updated.
^
there.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 04:56:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jul 16 00:56:53 2023 Received: from localhost ([127.0.0.1]:46367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKtoT-0002Al-5k for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 00:56:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKtoQ-0002AV-DM for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 00:56:51 -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 1qKtoK-0002hZ-G3; Sun, 16 Jul 2023 00:56:44 -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=ekfPrg1oY1FuKkEbx+/lgsSTTYrtOT0y7B+F9XvCev4=; b=TgL0TtT6TDXq 2pnuuuMwoeG7kZemjyPtbS56iFFilSOHipagcOZkoppVnlzaXPoFJXAr2TQEqNEwsxN6nk8zdBkkN ao2qlc1fOsgWaKp/1RDkSb3dZ7WXVh7nZW3hMupxeKj1qOKsOFQv1yJTLNijhXMF4TY+OF6Gin0Pn XlblXsT32DoyrX6kvFMHcWejMmF4t4E4btL5Md0Fn1ZAkCVQactGqlKd7zLzU36EEcCSnJIFw2All 6C58bzcXZzyS7LKOrjEXZLmyDXDf1d9i7Be4QJZegSVNSAJ7QjtOmKAk12l2zqpViN8Kte8NxyvHT sHXA1FtE56dgAKvmx+LadA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKtoJ-0004SJ-No; Sun, 16 Jul 2023 00:56:44 -0400 Date: Sun, 16 Jul 2023 07:57:07 +0300 Message-Id: <835y6kbgik.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <877cr1nep6.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jul 2023 19:43:17 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Sat, 15 Jul 2023 19:43:17 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The actual issue with the above is different: it implies that > > update_mode_lines _always_ indicates that more than a single mode line > > should be updated (which is why we need to "consider all windows"). > > But is that actually true, i.e. does every place that assigns non-zero > > to update_mode_lines indeed perform a change which makes it > > _necessary_ to consider non-selected windows? > > At least, when the current buffer is only displayed in a single, > selected window, checking every window should not be necessary. The code which sets update_mode_lines doesn't know whether the current buffer will be displayed in a single window by the time redisplay kicks in. It doesn't even know whether it will still be the current buffer by that time. Because the Lisp program that is running and making the changes which cause update_mode_lines to be set can change these things before it finishes. These global variables come from the time when the Emacs redisplay was much less selective. It basically has only two modes: either redisplay only the selected window, or redisplay all the windows on all the frames. (Here "redisplay" means "examine for redisplay and decide whether and which parts need that", not necessarily "actually redraw".) When the various 'redisplay' flags were added, the intent was to make redisplay more selective, so that it could completely refrain from examining windows on a certain frame, for example. The right way to keep advancing in that direction is to extend these flags and maybe introduce more flags that will describe the need to redisplay in more detail. Global variables such as update_mode_lines can do that only if they provide specific values to describe each required aspect of redisplay. But in any case, the code which sets the variable cannot make decisions for redisplay, it can only describe the changes for redisplay to consider.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 23:10:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 19:10:27 2023
Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKoPD-0001R2-Cz
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 19:10:27 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60038)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKoP9-0001Qj-S2
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 19:10:26 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 95FD28065C;
Sat, 15 Jul 2023 19:10:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8F881805DE;
Sat, 15 Jul 2023 19:10:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689462617;
bh=U1dfbkM0UQfa/ILHec4hu/Bz3ioXQe6MPvnIFb51HMc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=LRyv8hzWaVxh2srW7Oj9z8QTUhJB3wzp4OzsE2yu8waWMpbXekDhAnOjP467sTFt+
BOnZkAuCvPkyq+Uc7CNqj2BEtlGUNSeUqhtUcQbk1diNCCkGz6IKu8C88Iu9d1vhzQ
PIDurAdt8KBpDQe6SR4TJXLaJd+rL9tIoNmGhj9LYzgQQOrPxenW2RYjzpMlgvlGfa
CVOqdXHydcQYKa9YQ16anN475qRw9gn8P4qMLWgI3kp3FuQKltWfewc/6uqbij8Q5z
ObecoQIgcRgYkl05X2XKEqgkswuoNeyqq5oMFXrD1E/4W5g7eOKOq4CT0jw2kl0FPB
XpUxW77SaB3Xw==
Received: from pastel (unknown [104.247.238.169])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65E2B120165;
Sat, 15 Jul 2023 19:10:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <877cr1nep6.fsf@localhost> (Ihor Radchenko's message of "Sat, 15
Jul 2023 19:43:17 +0000")
Message-ID: <jwvr0p8aisb.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
<83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost>
Date: Sat, 15 Jul 2023 19:10:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---)
>> The actual issue with the above is different: it implies that
>> update_mode_lines _always_ indicates that more than a single mode line
>> should be updated (which is why we need to "consider all windows").
>> But is that actually true, i.e. does every place that assigns non-zero
>> to update_mode_lines indeed perform a change which makes it
>> _necessary_ to consider non-selected windows?
>
> At least, when the current buffer is only displayed in a single,
> selected window, checking every window should not be necessary.
Indeed, we have a special case for that. Before my change, it was
either "just the selected window" or "all windows".
> Compare bset_redisplay and bset_update_mode_line.
Indeed the old code updated all windows after a call to
`force-mode-line-update` even if the current buffer is only displayed in
the selected window and I somewhat preserved that :-(
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 22:53:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 18:53:33 2023
Received: from localhost ([127.0.0.1]:46240 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKo8q-00010u-Lx
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 18:53:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38950)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKo8l-00010d-Gt
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 18:53:31 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DE8E380065;
Sat, 15 Jul 2023 18:53:21 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D53F6801B3;
Sat, 15 Jul 2023 18:53:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689461600;
bh=SxdmDD+vgzHQ86JcdkDNX5BMMkJIc/tcKWHbNYQxgSE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=jAxghVCYI2vKX5wtKJIz8k6WZCwTX9/09nNTQDM2njp01cRLUM7jMWthSG5z5bIvY
zLlbnjDT4QRGGW1bOsxgLD6heqz+UcRdtPR/eGsA9QAfRaxVBhuDGtDYxL2/7sxPxQ
vBtTxPPFjmAoUomWY2RVSytm+l1z+354IwALQ1otlLnDTQrLl7H2mKwhr2L5jS+PUu
bBKTdd4X3DvAm37pisjmHDRCwi6ibDMHepqsBNyDcPuF/Hg4pR8oEllcV3J1qI+T33
CtRV7MK3x3AvTqR27TjnmptApJbQiTcy4ptkTDyB+AR1rarbxaTDvvTtD9rcLFGlnY
ghZJTVeu0FG6g==
Received: from pastel (unknown [104.247.238.169])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ABA721201FF;
Sat, 15 Jul 2023 18:53:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83a5vxas9k.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
2023 22:28:39 +0300")
Message-ID: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
<83a5vxas9k.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 18:53:19 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
>> Sorry, I skipped this part in my previous email.
>> I understand the above code, but I'm not sure what explanation might
>> be needed so you can understand it as well. Maybe the problem is the
>> name `consider_all_windows_p` which suggests that all windows will be
>> updated, but it only says that we should loop through all the windows to
>> try and find those which need to be updated.
>
> The actual issue with the above is different: it implies that
> update_mode_lines _always_ indicates that more than a single mode line
> should be updated (which is why we need to "consider all windows").
How 'bout the wording below, then?
Stefan
diff --git a/src/xdisp.c b/src/xdisp.c
index a3464c2c375..13f4fbca074 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -16490,8 +16490,10 @@ redisplay_internal (void)
enum {MAX_GARBAGED_FRAME_RETRIES = 2 };
int garbaged_frame_retries = 0;
- /* True means redisplay has to consider all windows on all
- frames. False, only selected_window is considered. */
+ /* False, means that only the selected_window needs to be updated.
+ True means that other windows may need to be updated as well,
+ so we need to consult the `redisplay` bits of
+ all windows/buffer/frames. */
bool consider_all_windows_p;
/* True means redisplay has to redisplay the miniwindow. */
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:43:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 15:43:21 2023 Received: from localhost ([127.0.0.1]:46138 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKlAn-0001o7-CQ for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:43:21 -0400 Received: from mout02.posteo.de ([185.67.36.66]:37691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKlAl-0001nt-LV for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:43:20 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 8010C240101 for <64596 <at> debbugs.gnu.org>; Sat, 15 Jul 2023 21:43:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689450193; bh=oh2TJJryrxapV4cSw7ocrYEMQSCwugJHsAB1KKLlNw0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=K69GxFVa6yq7WUBo0vYLU1LJ9WEr5S1y325KTw+jSu6dep1Y1nNr/LaQW+NjEqB7f ZYagGP2ZXbQji8+ukoaez0j0Nzgl6l6FwQ6VFcAXGP86Q5dciypMuzalLAxTpTeW8k P1B1WPtLsvJnOD4GS61JIba6Razt1rVddq7zRadwgcZ4a5vchrW7YbTbLj8AJ6nI4D oyZJojdMbIha3RIm2ofkx5VufIKhNxAD/faQU7EHBP1tTHtIb9uMnvgmbqxkIdz+59 DYk0JlUhDkCtPABCRO6u5QogQYaERRwh3p0BQ3jMimap63ZINUMKwbWLITEAlvv/gw 6wPCvs3cXZ91w== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R3Jfm4lwfz6twR; Sat, 15 Jul 2023 21:43:12 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83a5vxas9k.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN> Date: Sat, 15 Jul 2023 19:43:17 +0000 Message-ID: <877cr1nep6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: > The actual issue with the above is different: it implies that > update_mode_lines _always_ indicates that more than a single mode line > should be updated (which is why we need to "consider all windows"). > But is that actually true, i.e. does every place that assigns non-zero > to update_mode_lines indeed perform a change which makes it > _necessary_ to consider non-selected windows? At least, when the current buffer is only displayed in a single, selected window, checking every window should not be necessary. Compare bset_redisplay and bset_update_mode_line. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:28:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 15:28:24 2023 Received: from localhost ([127.0.0.1]:46118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKkwK-0001Om-Bf for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:28:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKkwI-0001OZ-Kt for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:28:23 -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 1qKkwD-00056y-Ao; Sat, 15 Jul 2023 15:28:17 -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=8Nhr0hTD8QreDN5PAa9lS65D6nZ1ZKcNewZ3d88NIOU=; b=Y/mUu1K5IEPS nIGGpEjP64bCiPKEGcP0MxqbClwgl0iR/5gKlBDHn/JVJcAkZVfGrcD+8taqHiKpNk5EJ+0JLsfIT Cz608R696CY1W7frbVTP5r0RrNfghOBwI2tjUmv5+KlaCMIZKjakp6ksMBlTP6uw5d6vpXYD+TwOb HZqLrcjB9n18O5DW3iD5k7L+HXuiRTtGSPsf+f93tB5aH2T73QZC0q4rXUNZ32+6Nvp8n7Cd1riGx /EAPuIuH3oKrko0mKT5GwAtWf/4Q+Ed80WyKD5gyBs01eRN+dzH3AfWyFGCetK3+CCdDyA82GQL5q qTjdqPi93L4U+zsWpVSJJA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKkwC-0005Uz-Op; Sat, 15 Jul 2023 15:28:17 -0400 Date: Sat, 15 Jul 2023 22:28:39 +0300 Message-Id: <83a5vxas9k.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 15 Jul 2023 14:15:41 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sat, 15 Jul 2023 14:15:41 -0400 > > > Or why redisplay_internal does this: > > > > consider_all_windows_p = (update_mode_lines > > || windows_or_buffers_changed); > > Sorry, I skipped this part in my previous email. > I understand the above code, but I'm not sure what explanation might > be needed so you can understand it as well. Maybe the problem is the > name `consider_all_windows_p` which suggests that all windows will be > updated, but it only says that we should loop through all the windows to > try and find those which need to be updated. The actual issue with the above is different: it implies that update_mode_lines _always_ indicates that more than a single mode line should be updated (which is why we need to "consider all windows"). But is that actually true, i.e. does every place that assigns non-zero to update_mode_lines indeed perform a change which makes it _necessary_ to consider non-selected windows?
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:18:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 15:18:26 2023 Received: from localhost ([127.0.0.1]:46105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKkmg-0001AL-Cf for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:18:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKkmd-0001A7-NC for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:18:24 -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 1qKkmY-0002Eg-8O; Sat, 15 Jul 2023 15:18:18 -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=4YAYeV9DKtl1DKnROyykwsm9KFwtjaHOlkscQxffw3Y=; b=OkiJkKRlVd9i jd5dc+QKGijQ5KNRqE2Eg9sVE6eNJSXERJ/Ru72gPnYseDwrys6yHYs7jtYFcardEEzcBIS7Cn5ve Fl9k1U7HKVGIWhodxFWx3oUz/9WN3CI2eHNE3B4REzSqV/m+jKZA9ZYM9qgn7DAE804w6VZW+Oo/3 iiEg0KLWsDOV4TTZoyf4feQA4oI6GiawbjOOKTRoLJydXpsdngnG9HEMNRuJHm0z/f5vicgZQK2Sm Ulqi/QGi2cRPC4BOseSwbPPs8jJ6vSPcXoF6u3NrOHMcEVMHa8XeQ/3GR1Zxq0dUgp1t93GKcFQcR eKW340X7PSQPmR5LlYcYAw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKkmX-0001pQ-On; Sat, 15 Jul 2023 15:18:18 -0400 Date: Sat, 15 Jul 2023 22:18:40 +0300 Message-Id: <83cz0tasq7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 15 Jul 2023 14:15:41 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sat, 15 Jul 2023 14:15:41 -0400 > > > Or why redisplay_internal does this: > > > > consider_all_windows_p = (update_mode_lines > > || windows_or_buffers_changed); > > Sorry, I skipped this part in my previous email. > I understand the above code, but I'm not sure what explanation might > be needed so you can understand it as well. Maybe the problem is the > name `consider_all_windows_p` which suggests that all windows will be > updated, but it only says that we should loop through all the windows to > try and find those which need to be updated. > > Would the patch below help? It probably would. (The meaning of the variable was clear to me before this, but maybe it will help others.) Thanks.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:05:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 15:05:10 2023
Received: from localhost ([127.0.0.1]:46087 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKkZp-0000r6-JL
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:05:10 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57134)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKkZm-0000qb-K5
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:05:07 -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 1qKkZg-0006rx-Ja; Sat, 15 Jul 2023 15:05:00 -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=nNb2FLomul02H6nWN1uwvrVTC80OghQVgNBFsN6/4vQ=; b=DRXmwcjlBo5P
gvFCv8cFnlbu1YvBQMCrIIiKPUn8NuzfTmax/xtKxPSWf2pT+kFhWMbWextOzUZ7Ipj+JGA8ISW9F
DfLdA0cGP22QE8A4gagwwURSKEl6G2/9hwqEkXSAL/C1/UYcVxr/kDXmUF9psS0xHnNXoj18MHzWS
J4xGO5IbooieZui338qlEJkaV+x0qxuP+U1oDtCCezaRLjMuOUqIW7f0GbQGcghn+PrBeEivWkQiN
2ZXrrsby5/CbfH+QOHad6SwZnNMwBsa3nV4mjjASBtnPX0PLEJBUdWo6kRiq6ras8CmWqIXIPhF5h
l1Pus1cFoEreP98kk2B/8A==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKkZI-0000XU-W5; Sat, 15 Jul 2023 15:04:52 -0400
Date: Sat, 15 Jul 2023 22:04:53 +0300
Message-Id: <83h6q5atd6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvilalayz0.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sat, 15 Jul 2023 13:15:39 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN> <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 13:15:39 -0400
>
> > Not entirely true, AFAIU. For example, what does update_mode_lines
> > have to do with preparing the menu bar?
> >
> > static void
> > prepare_menu_bars (void)
> > {
> > bool all_windows = windows_or_buffers_changed || update_mode_lines;
> > bool some_windows = REDISPLAY_SOME_P ();
>
> Indeed `update_mode_lines` means more than just mode-lines. It includes
> of course header-lines (of course), frame names (less obvious), and also
> the menu-bar, and some of those links are indeed not 100% clear.
>
> WDYT about the patch below?
That's an improvement, thanks. But it still isn't everything. For
example, what about resize_echo_area_exactly: why does it set this
variable? Also, this variable is tested in update_tool_bar and
update_tab_bar, so the comment you suggest should mention tool bar and
tab bar as well. Unless you know the answers to these questions, I
guess more digging is in order.
And I'd be happier if, instead of a single variable for so many
purposes we would have either several separate variables or make this
one a bitmap, where each bit says something very specific about the
part of the display that needs updating. Any takers?
> -/* Non-zero if we should redraw the mode lines on the next redisplay.
> +/* Non-zero if we should redraw the mode line*s* on the next redisplay.
> Usually set to a unique small integer so we can track the main causes of
> - full redisplays in `redisplay--mode-lines-cause'. */
> + full redisplays in `redisplay--mode-lines-cause'.
> + Here "mode lines" includes also header-lines and frame names, and
> + apparently also menu-bars. The link with header-lines is clear,
> + but a bit less so for frame names and the menu-bar. */
Btw, we need some function to show the information in
redisplay--mode-lines-cause in human-readable format, or at least a
documentation for how to examine it. Without that, this variable is
probably useful only to a very small group of people.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 18:15:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 14:15:59 2023
Received: from localhost ([127.0.0.1]:46064 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKjoF-0007zw-3J
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 14:15:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12203)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKjoA-0007zT-3A
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 14:15:57 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D24B080327;
Sat, 15 Jul 2023 14:15:48 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8E184801B3;
Sat, 15 Jul 2023 14:15:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689444943;
bh=RJQgviS1hhSkoO+ZHAR+r2kh59nvxAfnSpNhXhbY0eM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Z8Onog/JC8CYobmqGR/mEjt9qUUbobpW5/pzUqoDsAFOZFVN4opYDIIJRZmAMOT9P
LdH5cs7oTH2H3Tswt/DQyqfxZRX2XGaWmeHtwS3IpgwwQp2RtlvWmDtqtn9+ANr3cO
Y6GMepH49jIu/fqVNQFETDUWscMFHIZdMIdrOphnc66WFSji2m5pUgSqL73zAkmiaf
CCojDQKUQ76XOp1qrTT9a2gj6xceVpb297TAh2OpahO0M04h0/ZhBgWRawiTYpteQJ
F4H+/oAOMiWoA6vLlf7yklWe5sqSJamKI81r/Z+Q7ynfD7MhQyFygwobzexcVQlODy
NHJUjuBGc1h9w==
Received: from pastel (unknown [108.175.230.17])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 10B791202F2;
Sat, 15 Jul 2023 14:15:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83jzv1b152.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
2023 19:16:57 +0300")
Message-ID: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 14:15:41 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.062 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> Or why redisplay_internal does this:
>
> consider_all_windows_p = (update_mode_lines
> || windows_or_buffers_changed);
Sorry, I skipped this part in my previous email.
I understand the above code, but I'm not sure what explanation might
be needed so you can understand it as well. Maybe the problem is the
name `consider_all_windows_p` which suggests that all windows will be
updated, but it only says that we should loop through all the windows to
try and find those which need to be updated.
Would the patch below help?
Stefan
diff --git a/src/xdisp.c b/src/xdisp.c
index a3464c2c375..385569d9309 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -16491,7 +16491,9 @@ redisplay_internal (void)
int garbaged_frame_retries = 0;
/* True means redisplay has to consider all windows on all
- frames. False, only selected_window is considered. */
+ frames. False, only selected_window is considered.
+ If true, the set of windows we try to update is further limited
+ according to the `redisplay` bits in buffers/windows/frames. */
bool consider_all_windows_p;
/* True means redisplay has to redisplay the miniwindow. */
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 17:15:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 13:15:52 2023
Received: from localhost ([127.0.0.1]:45864 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKis4-0006Ay-6s
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 13:15:52 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30716)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKirz-0006Ag-Ua
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 13:15:51 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A61C18065C;
Sat, 15 Jul 2023 13:15:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 510FF805DE;
Sat, 15 Jul 2023 13:15:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689441341;
bh=xzSgMR3y3iaHrBZAb1tquiLtiAQpr4CJySvHnOkYqXk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=foG9SO/O6sB2+hb38zcNUoSxcTiX9/TolFcSHTk6ECPD3OrXBwqnzFZwIpIwYJnBG
4uf2XJrpxw7SNeIApDRctCJxmOKDvkULutIRDKJ5CTkHxFMADrzYhPwgkgpzkREDv2
dWDZYbKG3AsC6nTJMFLGzxu4NWiaOLo8mkAyENFeBJbk6Ajw30akHY8f7CRM42u7j3
eEytMz2W32lS+Da0k9FtVAd95pqnqHj++nf6amK7/yAjv+KLg19S7b+ixRbiGCVBcT
cSssJ1YmbvVyuD36c1bK/g1VtkUCpq3goiiKFXvwGbvmLJX6UamUnh2csucLlQmHBB
PM2J4jJNYl2OQ==
Received: from pastel (unknown [108.175.230.17])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 249CD12034B;
Sat, 15 Jul 2023 13:15:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83jzv1b152.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
2023 19:16:57 +0300")
Message-ID: <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
<83jzv1b152.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 13:15:39 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.083 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> Not entirely true, AFAIU. For example, what does update_mode_lines
> have to do with preparing the menu bar?
>
> static void
> prepare_menu_bars (void)
> {
> bool all_windows = windows_or_buffers_changed || update_mode_lines;
> bool some_windows = REDISPLAY_SOME_P ();
Indeed `update_mode_lines` means more than just mode-lines. It includes
of course header-lines (of course), frame names (less obvious), and also
the menu-bar, and some of those links are indeed not 100% clear.
WDYT about the patch below?
I'll try to update the docs to clarify this.
Stefan
diff --git a/src/window.h b/src/window.h
index 2f793ebe438..48d3fd3dc82 100644
--- a/src/window.h
+++ b/src/window.h
@@ -1114,9 +1114,12 @@ #define WINDOW_TEXT_TO_FRAME_PIXEL_X(W, X) \
extern Lisp_Object echo_area_window;
-/* Non-zero if we should redraw the mode lines on the next redisplay.
+/* Non-zero if we should redraw the mode line*s* on the next redisplay.
Usually set to a unique small integer so we can track the main causes of
- full redisplays in `redisplay--mode-lines-cause'. */
+ full redisplays in `redisplay--mode-lines-cause'.
+ Here "mode lines" includes also header-lines and frame names, and
+ apparently also menu-bars. The link with header-lines is clear,
+ but a bit less so for frame names and the menu-bar. */
extern int update_mode_lines;
@@ -1134,6 +1137,11 @@ #define WINDOW_TEXT_TO_FRAME_PIXEL_X(W, X) \
extern void wset_redisplay (struct window *w);
extern void fset_redisplay (struct frame *f);
extern void bset_redisplay (struct buffer *b);
+
+/* Routines to indicate that the mode-lines might need to be redisplayed.
+ Just as for `update_mode_lines`, this includes header-lines, frame names
+ and menu-bars, and the link with frame names and menu-bars is still
+ unclear. */
extern void bset_update_mode_line (struct buffer *b);
extern void wset_update_mode_line (struct window *w);
/* Call this to tell redisplay to look for other windows than selected-window
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 16:16:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 12:16:56 2023
Received: from localhost ([127.0.0.1]:45836 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKhx2-0004dP-EY
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:16:56 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54168)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKhwx-0004d9-55
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:16:55 -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 1qKhwq-0003Pm-56; Sat, 15 Jul 2023 12:16:44 -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=SAPm0ps647UI4HvrdeeKQx74ma3SdMiPWH2XXqE/AGg=; b=HLofgL+TwzOL
zdTTZcMXojUL/fGH1crPbYtYSdvORU50y/7vpsbnx+HCKBW7Wh1cRQGinmKMMzDPtANokAAGuZY88
hAoFO5Np7tdYeSWbcwPzmBI5aS+MNh1YJf0Cbai3vg+xLJT9pcLRjoxKNohLsmadFC334Nm7npydz
8A3p9kyWtsD/g6mJWwUxBfAiB/w9YdvZYBOrw987Q/cSm1tZGlaAyeJPEtfJU8gaGVSkwwnBHxV9d
Yk2RYo9jF+K+lpqOhbl7cHRVhS7PBzJmmDVGbhgO2HRHH6rWw6y38veWUUjxsN6Y9YxKs75PFOT17
g+MEmv+AXXvzJ8nBljrGHw==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKhwh-00018L-Bk; Sat, 15 Jul 2023 12:16:43 -0400
Date: Sat, 15 Jul 2023 19:16:57 +0300
Message-Id: <83jzv1b152.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> (message from Stefan
Monnier on Sat, 15 Jul 2023 12:01:50 -0400)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 12:01:50 -0400
>
> > But what happens in reality is that the breaking changes are made, and
> > then the "guilty parties" disappear into thin air, or lose interest.
> > And we are left with a broken redisplay and an unfinished project.
>
> I didn't disappear into thin air, did I?
Let's not make this too personal. Suffice it to say that I saw more
than once or twice changes in these areas which caused subtle
redisplay problems several years later, and I did have to fix a few of
them. So what I wrote is based on facts and actual experience.
> >> That's eactly what happened when I introduced the 3 `redisplay` bits
> >> above: it did introduce a few bugs, but overall it made the code
> >> more clear.
> > No, that's not "exactly" what happened. Some of the bugs popped up
> > much later, among other things. I agree that the added comments made
> > the situation better, but you know as well as I do that some of the
> > aspects of those variables are still somewhat mysterious: specifically
> > the meaning of windows_or_buffers_changed and update_mode_lines for
> > disabling optimizations and shortcuts. Which is exactly the focus of
> > the current discussion.
>
> Those aspects are not due to my changes. If they are mysterious it's
> because the remained mysterious, i.e. because I did not change them.
Indeed. The above wasn't written to accuse, but to convey the fact
that we are not yet where we want to be in this regard.
> This said, the meaning of those vars is clear, I think (they mean, that
> all the windows/modelines need to be updated).
Not entirely true, AFAIU. For example, what does update_mode_lines
have to do with preparing the menu bar?
static void
prepare_menu_bars (void)
{
bool all_windows = windows_or_buffers_changed || update_mode_lines;
bool some_windows = REDISPLAY_SOME_P ();
or a similar reference in update_menu_bar.
Or why redisplay_internal does this:
consider_all_windows_p = (update_mode_lines
|| windows_or_buffers_changed);
And a couple of more "questionable" uses of that variable.
> What still isn't clear at some places is the reason why they're set.
Yes, that too.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 16:02:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 12:02:04 2023
Received: from localhost ([127.0.0.1]:45831 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKhid-0004IU-SA
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:02:04 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8038)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKhiY-0004Hv-0G
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:02:01 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 183121000CA;
Sat, 15 Jul 2023 12:01:52 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 03531100098;
Sat, 15 Jul 2023 12:01:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689436911;
bh=bNOg1d1tkQaqHjqFWcOLdXDpl+ySuJVF8Vop1PNgBcs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=T4bCgZKSAfvPm5Owgbyra3Cvk5K01NizIkhKWQddL9GYR6NTct09+8ay7yKyM+LCX
VCDwNE+xw7JFE9O+XE1mFsmVo1juqXDbvNDmMkBQ9EnzXqRc7RiJ3imVLU6Q9IIPF0
s6mdFYhFV1Btz/jOX3+yCGjZ14jlgUlt3WGRE9DDGZr+WfnD/mXgwMFmrasD8fa0hd
VimXMYlDZTZVNSUFX/hclr3qlPBNBXuTtLlYd7uzPDOAFUm4RSWENkoVLc0bpnEbwH
k4zqnjT8QYSf9C8Y8yBEqoHb+qmKp2cGOM4sdO5tJZwbSjAzks9ylsc8L3P/BrRHZ4
zVp4Ral3CdxBw==
Received: from pastel (unknown [108.175.230.17])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CC2A312019A;
Sat, 15 Jul 2023 12:01:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83r0p9b3om.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
2023 18:22:01 +0300")
Message-ID: <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
<83r0p9b3om.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 12:01:50 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.131 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> But what happens in reality is that the breaking changes are made, and
> then the "guilty parties" disappear into thin air, or lose interest.
> And we are left with a broken redisplay and an unfinished project.
I didn't disappear into thin air, did I?
Maybe I shouldn't take this personally, but my `redisplay-bit` changes
are the only changes I'm aware of in this kind of vicinity, so I can't
help but feel that this experience is an important point of reference
for both of us.
>> That's eactly what happened when I introduced the 3 `redisplay` bits
>> above: it did introduce a few bugs, but overall it made the code
>> more clear.
> No, that's not "exactly" what happened. Some of the bugs popped up
> much later, among other things. I agree that the added comments made
> the situation better, but you know as well as I do that some of the
> aspects of those variables are still somewhat mysterious: specifically
> the meaning of windows_or_buffers_changed and update_mode_lines for
> disabling optimizations and shortcuts. Which is exactly the focus of
> the current discussion.
Those aspects are not due to my changes. If they are mysterious it's
because the remained mysterious, i.e. because I did not change them.
[ Actually, I did change them a bit to help track them down: I changed
those vars from booleans to integers where the integer is a "code" for
the place where it has been "mysteriously set". And you can check
`redisplay--all-windows-cause` and `redisplay--mode-lines-cause` to
see how many times each of those "mysterious causes" has been
used :-) ]
This said, the meaning of those vars is clear, I think (they mean, that
all the windows/modelines need to be updated).
What still isn't clear at some places is the reason why they're set.
>> > and guess who gets to work on fixing them.
>> AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
>> it should.
> Not all of them.
Admittedly, sometimes it's difficult to know beforehand whether the bug
may be due to those changes, so you may end up wasting your time before
you can redirect the bug to the appropriate person, but this is another
place where having that `internal--use-old-slow-redisplay` variable
would help.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 15:21:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 11:21:53 2023 Received: from localhost ([127.0.0.1]:45801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKh5k-00031j-Mt for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 11:21:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKh5i-00031R-93 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 11:21:51 -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 1qKh5c-0006cX-Qz; Sat, 15 Jul 2023 11:21:44 -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=QnwMd0qkxoJvoRkTqojipFtMP4L+QswPY5E96mA2aRk=; b=gaHV253vggVZ qMDS+MsG/Wncn7fbL1T+ngGh6vLgj69LkKr7dqjZY3qE6qj6UDw0+NycenkL62YXTbHvvXLmWqVqG 5SgKALlxyWl42l//lw3gB0QM5YO5CTKxzY1iHWMPI+SMqatFUXcSQg61nLysnsS6YNFnNymG/JmhD pK7stojQfTjp+zid1FG8vQqTF9EaL2wZgitTkSTOmQX+oiFKfAvsHLHCPVN29AgrapzPCK/pkS7U8 xAFv7vGCbf2/7OZzAyr8JG8WH+1lwaiWhEiUTJ9qle2a+O712gRt+lcUTP/8KTP/ema/kOoMK2MOu mZ8BZBo7Ppo+v0H8oJOUhw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKh5c-0003Fg-AY; Sat, 15 Jul 2023 11:21:44 -0400 Date: Sat, 15 Jul 2023 18:22:01 +0300 Message-Id: <83r0p9b3om.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 15 Jul 2023 10:49:37 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sat, 15 Jul 2023 10:49:37 -0400 > > > performance problem. Because otherwise making changes in code that we > > don't sufficiently understand can only cause bugs, > > It can introduce bugs, but in my experience when dealing with code > I don't understand, it's by breaking the code that you learn how it > works, so saying "can only cause bugs" doesn't make sense. It makes a lot of sense to me. So let's agree to disagree here. To reiterate my firm opinion: either someone steps forward to work on this seriously and systematically, or we should leave this code alone, for better and for worse. > The change can bring more clarity to the code, which is beneficial > in the long term, and if it introduces bugs then presumably some > users will see them, report them, and that will bring us better > understanding of the code. If someone wants to lead such a project for the next 10 years or so, maybe. But what happens in reality is that the breaking changes are made, and then the "guilty parties" disappear into thin air, or lose interest. And we are left with a broken redisplay and an unfinished project. > That's eactly what happened when I introduced the 3 `redisplay` bits > above: it did introduce a few bugs, but overall it made the code > more clear. No, that's not "exactly" what happened. Some of the bugs popped up much later, among other things. I agree that the added comments made the situation better, but you know as well as I do that some of the aspects of those variables are still somewhat mysterious: specifically the meaning of windows_or_buffers_changed and update_mode_lines for disabling optimizations and shortcuts. Which is exactly the focus of the current discussion. > > and guess who gets to work on fixing them. > > AFAIK, for the bugs introduced by those `redisplay` bit: I did, as > it should. Not all of them.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 14:49:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 10:49:47 2023
Received: from localhost ([127.0.0.1]:45744 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKgag-000882-Vu
for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 10:49:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21472)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKgae-00087p-Kn
for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 10:49:46 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 559BA80712;
Sat, 15 Jul 2023 10:49:39 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D0C84805DE;
Sat, 15 Jul 2023 10:49:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689432577;
bh=DQFTOhqrUTJIgUo9roA7Rz5Sw2Qi/pdTMI3IEm89Yfw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QzKzXa34F3HaXwjdB6pZEzhuHE51NbZhrnnokDqx50QFwv8k/qa7mlnHmo7UBft/g
XWCsWeh0iDlVBoR8UepvxQMM5O9ceyNN2mEnqiU7W+405wisifypVPb8S4TXKDSVI7
v98VFwh4vQJRYWgC4HK5d0kJ7rTG5uEv5OJc63jBjRS1kSTpsFPhfyNaeXTsMLkCTA
HsLBRYjTU8Ch/9J7vMikMQ2dW4t3qWwcJsma2kK/IVZVrTbgz4qJit9RBzcHOvAqmr
ja9qtS174hmorR7P2mXDwQ2I2rMlt24WQgFgdKkJnWnv/K/e/VNevNy/ggbU/R3K8T
Ht+QJ8QAaJf6Q==
Received: from pastel (unknown [108.175.230.17])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A20451203A1;
Sat, 15 Jul 2023 10:49:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83a5vxejz6.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
2023 10:01:49 +0300")
Message-ID: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
<87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
<83a5vxejz6.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 10:49:37 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.250 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> We currently have quite a few flags that are used by various Emacs
> commands to give redisplay hints about what should be done:
>
> . redisplay flag of a buffer
> . redisplay flag of a window
> . redisplay flag of a frame
> . update_mode_line flag of a window
> . update_mode_lines variable
> . windows_or_buffers_changed variable
I can explain what these are supposed to represent (IOW, if there's
a bug linked to them, I should be able to tell you whether the blame
goes to the redisplay code (which "reads" these vars) or in the
non-redisplay code (which sets these vars)).
If you read their docs and have questions, I'd love to hear them so
I can improve their doc.
> . clip_changed flag of a buffer
. beg_unchanged of a buffer_text
. end_unchanged of a buffer_text
I think their intended meaning is fairly clear. I haven't really
played with the corresponding part of the code, so I don't know if the
code really matches my expectations, but I have the impression that
there shouldn't be too many surprises.
> . cursor_type_changed flag of a frame
> . face_change flag of a frame
I can see what these are supposed to mean as well, but I'm less sure
that that intended meaning really matches the code (e.g., I wouldn't be
surprised to discover that one of them is also (ab)used for something
else).
> . prevent_redisplay_optimizations_p flag of a buffer
> . must_be_updated_p flag of a window
No idea what these mean.
The name `must_be_updated_p` makes it sound to me like it's redundant
with the `redisplay` flag above.
> (There are a few more, but these are the bulk.) The 3 redisplay flags
> at the beginning of this list did not exist before Emacs 24, they were
> added in the hope to make the flags more selective and
> self-explanatory.
They were added exclusively to refine:
. update_mode_lines variable
. windows_or_buffers_changed variable
since these have a global meaning whereas in most cases only a small
number of the windows should be affected.
[ IOW, the refinement targeted use cases where there are many windows.
I often have a hundred windows or more :-) ]
> performance problem. Because otherwise making changes in code that we
> don't sufficiently understand can only cause bugs,
It can introduce bugs, but in my experience when dealing with code
I don't understand, it's by breaking the code that you learn how it
works, so saying "can only cause bugs" doesn't make sense. The change
can bring more clarity to the code, which is beneficial in the long
term, and if it introduces bugs then presumably some users will see
them, report them, and that will bring us better understanding of
the code.
That's eactly what happened when I introduced the 3 `redisplay` bits
above: it did introduce a few bugs, but overall it made the code
more clear. My experience has been very positive there, and I hope you
wouldn't veto a similar change in the future.
> and guess who gets to work on fixing them.
AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
it should. And it wasn't terribly hard (largely because I indeed knew
(because I had decided it myself) what meant what and hence where
a problem should be fixed).
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 08:52:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 04:52:27 2023 Received: from localhost ([127.0.0.1]:44118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKb0s-0003JK-R0 for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 04:52:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKb0r-0003J8-9P for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 04:52:26 -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 1qKb0l-00063M-PZ; Sat, 15 Jul 2023 04:52:19 -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=ToaqyB4WbnjzQ7pDIC0oWbkTQu2mh6Zy30tPd61pw7g=; b=eiiEF7unh2Bq rprU7iV+Tzb3rBzQMZ5LqmTq78QaGZIcRSo4/PF9YYem9KTMk2zsKnj6GqpGlZi6nmQgvXYWDvxIN C427yeXCjj215h9HI3DUrpxcKhtrQ4RJ0wJ002Mv2S68QzytWdH5825sf11p1kgqXlcZWudYSz1cX PmVIQHCLvZmJHtKu9uojQCEV4QEUt5R6BYyyJf5PO6AaTk1cEyy5MIqi71zpxzEUousJP3YhTU/zD qou6Qn/ylqrzjymyftLdNgJgRRUunDZSBz1Hf2PRZJm9ixMvkmVKLcRfEMUX2h4qf768jbL+u2AA3 RoOim8FLtmGA3O/5/hWR/g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKb0l-0008Ik-7Q; Sat, 15 Jul 2023 04:52:19 -0400 Date: Sat, 15 Jul 2023 11:52:41 +0300 Message-Id: <83ilald09y.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87lefhhc4s.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jul 2023 07:22:59 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <87lefhhc4s.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Sat, 15 Jul 2023 07:22:59 +0000 > > >From my recent reading of the commentary in xdisp.c, one apparently > missing summary is which window and frame components are considered by > the redisplay code. Basically, all of them, I'd say. > "Glyph rows." section in the top comment talk about margins + text area, > but the real redisplay_internal appears to consider (1) title bars; (2) > menu bars; (3) header line; (4) tab line; (5) mode-line; (6) window > text; (7) echo area (which is treated specially). That section indeed mentions the text area and the margins, but only because the glyph rows distinguish between them. The other areas you mention either don't use our glyphs (title bar), or have no margin areas (mode line, header line, menu bar, etc.), only the text area. Echo area is displayed in a mini-window, which is just a window, albeit a special one. > > .... But I will not agree to > > random poking at this or that particular flag, unless there's > > convincing evidence that it causes a display bug or a significant > > performance problem. Because otherwise making changes in code that we > > don't sufficiently understand can only cause bugs, and guess who gets > > to work on fixing them. > > That's understandable. > But the general idea of having some kind of "experimental" flag might be > still useful in other situations. Not necessarily redisplay. > Of course, such experiments should be still weighed carefully. I'm okay with such experimental flags, and we did use them in the past (still have some of them in the current sources). I'm just saying those should be selective enough to allow enabling/disabling a small set of features, not all of them together.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 07:23:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 03:23:00 2023 Received: from localhost ([127.0.0.1]:43938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKZcK-0000fl-9D for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:23:00 -0400 Received: from mout01.posteo.de ([185.67.36.65]:35953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKZcI-0000fS-4a for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:22:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E9D07240027 for <64596 <at> debbugs.gnu.org>; Sat, 15 Jul 2023 09:22:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689405771; bh=IjXCJws5tPF33EQGK0qNA1vFF9/aFA/r+PI9s9GdU4U=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=gzSeQquoEwyDUov//sQ01fwAA7b+VqaX0VZ74e3Cu6+Ghljmoy7KAdU53Bfg3JpeH AqgxXuezjQh6e4k897WxqwOECsHLuRDTtt7pELgHOfQBXosLlGeHVKSZSaulJJIkFv JMbxXWhFVQ72nj4ex5Ne77Q+BsJHXHub1mtg+cq3oM0e6/y2H19+VEx3bBZDCbiMkI AGUdRMolFT8LagsNfz7C/azNctbqrtWuRIWJVSatL2gDesYBlWxF/I9SDOhiL7eDfy nEvxPCzXuHG9amJcYLTFaN20A2L2PjROE8BvAjuRcjg6z4I2fpGfcRuQIkQ8vuAkOI C+P4LIVkr1DFA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R30DV61Qsz9rxP; Sat, 15 Jul 2023 09:22:50 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83a5vxejz6.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> Date: Sat, 15 Jul 2023 07:22:59 +0000 Message-ID: <87lefhhc4s.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: > What we do need is to make some better order out of these flags, > understand better what does each one of them tell the display engine, > and perhaps make some of them more selective. And we need to document > these understandings. I agree. From my recent reading of the commentary in xdisp.c, one apparently missing summary is which window and frame components are considered by the redisplay code. "Glyph rows." section in the top comment talk about margins + text area, but the real redisplay_internal appears to consider (1) title bars; (2) menu bars; (3) header line; (4) tab line; (5) mode-line; (6) window text; (7) echo area (which is treated specially). > .... But I will not agree to > random poking at this or that particular flag, unless there's > convincing evidence that it causes a display bug or a significant > performance problem. Because otherwise making changes in code that we > don't sufficiently understand can only cause bugs, and guess who gets > to work on fixing them. That's understandable. But the general idea of having some kind of "experimental" flag might be still useful in other situations. Not necessarily redisplay. Of course, such experiments should be still weighed carefully. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 07:01:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jul 15 03:01:40 2023 Received: from localhost ([127.0.0.1]:43902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKZHf-00007H-KU for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:01:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKZHd-000070-T8 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:01:39 -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 1qKZHY-0005Ma-2r; Sat, 15 Jul 2023 03:01: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=kdqPjZ+1/DZZZkkuLkaNGu1HrKfHWEc5DdRL2kAIxKU=; b=MaoifD/BJrA1 OnKkzt3wo8/Skrwd2fogZOVyeHVmtnlGRBJv2wD5PAtHdeR2RPHkn5GRFecANdDf9OaNTAK/c2BTR n1Opj09ftvab95vk/qX51eYJAxfnjTbk/LHxxsPRxRTbgseQbr14kyuDtQ4kRQqrKoF9XzwQoC/Yo Q6QSXURHvEyjpTx3lw6fxMvN5UiJy/8jBIvDvKBr47Hc9c5vVFbSfjSkas9mM8Gc/nBFCp7wU7yoS DxkYokmauUn2TWSL1Zbm6JPZUbFpgcXHHy7kgvqKlB5wt8AOWldv2OKn70MefE5I8RJUJlHK2yt1g 1UaajZDdcLWeMUo+rjqTEQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKZHV-00031E-3q; Sat, 15 Jul 2023 03:01:31 -0400 Date: Sat, 15 Jul 2023 10:01:49 +0300 Message-Id: <83a5vxejz6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: yantar92@HIDDEN, monnier@HIDDEN In-Reply-To: <83sf9qe2ip.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 14 Jul 2023 22:06:38 +0300) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: 64596 <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 (---) > Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Fri, 14 Jul 2023 22:06:38 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Ihor Radchenko <yantar92@HIDDEN> > > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > > Date: Fri, 14 Jul 2023 17:46:09 +0000 > > > > Stefan Monnier <monnier@HIDDEN> writes: > > > > > What we need in order to investigate is a somewhat reproducible test > > > case and for that we need the bug to be exposed to as many users as > > > possible to increase the chance that one of them bumps into > > > a good recipe. > > > > > > The variable is not used to investigate, but to make it ethical to > > > expose users to those potential bugs because they can set the var to > > > recover the old behavior as soon as they're tired of playing the > > > guinea pig. > > > > +1. > > -1000 Let me explain once again my position on this. We currently have quite a few flags that are used by various Emacs commands to give redisplay hints about what should be done: . redisplay flag of a buffer . redisplay flag of a window . redisplay flag of a frame . prevent_redisplay_optimizations_p flag of a buffer . clip_changed flag of a buffer . update_mode_line flag of a window . must_be_updated_p flag of a window . cursor_type_changed flag of a frame . face_change flag of a frame . update_mode_lines variable . windows_or_buffers_changed variable (There are a few more, but these are the bulk.) The 3 redisplay flags at the beginning of this list did not exist before Emacs 24, they were added in the hope to make the flags more selective and self-explanatory. But just knowing, for example, that a buffer's text was changed says almost nothing about which optimizations can and cannot be used, whether or not the mode line needs to be updated, nor even if the window(s) showing the buffer need to be redrawn (since the change could be in a portion of the buffer that is not visible in any of the windows). Anyway, we now have this dozen of flags and variables, and one of them is prevent_redisplay_optimizations_p. It makes absolutely no sense to me to try to "solve" the "problem" of this single flag in the single case that started this thread. Even if this flag should not be set in the particular place with a FIXME -- which was not convincingly demonstrated here -- so what? what harm can that possibly make in this specific case? None. What we have now might look untidy at best, but it does work, and works well. It took an effort to get here, but the current situation has been stable for several years: I don't remember any significant redisplay problems reported for the last several years. What we do need is to make some better order out of these flags, understand better what does each one of them tell the display engine, and perhaps make some of them more selective. And we need to document these understandings. So this is the deal: if someone wants to try to do this job, or even some part of it, you will have my full support, my attention, and any form of help I can practically provide. But I will not agree to random poking at this or that particular flag, unless there's convincing evidence that it causes a display bug or a significant performance problem. Because otherwise making changes in code that we don't sufficiently understand can only cause bugs, and guess who gets to work on fixing them.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 19:06:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 15:06:25 2023 Received: from localhost ([127.0.0.1]:43523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKO7V-0002Ep-7b for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:06:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKO7T-0002Ed-GV for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:06:24 -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 1qKO7O-0003ap-9e; Fri, 14 Jul 2023 15:06:18 -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=Q2nRL3pB7XhtCnSnlmUXiIIDWWPdEJ0AY5jgz8ge2hw=; b=rE9FLPB1LVS6 vB4dCNniAuzBlsbRmrTwBt8Ngl9ZePXoHFwGDkdgGfesvg6FoxSdt5R6miG7gA3y9L2uux6YNG0L1 vSq5NOQMZDrEH10zm0Zy17WfO4k+vviSkeWTGBgqznw4C8YCWXqB1k/b2mNHg8VJRFFscH8tR3ayg CP6BeooB00pSmBKes68lotNXCjjp2YN+YlzHiUdcVkg4nQyBCS5xDKYAzikeqFh5iv9WQJuLlC4VN TWr7BV7Bm5o7WrVC+Zl3DLH24qOVZaKlYQRDlJ0SPMFzM6vYCEbb0TBuvRqkBGZAZ1I6lfIzKYnrX 6DAyicX96Sxw/M//lVtpVg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKO7N-00079Z-OP; Fri, 14 Jul 2023 15:06:18 -0400 Date: Fri, 14 Jul 2023 22:06:38 +0300 Message-Id: <83sf9qe2ip.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87a5vyidy6.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Jul 2023 17:46:09 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Fri, 14 Jul 2023 17:46:09 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > > What we need in order to investigate is a somewhat reproducible test > > case and for that we need the bug to be exposed to as many users as > > possible to increase the chance that one of them bumps into > > a good recipe. > > > > The variable is not used to investigate, but to make it ethical to > > expose users to those potential bugs because they can set the var to > > recover the old behavior as soon as they're tired of playing the > > guinea pig. > > +1. -1000
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 19:05:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 15:05:01 2023 Received: from localhost ([127.0.0.1]:43515 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKO68-0002CE-NW for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:05:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKO67-0002C2-3r for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:05:00 -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 1qKO61-00035k-4H; Fri, 14 Jul 2023 15:04:53 -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=8Zszn1UGc6S+eTIEknOfybrH6Dht3bes5ejmd3ZuMtI=; b=VWtbUFQQBBMn il8esAbNmRGmU3jb0uvfeY4FfJiR3YYxSP+U3eM1snyoFPzFesF3QV14lhOClzZU6BvLbErobohnm kzf7sT30/ysEPU2NByNv7vIf9G4CzPDmxhha1FjhNbqC/K/xMo5wGM1Fg4Np5+yHEi9Dqd7fMZbKL Liqdc11FablySMcW0m73iYH3xOz5LRkJ1zRB3tAesZEuLYgCyoCnNeoYlxnU68pUt49Asso1g++Nj 0/4pD+ZxzoMtbydN6kAUPbJIxIjqODlOjqWlupdMhJtuiWicl+TBzXsM/yo4Tc9ufmPgvU+g5U/Mw fEkZG9hIzGC8j41M1YER2w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKO60-0006tv-KP; Fri, 14 Jul 2023 15:04:52 -0400 Date: Fri, 14 Jul 2023 22:05:11 +0300 Message-Id: <83ttu6e2l4.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 14 Jul 2023 13:38:11 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Fri, 14 Jul 2023 13:38:11 -0400 > > > No, one variable is not enough -- it will never tell us which of the > > potential flags or settings of the flag requires to be reinstated. We > > need to be able to investigate this at a finer granularity. > > I doubt it. > > What we need in order to investigate is a somewhat reproducible test > case and for that we need the bug to be exposed to as many users as > possible to increase the chance that one of them bumps into > a good recipe. > > The variable is not used to investigate, but to make it ethical to > expose users to those potential bugs because they can set the var to > recover the old behavior as soon as they're tired of playing the > guinea pig. That's not what I had in mind when I proposed this approach. What I had in mind was to investigate the need for every one of the variables we use to disable redisplay optimizations in the various cases: the prevent_redisplay_optimizations_p flag, the update_mode_lines variable, the windows_or_buffers_changed variable, etc. -- in the places in xdisp.c where these are heeded. The purpose was to understand better which ones should be used where and why. This cannot be done with a single variable. So if you want a single variable for some "ethical" pseudo-investigation, I guess we deeply disagree here. I'm not interested in such "investigation".
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 17:46:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 13:46:13 2023 Received: from localhost ([127.0.0.1]:43428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKMrt-00005L-F1 for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:46:13 -0400 Received: from mout01.posteo.de ([185.67.36.65]:57263) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKMrr-000056-Ey for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:46:12 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5442C240027 for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 19:46:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689356765; bh=VCbTpzeGwhcVNJ9JMvaaNLsh4gkmfJPZbcAcYQQiJnc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=XRfMdGr2w8MqQ4Cop/juFA9AWuw02nKrNWfNFfVS+5VbEQWnBvSIPA6xR8eIF8fFW P4znTljfrpPm4K6VkrI5AWd5fE6zIQfPIbe3GKdfTt96DnLWDGptKlHywD0EmadFef Rr2UfJ+l5se3VQw+dQPpEls4Vs+tba0cThT5O2QHpo6M4+9e7eEsr9mqWJ1DE+UbpS XL/ZRLUy01sB4/XFZ//gpG3CBd1lHTVzMCxat7XC1NLudoRKz21rLk27v9dXH6r3rg CwdWgfpaZfQo8kzDp0bpDbslmTTghjq/TfY2tzvW2koWDxrVFNqzpQw6iERrahHzxQ mzJ8AyMPKj2tQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R2f645JTgz6tvh; Fri, 14 Jul 2023 19:46:04 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> Date: Fri, 14 Jul 2023 17:46:09 +0000 Message-ID: <87a5vyidy6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---) Stefan Monnier <monnier@HIDDEN> writes: > What we need in order to investigate is a somewhat reproducible test > case and for that we need the bug to be exposed to as many users as > possible to increase the chance that one of them bumps into > a good recipe. > > The variable is not used to investigate, but to make it ethical to > expose users to those potential bugs because they can set the var to > recover the old behavior as soon as they're tired of playing the > guinea pig. +1. Somewhat orthogonal, but related: if there are people who want to live dangerously (even more dangerously than on master), it might be interesting to have some kind of flip like "give me all the cutting edge experimental features enabled, even if not backward-compatible". -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 17:38:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 13:38:23 2023
Received: from localhost ([127.0.0.1]:43424 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKMkJ-0008Lg-HK
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:38:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23390)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKMkG-0008LR-6O
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:38:21 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 80D1E4409CA;
Fri, 14 Jul 2023 13:38:14 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EF34E44099C;
Fri, 14 Jul 2023 13:38:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689356293;
bh=riUq2GH3Uu3+Vf5xTCWI4Siwt65y78/lglZ1T7e79fE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=BrxtqDo71oQm95e/JxQs2VEE+oSLdycSIXyOGr4w6rllS/lV/zGkiwy5Lz7HwNbW9
T/UpWUfewxs7xDB1Oh2VeSwlvogESxhSvD7bmLVOy8T12Hb4D6SJWAfBnw+TxjWq4v
xR/IFitRZZjjf8FKidbF1SvMdH8BtxW8RsGdl22AM6gmxC2fuuOS8SalDQR4aJU5hW
m4ritejAWQYlbIDBEzp9mIjEOe/j4bwpAfI3HWpaNlBMBhMqn4w4XXX5veFfthvFVA
n4dKO8TBd6CvskdWjWEy45J9ixZ7xtFxwvvVAjNyPjfb/NljtB0nRNX5B8RvjOQ69Z
ltbuPhNeqUpnA==
Received: from pastel (unknown [104.247.239.133])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C30E1120397;
Fri, 14 Jul 2023 13:38:12 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <834jm6fppc.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
2023 19:00:31 +0300")
Message-ID: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
<834jm6fppc.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 13:38:11 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.032 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> No, one variable is not enough -- it will never tell us which of the
> potential flags or settings of the flag requires to be reinstated. We
> need to be able to investigate this at a finer granularity.
I doubt it.
What we need in order to investigate is a somewhat reproducible test
case and for that we need the bug to be exposed to as many users as
possible to increase the chance that one of them bumps into
a good recipe.
The variable is not used to investigate, but to make it ethical to
expose users to those potential bugs because they can set the var to
recover the old behavior as soon as they're tired of playing the
guinea pig.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 16:00:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 12:00:27 2023 Received: from localhost ([127.0.0.1]:43296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKLDW-0005aQ-Nu for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 12:00:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKLDT-0005aA-S3 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 12:00:25 -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 1qKLDO-0000XW-Ga; Fri, 14 Jul 2023 12:00:18 -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=YZ2LCmn7xu1N2+iuB5WH2JQ0tvVFiSExhqgtIzBiSG0=; b=O1GM2b5+2RYW DxgZ2Uw/PYV7Gre/G7eTbObueykUU3tBmdrYeVIVn29aXwXE7Ol5L7aow3yDHPYu1u8GBJ2VR5wBO CD99qN0elydXIwC7rN3IkQHZX/Odg4/dtoF5Xo00hFf5Zq0UByigDuHuhqRb8o/yGSCEANoECmyZE I/eyT1fTjbo/XNLeDhhYwEfWUFjowe2HkSe6hSgw1wjKMm/qmkvyAHq2zPMlKh5EjfvCCiT1zMtjq aurwnF4NjAiZeCahoqZbxQnh9sntoDpZGCnFE1RVlAseBFhTa0fSgzGAh1LJM/Mx+0zUS5QkkWzPV ZOQuqUIhZmI4+INtxkFqSA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKLDI-0004uS-Gu; Fri, 14 Jul 2023 12:00:18 -0400 Date: Fri, 14 Jul 2023 19:00:31 +0300 Message-Id: <834jm6fppc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 14 Jul 2023 10:31:23 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Fri, 14 Jul 2023 10:31:23 -0400 > > > It would be nice to analyze all those flags, make them more selective, > > and understand/document better what optimizations and optional > > processing are affected by each one of them. It is a large and > > somewhat ungrateful job, so if someone wants to do it by > > systematically examining the situations where we set each one of those > > flags and their effects on redisplay, I can offer my best help (though > > I cannot afford doing this job myself). > > I can't see it happening ever in such a systematic way. I still hope it will. It's a good way of getting familiar with the display code, so maybe someone will step forward. > A more pragmatic approach is the one you propose afterwards: based on > our vague understanding of how things work, make a few simplifications, > expose them to our users and then see what bug reports we get in return. > > I suspect a single boolean variable (which we could call > `internal--use-old-slow-redisplay`) to control those simplifications > would be enough. No, one variable is not enough -- it will never tell us which of the potential flags or settings of the flag requires to be reinstated. We need to be able to investigate this at a finer granularity. And the variables should be called something like use-old-and-correct-redisplay-for-mode-line.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 15:55:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 11:55:58 2023 Received: from localhost ([127.0.0.1]:43291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKL9B-0005SU-Vq for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 11:55:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKL9A-0005SH-9H for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 11:55:57 -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 1qKL93-0005VN-Dy; Fri, 14 Jul 2023 11:55:49 -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=BxcNCjnitzFicCyBWen11egZoW81M3KlUeLrIswUIyo=; b=I0w84sU7pBe8 WCdZlFnaULIiwYJz2KuqTPBJtpEtPEh3dMHoX9IrtZU8cLddhpLBs5S03gr/iJObng+tP+XcQOd3Z s5kc1LZmDMVu8XAK5pwXfTwwdUnloomYhzrn0cnqBt+fdKe4AmlS68RpxsF7EpsMOwQBDOM3IdTh2 1ZMKFJtLsBJG018sxh4MwPFd/LzK322UtGiGebJajygDT+ee0AyR7zdxmQ3zBvoGbvZtEf+CFg9zi q/zZXqqk1Xn+jk0c7sEu1FIccBQKZM6WVMegC/1f11gqQLsA7tGWwWla3734nn7kGoA17U9jypWP9 MAXsDOGEShjwv7kUeQu+gg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKL91-0007qx-G9; Fri, 14 Jul 2023 11:55:49 -0400 Date: Fri, 14 Jul 2023 18:56:06 +0300 Message-Id: <835y6mfpwp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 14 Jul 2023 10:20:32 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN> <87bkgeiuap.fsf@localhost> <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Fri, 14 Jul 2023 10:20:32 -0400 > > `prevent_redisplay_optimizations_p` is just another of those vars. > The problem with that var is not its existence but the fact that by now > noone knows what it means, so we can't touch that code, basically :-( I think we can touch that code, but we need to do it carefully, and we need to leave behind a "fire escape". If you look at its uses (not where the flag is set, but where it is checked), you will see that it either disables some optimization (example: in try_window_id), or sets other variables, like current_matrix_up_to_date_p. In the first case, we need to go over the places where the flag is set to true and think whether those setters indeed need to disable each particular optimization. In the second case, I think the flag is basically used to quickly disable optimizations conditioned by those other variables, in a way that prevents us to make more expensive tests. If we understand better each of these cases -- and there aren't so many of them -- we then could discuss whether to set the flag or not and whether to replace it with something else, whether those are other, more descriptive, flags or nothing.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:50:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 10:50:16 2023
Received: from localhost ([127.0.0.1]:43198 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKK7c-0003nU-Fg
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:50:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28254)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKK7b-0003nF-GS
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:50:15 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3DD831000C4;
Fri, 14 Jul 2023 10:50:10 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1AD69100098;
Fri, 14 Jul 2023 10:50:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689346209;
bh=VUeavhYYGGc/VTdR1IhLf6LaWzqUBXSxXm3GpuOWW3E=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=PKQAGeLOmfjyZB+33zrcS/6VVf2AKNsR1AyLaNWMjKj9bkCutTAVOdFdjao4kuL5L
nIP4X8a7onrZMIFeWgTS5LC7a9MrG11BMjK71aYmiUI6hiNjtinQbqckP5bHDmbMtY
ftfUjMi9h8etLZEsoC3eo9HA6P+XiJ+K1ut70PtS0ubiXKnXhIqYJ3A61aOb4P1XU0
60JDSA1JaAJve4itKVS+Dvu7DdT+tdDgykduX83BUF3YTyMHTiXJe6oBRnycGFzxyW
qVS/SHQK8VFaJEPRhOEkHXgds3oFMId2TT0taG9m9AQOg8IFGEL7lKGm237wAHYjOj
J9GMwTbShKjJw==
Received: from pastel (unknown [104.247.239.133])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E63CC12033B;
Fri, 14 Jul 2023 10:50:08 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83fs5qfznv.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
2023 15:25:24 +0300")
Message-ID: <jwv4jm6eeg8.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
<87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 10:50:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.109 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Ihor Radchenko <yantar92@HIDDEN>, 64596 <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 (---)
> Moreover, you will see in the wild that force-mode-line-update is used
> not just to update the mode line, but also to force a more thorough
> redisplay of one or more windows.
AFAIK these are bugs and we should not hide them by making
`force-mode-line-update` do more than what it's designed to do.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:31:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 10:31:33 2023
Received: from localhost ([127.0.0.1]:43175 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKJpU-0003GD-Ra
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:31:33 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64277)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKJpS-0003G0-Ah
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:31:31 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 184491000C4;
Fri, 14 Jul 2023 10:31:25 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DD1B2100098;
Fri, 14 Jul 2023 10:31:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689345083;
bh=4y3KhmiSlbKzzDuAqX5qdAmyV4NDGbWJS1N7/uVAK3E=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=W1rMauvJNTsqAYODLOS3kMgkMjSW6AWWbUxjbXZImc2v3uiFuwpvIlsPcOL4ZnYuj
BmjnVyYPVg2GgQmP+aZUjS/eI58b61N2b2WgIXWwZ7rWQUWn5VO54d76U1QRl0LHlp
ewb88cakIrvTBI7FsmrNaChYIc/kHowdh/ZDl6DKb2gPPSLDoX5B90jh5imrt5DuyT
ezTIW9pMk6hgF3J1hQia0rRdoyhNLRgN5XiV8RYJyw8i8QcxHIK35EIxuTkomrrhnq
3l5gVQ05a7N8n+DICkc95CEHHMYiI9/BCcr7IBpFmx9rCdr78xdE8LwmPTQk4yXTuF
LKyjr/YHMyEsQ==
Received: from pastel (unknown [104.247.239.133])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5CA3120264;
Fri, 14 Jul 2023 10:31:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83fs5r3tqv.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
2023 09:14:00 +0300")
Message-ID: <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
<83fs5r3tqv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 10:31:23 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.113 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
>> > Then I guess you or Ihor (or both) should try removing that line and
>> > run with that for a while.
>> FWIW, I've been running without those two lines ever since I put this FIXME.
> I'd be happier with the alternative I proposed, which you cite below.
I assume you assumed that my lack of problems would make me think
removing those two lines is safe :-)
I'm fully aware that when it comes to redisplay, one or two testers are
definitely far from sufficient, don't worry.
>> > Alternatively, maybe in the case of ALL non-nil the code should set
>> > the prevent_redisplay_optimizations_p flag of all the buffers that are
>> > displayed in some window, since some redisplay optimizations are not
>> > eligible when the mode-line is about to be updated.
>>
>> Any reason why the corresponding optimizations don't consult the
>> `update_mode_lines` var (or the `update_mode_line` buffer flag), or
>> maybe have redisplay start by propagating the `update_mode_line` buffer
>> flag to `prevent_redisplay_optimizations_p`?
>
> Once again, prevent_redisplay_optimizations_p is NOT (just) about
> updating mode lines, it affects more optimizations. There's also
I know. I didn't mean "consult `update_mode_lines` instead of
`prevent_redisplay_optimizations_p`" but "consult `update_mode_lines` in
addition to `prevent_redisplay_optimizations_p`".
> It would be nice to analyze all those flags, make them more selective,
> and understand/document better what optimizations and optional
> processing are affected by each one of them. It is a large and
> somewhat ungrateful job, so if someone wants to do it by
> systematically examining the situations where we set each one of those
> flags and their effects on redisplay, I can offer my best help (though
> I cannot afford doing this job myself).
I can't see it happening ever in such a systematic way.
A more pragmatic approach is the one you propose afterwards: based on
our vague understanding of how things work, make a few simplifications,
expose them to our users and then see what bug reports we get in return.
I suspect a single boolean variable (which we could call
`internal--use-old-slow-redisplay`) to control those simplifications
would be enough.
We could set it to nil on `master` and to t in the release branch.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:20:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 10:20:42 2023
Received: from localhost ([127.0.0.1]:43140 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKJez-0002xJ-Ui
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:42 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53340)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qKJey-0002x3-BY
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:40 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 197B0806BB;
Fri, 14 Jul 2023 10:20:35 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AE4478065C;
Fri, 14 Jul 2023 10:20:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689344433;
bh=g85h7DrYkFfZ4uXJWH3HQKmAp6VIcSbHe6uSrzTsZBg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=LlxwI+f+e4xJpAPFwQVN7wjRbiqSin3YJ+GRmr3lXVasjkfkc6M6nw+wGmcGqCDfL
XaW5KCcl7zi9V5eJfBNlbRWALD//dqd1xguiU6WHVnXhJuYkMeB8e7022rS3G/75Zc
y6VPnVpODJ420Mquo6cLMhjbyWTGbiYUZmF+t+hlmqgd4QB2YC09s9xw3IXCQl6TAA
88nljwSxbSNjnYgFJRzfY0/QxVuyJ1Of9n4zorYID6LFcM0mxq5EsbPDDCTwS0QeIs
cMnkUppWXYddRW4TiohljCcUGkke9DS14o3Vy1K24T1+bnyuSrkDyID/B9mg3yCztf
/8JudFu+BLonQ==
Received: from pastel (unknown [104.247.239.133])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 84DF9120330;
Fri, 14 Jul 2023 10:20:33 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <87bkgeiuap.fsf@localhost> (Ihor Radchenko's message of "Fri, 14
Jul 2023 11:53:02 +0000")
Message-ID: <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
<87bkgeiuap.fsf@localhost>
Date: Fri, 14 Jul 2023 10:20:32 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <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 (---)
> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.
It's not that simple: the reliable way to do redisplay is to recompute
the whole glyph matrix anew for all windows every time any change occurs.
But that's unrealistic Instead, we decouple the redisplay from the
buffer modifications. In addition we try to keep track of which parts
may need to be redisplayed. For that we use various auxiliary variables
which the code performing modifications can set to tell the redisplay
about which parts may need to be redisplayed.
Such variables include the `redisplay` and the `update_mode_line` bits,
buffer vars that keep track of a buffer-interval outside of which
there has not been any buffer changes, ...
`prevent_redisplay_optimizations_p` is just another of those vars.
The problem with that var is not its existence but the fact that by now
noone knows what it means, so we can't touch that code, basically :-(
> So, I see not why calling bset_update_mode_line is not sufficient to
> force mode line update in all windows associated with a single buffer.
I suspect the `prevent_redisplay_optimizations_p` is/was not meant to make
sure the modeline is updated, but to make sure some other part of the
window is/was also updated, but the code that decides whether to redraw
that other part never looked at `update_mode_line`.
E.g. maybe some code caused the mode-line or header-line to
appear/disappear and thus called `force-mode-line-update` for that
purpose, but the redisplay failed to notice that it needed to redraw
parts of the buffer text in response o that change, so the "quick fix"
was to set `prevent_redisplay_optimizations_p`?
[ This is a completely hypothetical scenario, I have no idea how this
code came about. ]
> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p?
I don't know if it's still needed, or (if it is) whether it's the best
way to get the result nowadays, but I know why it's done: it's simply
because Fforce_mode_line_update used not to exist and instead the
standard way to force a mode-line update was to call
`set-buffer-modified-p` (yeah, I know it's weird, but that was simply
the cheapest operation exposed to ELisp that happened to set the needed
flags for the redisplay). `force-mode-line-update` was introduced as
a cleaner API (but still implemented by calling
`set-buffer-modified-p`), so when I "straightened things out" by making
`force-mode-line-update` set the redisplay flags directly, I made
`set-buffer-modified-p` call `Fforce_mode_line_update` to be sure that
any old code out there calling `set-buffer-modified-p` to force a mode
line update would keep working as well as before.
> Wouldn't calling bset_redisplay be better?
Maybe (depends whether the redisplay code on its own checks stores the
old modified-p value to detect when it has changed), tho I doubt it
matters very much.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:20:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 10:20:31 2023
Received: from localhost ([127.0.0.1]:43136 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKJep-0002wq-A0
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:31 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41400)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKJem-0002wU-Fb
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:29 -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 1qKJec-0003uV-Rb; Fri, 14 Jul 2023 10:20:20 -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=uKZp7mLtK9v/yC6q7BDLfNgrdR6wOAQkpDbEOKgOMec=; b=pPePg8hxrND0
m3O5kUdyFP3qpgNWZLSE/pxqRwjR5A4TevevawcIbEuy8JAFtW0TdTDPzd9dCcEPMWAOU4dHOj6lA
UPyirjRxWsjSkQPzZTu/ZHezVsQWP0bJ6WJpIwojEgBRuJeQTU56Fkon+J7vzvk4UUMvYYYPwNgnE
zm8rbWDvNPEbAjDt7WGdt8Z3YJrZPm9jKk6Rr8MLhOl8ZRNehrMMmvF8QJiL8vG6kbjzWz2loluX8
KWeiNESjMDJsO+jHhB7qCyiNt6Kz5XCejjFRRc8/XS4mbJllq24k2P52dwdW/wY2Ngq9RNqueflyK
xYXgeJ6LTxtwgBBbuT+SUg==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKJeX-0001bG-BI; Fri, 14 Jul 2023 10:20:18 -0400
Date: Fri, 14 Jul 2023 17:20:30 +0300
Message-Id: <838rbifuc1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <87351qioxw.fsf@localhost> (message from Ihor Radchenko on Fri,
14 Jul 2023 13:48:43 +0000)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
<87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN> <87351qioxw.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: monnier@HIDDEN, 64596 <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 (---)
> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 13:48:43 +0000
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> >> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> >> flag is a mistake hiding bugs with redisplay optimizations logic.
> >
> > I think you should avoid making such comments until you have a better
> > understanding of the redisplay logic, or else I will stop taking your
> > posts in this matter seriously.
>
> Your answer indicates that I missed something important after reading
> the top comment in xdisp.c, redisplay_internal, redisplay_window, and
> skimmed through a couple of other functions. But I still cannot figure
> out what.
Keep studying the code, is all I can suggest. There's much more there
than meets the eye, IME.
> Note that I did not mean that previous committers had bad intentions. I
> just think that the idea of having "disable all optimizations" flag is
> causing the code quality that could be otherwise somewhat better (at
> least, more explicit about why redisplay should take long path).
I agree that the underlying logic is somewhat subtle, and sometimes
even mysterious, and I suggested a way to make this logic more
explicit and better documented. But removing parts of display code
because we don't always understand it is a bad idea, IME, and usually
leads to bugs. So it is a non-starter, as far as I'm concerned.
> I think that replacing all the instances of setting this flag to more
> explicit alternatives would improve the display performance and also
> readability.
It's possible. But to consider such suggestions, I'd need to see a
detailed proposal backed up by serious analysis. In any case, whether
it will make performance better is not yet clear; the original
motivation for this was not a performance issue at all.
> > /* Optimize the case that only the line containing the cursor in the
> > selected window has changed.
> >
> > The prevent_redisplay_optimizations_p flag says, among other things,
> > that we are not in that case, and it is tested early enough in order
> > to prevent us from examining additional conditions which are just
> > waste of CPU cycles (and some of them are relatively expensive).
>
> Sure, but it is a very generic way to say this. It provides no detailed
> reason what exactly changed in the buffer/window/frame that makes us
> bypass this optimization.
What detailed reasons would you like to see?
> Is it not always possible to use the other, more specific, existing
> flags for redisplay to indicate that something important has been changed?
Which other flags? And why do you think they are more specific? At
least some of them are actually _less_ specific.
> >> So, I see not why calling bset_update_mode_line is not sufficient to
> >> force mode line update in all windows associated with a single buffer.
> >
> > The mode line displays quite a lot of information. It could also
> > display information we don't know about (on the level of the redisplay
> > code), because mode-line-format supports :eval, which can execute any
> > Lisp. Therefore, there could be changes to the buffer that affect the
> > mode line indirectly.
>
> But isn't :eval processed by display_mode_lines? Once we take care to call
> bset_update_mode_line, display_mode_lines is guaranteed to be executed,
> AFAIU.
Executed, but with what data? redisplay_window is a large function,
and employs quite a few of shortcuts. If one of those shortcuts is
taken when it shouldn't be, the data shown on the mode line might be
inaccurate, because some of the variables affecting it were not
updated.
But let me turn the table and ask you: suppose that the
prevent_redisplay_optimizations_p flag is not needed for updating the
mode line per se -- what damage could it possibly do to redisplaying
the mode line? why are you so eager to remove that setting from
force-mode-line-update?
> > One problem of this kind which we had relatively recently is when the
> > changes in mode-line-format or some of its :eval forms yields a mode
> > line that is significantly taller or smaller than the previously
> > displayed one. Such changes in the mode-line height generally affect
> > the window(s) as well, not just the mode line itself.
>
> Sure, and redisplay_window accounts for this when calling display_mode_lines:
>
> display_mode_lines (w);
> unbind_to (count1, Qnil);
>
> /* If mode line height has changed, arrange for a thorough
> immediate redisplay using the correct mode line height. */
> if (window_wants_mode_line (w)
> && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
> {
> f->fonts_changed = true;
> w->mode_line_height = -1;
> MATRIX_MODE_LINE_ROW (w->current_matrix)->height
> = DESIRED_MODE_LINE_HEIGHT (w);
> }
And if you've read the relevant bug reports, this doesn't always work.
But this is just an example, so even if you consider it to be solved,
it tells us that there can be other issues like that. We are trying,
slowly, to go from general flags to more specific ones, but we are not
there yet, and removing code in this situation will just produce more
buggy redisplay. I cannot agree to that.
> > Moreover, you will see in the wild that force-mode-line-update is used
> > not just to update the mode line, but also to force a more thorough
> > redisplay of one or more windows.
>
> Why not `force-window-update'?
Why does it matter? they both do almost the same (when the argument to
force-window-update is a window).
> And I now looked deeper into the code, and see no obvious downsides of
> removing current_buffer->prevent_redisplay_optimizations_p = true; from
> force-mode-line-update specifically.
> `set-buffer-modified-p' may need to be re-considered though as it is the
> original place where setting prevent_redisplay_optimizations_p was done
> (for different reasons).
Again, removing this is a non-starter, except if you want to do it
locally. If we want to make any progress in this area in general, we
should take one of the two approaches I described in my previous
message. Anything else is simply irresponsible, and won't happen on
my watch, sorry.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 13:48:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 09:48:47 2023
Received: from localhost ([127.0.0.1]:41739 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKJA6-0001Ru-Dh
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 09:48:46 -0400
Received: from mout01.posteo.de ([185.67.36.65]:34397)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qKJA3-0001RZ-Sb
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 09:48:45 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 9BBAD240028
for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 15:48:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1689342517; bh=/QXU+HukibJSAEYIWAQxNhcC6nF2Fz8F2IgMzE318t8=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
b=LbtfwjtjG9eItxgXTY1YycBi+V4OLXKpwv9dp0aFtDoHtA/k/rnG7jLula5Uxe5sU
EJd9ZS78bD1SUxZM0OzF1iDht+x8XDoT2lI/ny/QwMysSFP2pcexsEGha475rx9NFh
J82y6amIJkXkzwSpZhIvfXEDmGlPL8FkhQWgRxc3b2lvrbQtTAS9ULUgy7RGGJY9dt
aeie8CIfm1dP2SP9YJize5yAT1R5ACKYKb05JAZEzG0EBcAAVai3/Dqu7tkcUIZ7jC
c2qpWx5iLG8jeSje11hrgDMyj1POqdiY4VSqSLwz2pg0HkmAew0tu2tnKIwpe/ZjZ6
5JfbI7nLmIwqg==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4R2Xr43H5Cz6twZ;
Fri, 14 Jul 2023 15:48:36 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83fs5qfznv.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
<87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 13:48:43 +0000
Message-ID: <87351qioxw.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: monnier@HIDDEN, 64596 <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 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> I'm afraid that the very existence of prevent_redisplay_optimizations_p
>> flag is a mistake hiding bugs with redisplay optimizations logic.
>
> I think you should avoid making such comments until you have a better
> understanding of the redisplay logic, or else I will stop taking your
> posts in this matter seriously.
Your answer indicates that I missed something important after reading
the top comment in xdisp.c, redisplay_internal, redisplay_window, and
skimmed through a couple of other functions. But I still cannot figure
out what.
Note that I did not mean that previous committers had bad intentions. I
just think that the idea of having "disable all optimizations" flag is
causing the code quality that could be otherwise somewhat better (at
least, more explicit about why redisplay should take long path).
I think that replacing all the instances of setting this flag to more
explicit alternatives would improve the display performance and also
readability.
>> Currently, redisplay_internal has a number of conditions used to
>> determine if one or another optimization is safe to use + assertion that
>> !prevent_redisplay_optimizations_p.
>>
>> When some code outside xdisp.c sets this flag, it is nothing but a
>> statement: "I was lazy enough to update xdisp.c properly, so I just
>> force bypassing optimizations".
>
> No. The optimization in question, which is disabled when
> prevent_redisplay_optimizations_p flag is set for the current buffer,
> is described in the comment before the condition:
>
> /* Optimize the case that only the line containing the cursor in the
> selected window has changed.
>
> The prevent_redisplay_optimizations_p flag says, among other things,
> that we are not in that case, and it is tested early enough in order
> to prevent us from examining additional conditions which are just
> waste of CPU cycles (and some of them are relatively expensive).
Sure, but it is a very generic way to say this. It provides no detailed
reason what exactly changed in the buffer/window/frame that makes us
bypass this optimization.
Is it not always possible to use the other, more specific, existing
flags for redisplay to indicate that something important has been changed?
>> So, I see not why calling bset_update_mode_line is not sufficient to
>> force mode line update in all windows associated with a single buffer.
>
> The mode line displays quite a lot of information. It could also
> display information we don't know about (on the level of the redisplay
> code), because mode-line-format supports :eval, which can execute any
> Lisp. Therefore, there could be changes to the buffer that affect the
> mode line indirectly.
But isn't :eval processed by display_mode_lines? Once we take care to call
bset_update_mode_line, display_mode_lines is guaranteed to be executed,
AFAIU.
> One problem of this kind which we had relatively recently is when the
> changes in mode-line-format or some of its :eval forms yields a mode
> line that is significantly taller or smaller than the previously
> displayed one. Such changes in the mode-line height generally affect
> the window(s) as well, not just the mode line itself.
Sure, and redisplay_window accounts for this when calling display_mode_lines:
display_mode_lines (w);
unbind_to (count1, Qnil);
/* If mode line height has changed, arrange for a thorough
immediate redisplay using the correct mode line height. */
if (window_wants_mode_line (w)
&& CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
{
f->fonts_changed = true;
w->mode_line_height = -1;
MATRIX_MODE_LINE_ROW (w->current_matrix)->height
= DESIRED_MODE_LINE_HEIGHT (w);
}
> Moreover, you will see in the wild that force-mode-line-update is used
> not just to update the mode line, but also to force a more thorough
> redisplay of one or more windows.
Why not `force-window-update'?
> Thus, this is not as simple a problem as you seem to think, and we
> need deeper analysis and more significant changes than simply deleting
> the code that you didn't understand and think is redundant. Please
> keep in mind that people who wrote that code (and I don't mean myself)
> were not stupid at all, and generally knew what they were doing!
I understand, which is why I looked into git history and found that the
code in question is carried over during refactoring. Into a new function
with different meaning.
And I now looked deeper into the code, and see no obvious downsides of
removing current_buffer->prevent_redisplay_optimizations_p = true; from
force-mode-line-update specifically.
`set-buffer-modified-p' may need to be re-considered though as it is the
original place where setting prevent_redisplay_optimizations_p was done
(for different reasons).
>> > The purpose of force-mode-line-update is to do what its name says,
>> ...
>> Then, why do we need to call Fforce_mode_line_update in
>> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?
>
> You have read the large comment there which attempts to answer this
> question, didn't you?
Yup, I did. I thought bset_redisplay as an alternative, because it is
smarter than bset_update_mode_line when the buffer is displayed in
selected window (it is not necessary to assign DISPLAY_SOME flags).
However, I did miss the docstring that explicitly says that
`set-buffer-modified-p' forces mode line update. So, forcing mode line
update here is simply following the docstring and should not be
disputed.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 12:25:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 08:25:28 2023
Received: from localhost ([127.0.0.1]:41623 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qKHrT-0006gT-FR
for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 08:25:28 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36854)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qKHrQ-0006g4-Uz
for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 08:25:26 -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 1qKHrJ-0005WW-EJ; Fri, 14 Jul 2023 08:25:19 -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=1MTcArGREzyBWFvkpegibOp7BSqNDL3JQ7boWS4BPFk=; b=sOOxCf8CfY/jmBBIx4Lb
ktTaLGn9fh11ELQVGZEVw3ogvDBD8epkRvL4PDpMRELMhTEFPrrt7Muc/qt7mkgMPx9PFCTj88eC2
0cf4UiihYM5P5qLDKRYYykncYfqAAiTogseI9qUosDU3tneh9xfMxS7FbkNBmC2CTy9414bXPn7wR
5/vh37eSZHuCVII1UKqrApgwTqUEmuhp8G71oas52/OylcOCnM/gkIsiwMeIlNnVgi899Pzu4YUUG
Qb2v+7i5mpqFLLGRZnrw2ljoK9mdrkWxhxggveTJlJ0paosTHLiAFGtjHwBRuwteTHP2sq6d5LroR
wKTv1fbRWNkTKA==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qKHr7-0002d8-RY; Fri, 14 Jul 2023 08:25:13 -0400
Date: Fri, 14 Jul 2023 15:25:24 +0300
Message-Id: <83fs5qfznv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <87bkgeiuap.fsf@localhost> (message from Ihor Radchenko on Fri,
14 Jul 2023 11:53:02 +0000)
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
<87bkgeiuap.fsf@localhost>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: monnier@HIDDEN, 64596 <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 (---)
> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 11:53:02 +0000
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> > No, it's more subtle. In a nutshell, it is meant to prevent redisplay
> > from applying certain optimizations (search xdisp.c for the uses of
> > this flag). These optimizations are based on various assumptions,
> > such as that the current glyph matrix of the window is up-to-date.
> > Setting the prevent_redisplay_optimizations_p flag tells the display
> > engine that those assumptions are (or might be) false.
>
> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.
I think you should avoid making such comments until you have a better
understanding of the redisplay logic, or else I will stop taking your
posts in this matter seriously.
> Currently, redisplay_internal has a number of conditions used to
> determine if one or another optimization is safe to use + assertion that
> !prevent_redisplay_optimizations_p.
>
> When some code outside xdisp.c sets this flag, it is nothing but a
> statement: "I was lazy enough to update xdisp.c properly, so I just
> force bypassing optimizations".
No. The optimization in question, which is disabled when
prevent_redisplay_optimizations_p flag is set for the current buffer,
is described in the comment before the condition:
/* Optimize the case that only the line containing the cursor in the
selected window has changed.
The prevent_redisplay_optimizations_p flag says, among other things,
that we are not in that case, and it is tested early enough in order
to prevent us from examining additional conditions which are just
waste of CPU cycles (and some of them are relatively expensive).
> > Updating the mode line usually requires more thorough redisplay,
> > especially when the only reason for that is that some Lisp called
> > force-mode-line-update -- without setting that flag, the display
> > engine could easily decide that the window doesn't need to be redrawn.
>
> I have explored xdisp a bit and AFAIU, once we are in redisplay_window,
> mode line will be updated as long as update_mode_line is set (at least
> to UPDATE_SOME), except when current window is MINI_WINDOW_P (this code
> branch is not prevented by prevent_redisplay_optimizations_p though) or
> when we give up redisplaying.
>
> Calling redisplay_window may be prevented via needs_no_redisplay, unless
> we have buffer->text->redisplay, which is set in bset_update_mode_line.
> [ setting buffer->text->redisplay is rather awkward way to single mode
> line update though ]
>
> redisplay_window may also be postponed for frames that are not visible
> or that are obscured, but it appears to be by design and not influenced
> by prevent_redisplay_optimizations_p anyway 😕
>
> So, I see not why calling bset_update_mode_line is not sufficient to
> force mode line update in all windows associated with a single buffer.
The mode line displays quite a lot of information. It could also
display information we don't know about (on the level of the redisplay
code), because mode-line-format supports :eval, which can execute any
Lisp. Therefore, there could be changes to the buffer that affect the
mode line indirectly.
One problem of this kind which we had relatively recently is when the
changes in mode-line-format or some of its :eval forms yields a mode
line that is significantly taller or smaller than the previously
displayed one. Such changes in the mode-line height generally affect
the window(s) as well, not just the mode line itself.
Moreover, you will see in the wild that force-mode-line-update is used
not just to update the mode line, but also to force a more thorough
redisplay of one or more windows.
Thus, this is not as simple a problem as you seem to think, and we
need deeper analysis and more significant changes than simply deleting
the code that you didn't understand and think is redundant. Please
keep in mind that people who wrote that code (and I don't mean myself)
were not stupid at all, and generally knew what they were doing!
> >> If my understanding is correct,
> >> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> >> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
> >
> > The purpose of force-mode-line-update is to do what its name says,
> > regardless of whether the buffer was modified or not, and how it was
> > modified. The idea is that Lisp programs which change something that
> > they know must affect the mode line call this function to make sure
> > the mode line is redrawn with up-to-date information. By contrast,
> > buffer modifications could be such that don't affect redisplay at all,
> > or allow redisplay to use some shortcuts and redraw only a very small
> > portion of the window.
>
> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?
You have read the large comment there which attempts to answer this
question, didn't you?
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 11:53:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 07:53:06 2023 Received: from localhost ([127.0.0.1]:41557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKHM9-0005ee-PK for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 07:53:06 -0400 Received: from mout01.posteo.de ([185.67.36.65]:60659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qKHM6-0005e8-CL for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 07:53:04 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5F715240027 for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 13:52:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689335576; bh=fuDynePCm5w31s51KG9yzpJqO01WXcZnoJG2SAt3Bno=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=ImuoX09h/XGccc2YqVzqg9XP31Iv8CrZ0SuqjnxyGLQR92ZDyefBrZmyIprULhw9l j2zcpmA3lFfC/nzNCPvt+Wb2D7MmI/lvXykfgRd+zOXbKYjCfCXBs6fdjhhyzmRDN+ lCxlBDAuYm6HngA4kZNW1MrW9kmZ8ZeGbFzxPpMsAjTB4tmazev6Ng99c7jcAYt5mk ltzOEKu6YvmPGXMb0BAgWYBh5tCN4ml6VqZxG8oczOVqcBG/7ryT+u8RvTqBey3zJo 7Jej4T6JQUqiB2l3jVjZae2DT0noSPTJFW/HyLyFXHCJvY89kakaR8IiS1V5pFxsj5 H5K9mV9kxLnYA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R2VGb1G1pz9rxT; Fri, 14 Jul 2023 13:52:54 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83v8eo3pfv.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN> Date: Fri, 14 Jul 2023 11:53:02 +0000 Message-ID: <87bkgeiuap.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> AFAIU, the purpose of disabling redisplay optimizations is avoiding the >> situation when the modification flag is unset in the buffer, but the >> buffer was actually modified, and has to be redrawn. > > No, it's more subtle. In a nutshell, it is meant to prevent redisplay > from applying certain optimizations (search xdisp.c for the uses of > this flag). These optimizations are based on various assumptions, > such as that the current glyph matrix of the window is up-to-date. > Setting the prevent_redisplay_optimizations_p flag tells the display > engine that those assumptions are (or might be) false. I'm afraid that the very existence of prevent_redisplay_optimizations_p flag is a mistake hiding bugs with redisplay optimizations logic. Currently, redisplay_internal has a number of conditions used to determine if one or another optimization is safe to use + assertion that !prevent_redisplay_optimizations_p. When some code outside xdisp.c sets this flag, it is nothing but a statement: "I was lazy enough to update xdisp.c properly, so I just force bypassing optimizations". > Updating the mode line usually requires more thorough redisplay, > especially when the only reason for that is that some Lisp called > force-mode-line-update -- without setting that flag, the display > engine could easily decide that the window doesn't need to be redrawn. I have explored xdisp a bit and AFAIU, once we are in redisplay_window, mode line will be updated as long as update_mode_line is set (at least to UPDATE_SOME), except when current window is MINI_WINDOW_P (this code branch is not prevented by prevent_redisplay_optimizations_p though) or when we give up redisplaying. Calling redisplay_window may be prevented via needs_no_redisplay, unless we have buffer->text->redisplay, which is set in bset_update_mode_line. [ setting buffer->text->redisplay is rather awkward way to single mode line update though ] redisplay_window may also be postponed for frames that are not visible or that are obscured, but it appears to be by design and not influenced by prevent_redisplay_optimizations_p anyway =F0=9F=98=95 So, I see not why calling bset_update_mode_line is not sufficient to force mode line update in all windows associated with a single buffer. >> If my understanding is correct, >> current_buffer->prevent_redisplay_optimizations_p =3D true does not belo= ng >> to `force-mode-line-update', but rather to `restore-buffer-modified-p'. > > The purpose of force-mode-line-update is to do what its name says, > regardless of whether the buffer was modified or not, and how it was > modified. The idea is that Lisp programs which change something that > they know must affect the mode line call this function to make sure > the mode line is redrawn with up-to-date information. By contrast, > buffer modifications could be such that don't affect redisplay at all, > or allow redisplay to use some shortcuts and redraw only a very small > portion of the window. Then, why do we need to call Fforce_mode_line_update in set-buffer-modified-p? Wouldn't calling bset_redisplay be better? --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 06:13:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jul 14 02:13:55 2023 Received: from localhost ([127.0.0.1]:41363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qKC3v-0001xq-Ag for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 02:13:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qKC3r-0001xZ-8w for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 02:13:53 -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 1qKC3j-0006WN-Vq; Fri, 14 Jul 2023 02:13:44 -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=c+oMUdm9A91ExEbeDMpOD4WKOzDUDbS/sK/EhsuQYy8=; b=OcJ9Qp8uW1TJ xFv7CQpaIXl6C5CjiJ/3rYov+a+yvL8xZbhlUxsaOZDth+SKEhF12VINUy0vbuZP4oNzRmcVtQeP+ WVEg/TiC/sDpkv/WQTCd5dfsJWdAk0AcElEmN0JvGODqc00alBMSbw4QpwiQzXdHNl5liTaLx4dH7 c4L5llmO0g7bC8jzAPZW9gwJxufXM+qI19kSv2pAf/ZEeSuoBQ6CkF5xgYwraf3PQOxZ5dQTsjWR5 nvdXghLOkGu58Py9pjIoAV6QXDs4GoOEBVb/w8FZn9CRJz814mjiTZzFU3gUelaPK1ZA986BdEyOo VsqbHWvkZ0f7z4CBAp5N7w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qKC3h-00071A-Ff; Fri, 14 Jul 2023 02:13:41 -0400 Date: Fri, 14 Jul 2023 09:14:00 +0300 Message-Id: <83fs5r3tqv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Thu, 13 Jul 2023 18:02:26 -0400) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org > Date: Thu, 13 Jul 2023 18:02:26 -0400 > > > Then I guess you or Ihor (or both) should try removing that line and > > run with that for a while. > > FWIW, I've been running without those two lines ever since I put this FIXME. I'd be happier with the alternative I proposed, which you cite below. Because bitter experience taught me that your, Stefan, usage patterns evidently exclude some use cases, because bug reports pop up after your similar changes where the display is not updated in some cases. I'm sure the same is true for the usage patterns of anyone of us, so doing this on a small number of systems is not enough. > > Alternatively, maybe in the case of ALL non-nil the code should set > > the prevent_redisplay_optimizations_p flag of all the buffers that are > > displayed in some window, since some redisplay optimizations are not > > eligible when the mode-line is about to be updated. > > Any reason why the corresponding optimizations don't consult the > `update_mode_lines` var (or the `update_mode_line` buffer flag), or > maybe have redisplay start by propagating the `update_mode_line` buffer > flag to `prevent_redisplay_optimizations_p`? Once again, prevent_redisplay_optimizations_p is NOT (just) about updating mode lines, it affects more optimizations. There's also windows_or_buffers_changed, which is even "stronger". For example, try_window_id checks the prevent_redisplay_optimizations_p flag and punts if it is set, although that optimization method AFAIK has nothing to do with redisplaying mode lines, it is only about updating the text area. It would be nice to analyze all those flags, make them more selective, and understand/document better what optimizations and optional processing are affected by each one of them. It is a large and somewhat ungrateful job, so if someone wants to do it by systematically examining the situations where we set each one of those flags and their effects on redisplay, I can offer my best help (though I cannot afford doing this job myself). Failing that, we could try disabling some portions of the code. This is not the best method of collecting such systematic information, IME, certainly not if just a couple of people do that, because experience teaches us that usage patterns differ wildly, and different window-systems and different window managers sometimes have significant effect on this stuff. So if we want to use this "phenomenological" approach, my suggestion is to allow disabling the relevant parts of the display-related code at run time, controlled by variables exposed to Lisp. We already have a bunch of inhibit-* variables that inhibit specific optimizations in xdisp.c; we could add more. Then we could set the defaults of these variables according to our best understanding, and if and when redisplay problems are reported, ask people to flip one or more of these inhibit-* variables and see if the problems go away. Again, this is not the best way, so if someone here is willing to do a thorough job regarding this, I encourage him or her to take the first way, although it is harder. The advantage is that we will have a much better understanding and documentation of these flags, and will probably be able to improve the ad-hoc set of flags we have today and make it easier to use and maintain. (Ideally, these flags should be a single bitmap with individual reasons representing the causes for disabling optimizations, and each optimization should examine the bits it cares about.)
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 22:02:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 18:02:37 2023
Received: from localhost ([127.0.0.1]:40967 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qK4OS-0008W9-Vb
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 18:02:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51761)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qK4OP-0008Vo-OD
for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 18:02:35 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7DA148060E;
Thu, 13 Jul 2023 18:02:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7504B801D6;
Thu, 13 Jul 2023 18:02:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689285747;
bh=WmgyprsdoNW5tR0EfnsiSE0S47OZKb6tfO2cGBjiF/w=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=V1Pn0qX38f+Jc6ABZz64InMhvgXl8zgjUxblqc7HctdHSTCk0oDyOjjp/pBtxmzsS
876FaJ0OW5b7Ee1FTwW6Sgc9reFUX5QQuFJ8QwTKLYV5h8Ggap68Zdj2T2PQutBqMW
dHTJr7CQqb1GJuQkyrxigrKjFZpq/x728bfUE5+QvCKj5kbNPqCeQWiL7qF6zlfKn7
DvzagpUE0B4rKqSME0Thj9VxpuAEYmhT7lXeM4Y28Bo5G6p6q6tvmaB5xlIar0UJKW
cnXM5khELAnQLLSB3v/hXt87N6foFwwwDB8tnKZ/3uRNSsR73GDCf6yms2H+RFA/1O
ozbrTOWVfGh+Q==
Received: from pastel (unknown [104.247.239.133])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 490471201B8;
Thu, 13 Jul 2023 18:02:27 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83lefj4okb.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 13 Jul
2023 22:08:20 +0300")
Message-ID: <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
<83lefj4okb.fsf@HIDDEN>
Date: Thu, 13 Jul 2023 18:02:26 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: yantar92@HIDDEN, 64596 <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 (---)
> Then I guess you or Ihor (or both) should try removing that line and
> run with that for a while.
FWIW, I've been running without those two lines ever since I put this FIXME.
> Alternatively, maybe in the case of ALL non-nil the code should set
> the prevent_redisplay_optimizations_p flag of all the buffers that are
> displayed in some window, since some redisplay optimizations are not
> eligible when the mode-line is about to be updated.
Any reason why the corresponding optimizations don't consult the
`update_mode_lines` var (or the `update_mode_line` buffer flag), or
maybe have redisplay start by propagating the `update_mode_line` buffer
flag to `prevent_redisplay_optimizations_p`?
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 21:00:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 17:00:25 2023
Received: from localhost ([127.0.0.1]:40920 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qK3QH-0006Sd-EL
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 17:00:25 -0400
Received: from mout02.posteo.de ([185.67.36.66]:48313)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qK3QC-0006SB-Vs
for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 17:00:24 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id AE0C3240101
for <64596 <at> debbugs.gnu.org>; Thu, 13 Jul 2023 23:00:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1689282014; bh=/q4HZFegT/P0Kq5N56WR5k9Ogv08YvFvNW/2ptB1qRE=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
b=ZseDEfJaYYRp4foy33RrAbgT4xsI5a6Dw4CH8bGAhhXs9E/07R1XYtc3qZS33obLm
tM4D///SWZiFjSBpVZ2K1ZD5+t1+E6ERMhEPYvQshnSyLysGY0M7kDBq3iWYsp/XEo
CUQp17FS9wsXNUpf43GWr28Cuwm/gGpERUCEMWLZ85/jmh+a4NVBPROwcth8jnMaP3
4N6M77m6rk5HijWL+v5XVoPq5VDe09k+tm8QVtEXEKxyHc6wELL3W1027bsDOwQTJG
TgzXQM+twJ0Ieh4SStGQ0sfzz/bGSSvXSzVeiosSWL9IcpteZB/5qPefREQQShsA7W
p+DjObJNjF+9A==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4R26SY3v1yz9rxD;
Thu, 13 Jul 2023 23:00:13 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <83lefj4okb.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
<jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
Date: Thu, 13 Jul 2023 21:00:18 +0000
Message-ID: <87zg3zcysd.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <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 (---)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
> Then I guess you or Ihor (or both) should try removing that line and
> run with that for a while.
Yup. That's what I am already doing. See the attached diff.
Beware though that I still haven't looked closely into your and Stefan's
emails (it is late here) and I have no idea what I am doing in this
diff.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=test.diff
diff --git a/src/buffer.c b/src/buffer.c
index 0c46b201586..db7dc5c3c68 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1476,16 +1476,9 @@ DEFUN ("force-mode-line-update", Fforce_mode_line_update,
(Lisp_Object all)
{
if (!NILP (all))
- {
update_mode_lines = 10;
- /* FIXME: This can't be right. */
- current_buffer->prevent_redisplay_optimizations_p = true;
- }
else if (buffer_window_count (current_buffer))
- {
bset_update_mode_line (current_buffer);
- current_buffer->prevent_redisplay_optimizations_p = true;
- }
return all;
}
@@ -1502,6 +1495,8 @@ DEFUN ("set-buffer-modified-p", Fset_buffer_modified_p, Sset_buffer_modified_p,
{
Frestore_buffer_modified_p (flag);
+ if (!flag) current_buffer->prevent_redisplay_optimizations_p = true;
+
/* Set update_mode_lines only if buffer is displayed in some window.
Packages like jit-lock or lazy-lock preserve a buffer's modified
state by recording/restoring the state around blocks of code.
--=-=-=
Content-Type: text/plain
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 19:08:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 15:08:15 2023 Received: from localhost ([127.0.0.1]:40890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qK1fj-0003aK-1K for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:08:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qK1fe-0003a4-Pw for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:08:14 -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 1qK1fZ-0004Dm-A2; Thu, 13 Jul 2023 15:08:05 -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=Tdd9U6CBT5HOFeFG1PALo4B5Pa+VNLVeNoWE0/oGWUE=; b=J2aEH88Q+T1a O6+HmYQ7ZxHNBJpNpD1BAmJMBHrmXtPkXi9FTb46gXiM6dddpb1IeUa/6PNWPiEnbzL1CDugQ+0jo mLZqqYZlIzP++KRnbmDFIkLrmeHVHJOsFAbT7v0TUK+2TagYNQ9V00sPw4A5F2OmLohz8AZLT7xOh +E8K6WtS6ukPlbZs2fqAgEnO4MthS50ErFU0/7Sd98B1kp/BC2pCh1+rMRsizes6z4SwgHtU7B2nc byBy9pubAF5nSv7LoKYLNL/LxSOTPjyQDhGhw6zjwNaGL7IauqmtqzLUFanASiauII7dMZNPdtu+G wfcDA0eeHbY7jMhajDfMhw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qK1fY-0002yZ-Q3; Thu, 13 Jul 2023 15:08:05 -0400 Date: Thu, 13 Jul 2023 22:08:20 +0300 Message-Id: <83lefj4okb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvv8envj39.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: yantar92@HIDDEN, 64596 <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 (---) > Cc: 64596 <at> debbugs.gnu.org > Date: Thu, 13 Jul 2023 13:20:23 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > > AFAIU, the purpose of disabling redisplay optimizations is avoiding the > > situation when the modification flag is unset in the buffer, but the > > buffer was actually modified, and has to be redrawn. > > If my understanding is correct, > > current_buffer->prevent_redisplay_optimizations_p = true does not belong > > to `force-mode-line-update', but rather to `restore-buffer-modified-p'. > > I strongly suspect it doesn't belong in `force-mode-line-update`, indeed. To the ALL branch or to both of them? > > Stefan will tell, but I'm quite sure he wrote that FIXME because > > removing that line caused regression in some situation. > > Nope. I put the FIXME simply because I realized that the code doesn't > make sense: if that line is sometimes necessary, then I'm pretty sure it's > not always sufficient. Then I guess you or Ihor (or both) should try removing that line and run with that for a while. Alternatively, maybe in the case of ALL non-nil the code should set the prevent_redisplay_optimizations_p flag of all the buffers that are displayed in some window, since some redisplay optimizations are not eligible when the mode-line is about to be updated.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 19:03:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 15:03:11 2023 Received: from localhost ([127.0.0.1]:40873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qK1ap-0003Sb-2p for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:03:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1qK1am-0003SN-7h for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:03:10 -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 1qK1ah-0000fX-1A; Thu, 13 Jul 2023 15:03:03 -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=meeLW4IXkmdzb/jqqtk3Ok+hqewuvzeUNWMJ1FvHDqY=; b=fFB20TUtgrLW r6SnJo048UxLmnG1wXdXGymiIIV90Y71gBopxHVQSi/HixwjsW01M+rA+g+h3/1SmNwWzmbLhM2aM Bzri20vTSVikDMwwI/e22RM/0C97phksNekkqBug+sY/V3YRZvPTo7h2A8kstIPgtt/5jKrGU+4s0 llJ/Iuc2zMxBV7bryBpG7EQnTjj3bTlVhaW73X/eoEGvDMr7cJ7ZHF6zO8QKPAksOtPml5Hl1uOrm YSlSL1i4Hfg3em0oZdb+A/mRB4bKP0PRum2luJRKa5gXPzsWB4Il2xZjoQr09DlS2lIoMKJs21zg1 SLFpNgRFbsMDz6F7Zu723g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1qK1ag-0001nb-G2; Thu, 13 Jul 2023 15:03:02 -0400 Date: Thu, 13 Jul 2023 22:03:20 +0300 Message-Id: <83mszz4osn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87edlbd90e.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Jul 2023 17:19:29 +0000) Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN> <87edlbd90e.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: monnier@HIDDEN, 64596 <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 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org > Date: Thu, 13 Jul 2023 17:19:29 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The purpose of force-mode-line-update is to do what its name says, > > regardless of whether the buffer was modified or not, and how it was > > modified. The idea is that Lisp programs which change something that > > they know must affect the mode line call this function to make sure > > the mode line is redrawn with up-to-date information. > > I do not claim that I fully understand Who does, when it comes to the display code? > but what is confusing is that a number of other places in code > simply use bset_update_mode_line without disabling optimizations. In > particular: > > 1. kill-all-local-variables > 2. rename-buffer bset_update_mode_line is for a single buffer, whereas the FIXME is for the case where force-mode-line-update is called with a non-nil ALL argument. > Also, `force-window-update' disable optimizations for a given window, > but not when all windows should be updated - in contrast with the code > in OP. When all the windows need to be updated, we force that via windows_or_buffers_changed, which is a somewhat stronger flag, as far as preventing optimizations goes. > So, `force-window-update' and `force-mode-line-update' are at least > inconsistent. Why should they be entirely consistent? They do different jobs.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 17:20:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 13:20:33 2023
Received: from localhost ([127.0.0.1]:40761 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qJzzU-0006Xp-Si
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:20:33 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29042)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1qJzzS-0006Xa-Bt
for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:20:31 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9983A1000C3;
Thu, 13 Jul 2023 13:20:24 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8813510009E;
Thu, 13 Jul 2023 13:20:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1689268823;
bh=TB6qT68fXmFvxrFCCIIIAtLDR8zrnTs0URufBCoUZfY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=MpW3VzjjFfviMpg7UWT+1nRVHfVNB8pO8pNdKC6yFUBeC3z07zzgVX/a2wr6BLx2G
8OZROnZ1ignTVMDv2yh8ErXGc1PW0uATMQpywmL2kDrYjF3Sl6wpqWF+4NQGbY/XYG
+2cRnlzszelO2TEo4+RApr4gfiW1GmdDaEyFMu3s05pZEFWYpN6MBBpnNnBaqMA7C0
2kHpigZLKLuCwudBSI8b0moNQGfZDr1hvedxQsaitSpfGmOhjh9EVqdhhgv5YXBQfx
T0gpogz3yu0egpBewaM5uC6mLvqPVo9CAxVNIMz2+ujgABKB+1b5HYXL8PNKeeo3Bk
pBR96Q01t/rRw==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7A9091201E1;
Thu, 13 Jul 2023 13:20:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481
(force-mode-line-update)
In-Reply-To: <877cr4nez9.fsf@localhost> (Ihor Radchenko's message of "Thu, 13
Jul 2023 13:00:26 +0000")
Message-ID: <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
Date: Thu, 13 Jul 2023 13:20:23 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.073 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: 64596 <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 (---)
> `force-mode-line-update' has the following FIXME:
>
> if (!NILP (all))
> {
> update_mode_lines = 10;
> /* FIXME: This can't be right. */
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
> else if (buffer_window_count (current_buffer))
> {
> bset_update_mode_line (current_buffer);
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
>
> This FIXME has been introduced in 655ab9a3800, shortly after
> ecda65d4f7e, which moved this code from `set-buffer-modified-p'.
ecda65d4f7e changed `force-mode-line-update` from
(if all (with-current-buffer (other-buffer)))
(set-buffer-modified-p (buffer-modified-p)))
to
if (!NILP (all) || buffer_window_count (current_buffer))
{
update_mode_lines = 10;
current_buffer->prevent_redisplay_optimizations_p = 1;
}
That new code was (to the best of my knowledge) doing the same as what
the old ELisp code did (I got to that code basically by taking the sum
of the C code run by the original ELisp code and then simplifying it by
eliminating those things which canceled each other).
That code already had the same problem as the one I flagged with the
FIXME: when we do (force-mode-line-update t) the effect should be
global, so if `prevent_redisplay_optimizations_p` is needed in
`current_buffer` it should be needed in other displayed buffers as well.
> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> situation when the modification flag is unset in the buffer, but the
> buffer was actually modified, and has to be redrawn.
> If my understanding is correct,
> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
I strongly suspect it doesn't belong in `force-mode-line-update`, indeed.
> Stefan will tell, but I'm quite sure he wrote that FIXME because
> removing that line caused regression in some situation.
Nope. I put the FIXME simply because I realized that the code doesn't
make sense: if that line is sometimes necessary, then I'm pretty sure it's
not always sufficient.
Stefan
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 17:19:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 13:19:36 2023 Received: from localhost ([127.0.0.1]:40756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1qJzya-0006W5-Ej for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:19:36 -0400 Received: from mout01.posteo.de ([185.67.36.65]:52301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1qJzyW-0006Vp-36 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:19:35 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 34995240028 for <64596 <at> debbugs.gnu.org>; Thu, 13 Jul 2023 19:19:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1689268766; bh=fmt0hcUb1GkiNOz1pK0KA4HxG4lG8uhkhmP2/dphF18=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=PUIGMKaadePgYs5/aLf32Wxto0Hp5T807+CNrF6h6MN7bQO+CgaIWfR5QDbMwEZWS tdv4431iP+v2fPniG30EPiADrTnpmCULs1ufb0ArtjunqIwgP/W9XrwGSdRhDdABR1 dF6nzKHatXN+R6Q6BGnggCgvRm2QREAfQ4Kk20BEcAOGjN4NM1Yfc4vqssEv1sQMmB T0cksgV/00VyQ6kAIyMoyjE3M4uqBaLb3/6vnYnmfnGu+bOO2Eoqk1lApE8Ybe64by O27KY0MP/Rh17WfFB06nHeisByppKPDbMYjpczk3QDFroMf9LYLyiuKIUXuZHhrIGC moyR2j5fxVI2A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4R21Yn0N46z9rxB; Thu, 13 Jul 2023 19:19:24 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) In-Reply-To: <83v8eo3pfv.fsf@HIDDEN> References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN> Date: Thu, 13 Jul 2023 17:19:29 +0000 Message-ID: <87edlbd90e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64596 Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> If my understanding is correct, >> current_buffer->prevent_redisplay_optimizations_p = true does not belong >> to `force-mode-line-update', but rather to `restore-buffer-modified-p'. > > The purpose of force-mode-line-update is to do what its name says, > regardless of whether the buffer was modified or not, and how it was > modified. The idea is that Lisp programs which change something that > they know must affect the mode line call this function to make sure > the mode line is redrawn with up-to-date information. I do not claim that I fully understand, but what is confusing is that a number of other places in code simply use bset_update_mode_line without disabling optimizations. In particular: 1. kill-all-local-variables 2. rename-buffer Also, `force-window-update' disable optimizations for a given window, but not when all windows should be updated - in contrast with the code in OP. So, `force-window-update' and `force-mode-line-update' are at least inconsistent. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 13:34:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 09:34:43 2023
Received: from localhost ([127.0.0.1]:53601 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qJwSx-0000is-2N
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 09:34:43 -0400
Received: from eggs.gnu.org ([209.51.188.92]:38280)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1qJwSq-0000iR-Iz
for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 09:34:41 -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 1qJwSj-0003VK-3X; Thu, 13 Jul 2023 09:34:29 -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=slNUoZSrLoTqKKIauZV3ZgI+0c/6KxtoYYXwZq5n5G8=; b=dwafNwPRRFnO
sXN92kxMGXtrIFbKWDTmGFnh30EF18lE6aA+Tg1j4nKrLie7ScijMt56PApdGtQUiUy1jZlB6OWqj
eITiOohaeYUKrTxVmjhoo7kIkT1h8gOeBNoRO9X3HenNBTYlEcBKpdQAg8RJuz3SOIBOmKMQgjMS4
8QelzsnzF1okcZ368mw3rBxMduB1hN0gox87UJqMfyJ0gV1TGMb4RO8Mh6otz0QMoH0CM+VvDEqqz
f7xNcx54PGwitnZqhrkFn3yxqaSBxTVhsx0VuGbRfheSdQFGa8UAgh3bHHK562P/lXBh8+cH2ycBJ
GHEVCfo/kSyusSFBAhT3Uw==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1qJwSh-0008K7-Bw; Thu, 13 Jul 2023 09:34:28 -0400
Date: Thu, 13 Jul 2023 16:34:44 +0300
Message-Id: <83v8eo3pfv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <877cr4nez9.fsf@localhost> (message from Ihor Radchenko on Thu,
13 Jul 2023 13:00:26 +0000)
Subject: Re: bug#64596: 30.0.50;
On FIXME: in src/buffer.c:1481 (force-mode-line-update)
References: <877cr4nez9.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 64596
Cc: 64596 <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 (---)
> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Thu, 13 Jul 2023 13:00:26 +0000
>
> `force-mode-line-update' has the following FIXME:
>
> if (!NILP (all))
> {
> update_mode_lines = 10;
> /* FIXME: This can't be right. */
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
> else if (buffer_window_count (current_buffer))
> {
> bset_update_mode_line (current_buffer);
> current_buffer->prevent_redisplay_optimizations_p = true;
> }
>
> This FIXME has been introduced in 655ab9a3800, shortly after
> ecda65d4f7e, which moved this code from `set-buffer-modified-p'.
Yes, it was part of Stefan's effort to make redisplay less expensive
by avoiding too thorough redisplay in as many use cases as possible.
> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> situation when the modification flag is unset in the buffer, but the
> buffer was actually modified, and has to be redrawn.
No, it's more subtle. In a nutshell, it is meant to prevent redisplay
from applying certain optimizations (search xdisp.c for the uses of
this flag). These optimizations are based on various assumptions,
such as that the current glyph matrix of the window is up-to-date.
Setting the prevent_redisplay_optimizations_p flag tells the display
engine that those assumptions are (or might be) false.
Updating the mode line usually requires more thorough redisplay,
especially when the only reason for that is that some Lisp called
force-mode-line-update -- without setting that flag, the display
engine could easily decide that the window doesn't need to be redrawn.
> If my understanding is correct,
> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
The purpose of force-mode-line-update is to do what its name says,
regardless of whether the buffer was modified or not, and how it was
modified. The idea is that Lisp programs which change something that
they know must affect the mode line call this function to make sure
the mode line is redrawn with up-to-date information. By contrast,
buffer modifications could be such that don't affect redisplay at all,
or allow redisplay to use some shortcuts and redraw only a very small
portion of the window.
> I also grepped through src/display.c looking at the usage of
> update_mode_lines, and there seems to be no obvious situation where
> update_mode_lines being non-nil is ignored.
Stefan will tell, but I'm quite sure he wrote that FIXME because
removing that line caused regression in some situation. I see that
this flag is tested without also testing update_mode_lines in
window-lines-pixel-dimensions, window-line-height, window-end,
redisplay_window, try_window_id, and display_line. So I don't think I
agree with your conclusion.
bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 13 Jul 2023 13:00:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 13 09:00:50 2023
Received: from localhost ([127.0.0.1]:53578 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1qJvw6-00084w-U9
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 09:00:50 -0400
Received: from lists.gnu.org ([209.51.188.17]:39556)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1qJvw3-00084l-1k
for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 09:00:45 -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 <yantar92@HIDDEN>)
id 1qJvvx-0002vi-8h
for bug-gnu-emacs@HIDDEN; Thu, 13 Jul 2023 09:00:42 -0400
Received: from mout01.posteo.de ([185.67.36.65])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <yantar92@HIDDEN>)
id 1qJvvs-000811-Dq
for bug-gnu-emacs@HIDDEN; Thu, 13 Jul 2023 09:00:36 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id B1B06240028
for <bug-gnu-emacs@HIDDEN>; Thu, 13 Jul 2023 15:00:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1689253218; bh=16DSjzB/waXYU2h5O1KFtVW7ZyIBDPkni13O2SrW63Y=;
h=From:To:Subject:Date:Message-ID:MIME-Version:From;
b=OYjr2NNhqZhW5tDckx3tr/UZujHHEsLTfx9IylKnTAO08U0wmRXu4VD7GXKPWlQTl
hx9wF+cQtQ1vK7vI7ygKepX7LkBYnIZ26dGhFiX3Ni7WCc1k7d6PRecLCh+4jdL7jf
Cq3vTmjPNitC+NmFQAMX1bmdnvsuw4w7usERyVb/rj5quTxe4cVvLjZMnBnjZOg7hy
LSHimd4tF99AE2gCC1mtsN4rhN79o96ewuThuN2/1IRy2yu6DpHANTDGWETqH/IzBE
LeEPv+62qzMvVN9Ad6Dvh2BPZsynHIfcXaGCihf4m7YVRpGf1QikC2wKi8R2QaCwQr
DtmuS1OMWFtzg==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4R1vpn70JNz9rxS
for <bug-gnu-emacs@HIDDEN>; Thu, 13 Jul 2023 15:00:17 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Date: Thu, 13 Jul 2023 13:00:26 +0000
Message-ID: <877cr4nez9.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@HIDDEN;
helo=mout01.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 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,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
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: -2.3 (--)
Hello,
`force-mode-line-update' has the following FIXME:
if (!NILP (all))
{
update_mode_lines = 10;
/* FIXME: This can't be right. */
current_buffer->prevent_redisplay_optimizations_p = true;
}
else if (buffer_window_count (current_buffer))
{
bset_update_mode_line (current_buffer);
current_buffer->prevent_redisplay_optimizations_p = true;
}
This FIXME has been introduced in 655ab9a3800, shortly after
ecda65d4f7e, which moved this code from `set-buffer-modified-p'.
AFAIU, the purpose of disabling redisplay optimizations is avoiding the
situation when the modification flag is unset in the buffer, but the
buffer was actually modified, and has to be redrawn.
If my understanding is correct,
current_buffer->prevent_redisplay_optimizations_p = true does not belong
to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
I also grepped through src/display.c looking at the usage of
update_mode_lines, and there seems to be no obvious situation where
update_mode_lines being non-nil is ignored.
In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.17.8) of 2023-07-06 built on localhost
Repository revision: d97b77e6c66db46b198c696f83458aa141794727
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Gentoo Linux
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
Ihor Radchenko <yantar92@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#64596; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.