From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) Date: Sun, 16 Jul 2023 13:30:06 +0300 Message-ID: <835y6k9mj5.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@gnu.org> <83fs5r3tqv.fsf@gnu.org> <834jm6fppc.fsf@gnu.org> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@gnu.org> <83a5vxejz6.fsf@gnu.org> <83r0p9b3om.fsf@gnu.org> <83jzv1b152.fsf@gnu.org> <83a5vxas9k.fsf@gnu.org> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@gnu.org> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@gmx.at> <87wmz0i709.fsf@localhost> <83edl89qvd.fsf@gnu.org> <87a5vwi46v.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25271"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 64596@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 16 12:30:11 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKz10-0006MP-7j for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 12:30:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKz0u-0008E1-Lw; Sun, 16 Jul 2023 06:30:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKz0t-0008Dr-Ln for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 06:30:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qKz0t-0000Lp-CO for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 06:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKz0t-0003fY-6r for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 06:30:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jul 2023 10:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64596 X-GNU-PR-Package: emacs Original-Received: via spool by 64596-submit@debbugs.gnu.org id=B64596.168950339214063 (code B ref 64596); Sun, 16 Jul 2023 10:30:03 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:29:52 +0000 Original-Received: from localhost ([127.0.0.1]:46905 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKz0h-0003el-R5 for submit@debbugs.gnu.org; Sun, 16 Jul 2023 06:29:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKz0f-0003eW-65 for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 06:29:50 -0400 Original-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 ) 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==; Original-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 ) id 1qKz0Y-0004f4-Pd; Sun, 16 Jul 2023 06:29:43 -0400 In-Reply-To: <87a5vwi46v.fsf@localhost> (message from Ihor Radchenko on Sun, 16 Jul 2023 09:41:28 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265311 Archived-At: > From: Ihor Radchenko > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 64596@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.