From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#75291: Redisplay not updating fringe when face filter changes Date: Thu, 02 Jan 2025 14:50:54 -0500 Message-ID: <87ikqx2dwh.fsf@dancol.org> References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20781"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.8; emacs 31.0.50 Cc: 75291@debbugs.gnu.org, mina86@mina86.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 20:52:24 2025 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 1tTRF1-0005Fm-E4 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 20:52:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTREj-00064G-Az; Thu, 02 Jan 2025 14:52:05 -0500 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 1tTREh-00063i-5W for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:52:03 -0500 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 1tTREg-0004Qq-Tq for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:52:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=MgbQwNI6ZzOEzCH6yHZZ/3OH/RhMm6sYVH4M83tL9NU=; b=TTjQhQwD2xDRFwBZgm425VzhIj5kHSCDPs2G/p1jYB2kfCmtjN4dMZYECIXfSFIcBcB839sLlco4jYI2Y5uIymkUqV4fH0l4VKe4cGHz5HOOg3BKUXJszYkZOUBhSHNwiZKebq2yZStNtrxwnmLU/uwInEoHdtpvBCSK81WYpIqx802v6Tmgbu3p0xM+x+59soqjDVQW6CQM5cALVduzkXrY6a3GkOgGiUS8JYYDlM1a360X3kEopMb1MgcPl+rewnHZ81C3c6Wcg6yODFMDFppsAjY/C7loeSh6I5+lkovqtJlDYpUhybWz5j27i7t1+dPLGUMe0IrdOOYkq7ZfVw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTREg-0004Ov-Ad for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 19:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75291 X-GNU-PR-Package: emacs Original-Received: via spool by 75291-submit@debbugs.gnu.org id=B75291.173584746316735 (code B ref 75291); Thu, 02 Jan 2025 19:52:02 +0000 Original-Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 19:51:03 +0000 Original-Received: from localhost ([127.0.0.1]:46773 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTRDi-0004Lr-9K for submit@debbugs.gnu.org; Thu, 02 Jan 2025 14:51:02 -0500 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:36652) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTRDf-0004LH-3O for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 14:51:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MgbQwNI6ZzOEzCH6yHZZ/3OH/RhMm6sYVH4M83tL9NU=; b=N3bsGqBuXVybOr3U6sbb57CHJy Z48BUYyoh3przZqaYylcVx9K4WNqTfj3Nrl0rx0nDmCu5VRmqn2GRCpMMTrvMztdWYgtvD4Qnjvnt sPRxeEgj2XIbQmzflu6CuxtLOfoYmwtRLIS3nkKauQfD7KDsRc5NoWoPctPZ7sIV4meLPshNrERKc GMc8/l7FTrrm0xHXZqQLSFO8rFLFzXbZkECfES43QphaE35WFWVPwZHIxl45TxBXCne0dFrMrmPYE HDnTRd6F9t3Q+DZLIl7R3G1BN2k2teUOf5UuplcNzrtvPcS+lP4lHMiJPvNoSxe5H3dqrEOKwSXvk xgnylwhg==; Original-Received: from 2603-9001-4203-1ab2-bd9e-ad89-4d97-f163.inf6.spectrum.com ([2603:9001:4203:1ab2:bd9e:ad89:4d97:f163]:42720 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTRDc-0001Sv-17; Thu, 02 Jan 2025 14:50:56 -0500 In-Reply-To: <86v7uxhv9c.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2025 21:26:55 +0200") 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:298227 Archived-At: Eli Zaretskii writes: > merge 75291 74876 > thanks > >> From: Daniel Colascione >> Cc: 75291@debbugs.gnu.org, Michal Nazarewicz >> Date: Thu, 02 Jan 2025 13:36:34 -0500 >> >> Eli Zaretskii writes: >> >> > I think this is bug#74876 again. I tried to explain there why the way >> > the fringe drawing is implemented doesn't work well with >> > face-remapping (or with changes in the fringe face in general). >> > >> > Maybe I'm missing something, but supporting what this and that bug >> > want would need a rewrite of update_window_fringes (and possibly also >> > the way we record fringes' attributes in the glyph row). >> >> That's amazing. Seven years ago, I implemented >> https://github.com/dcolascione/emacs-window-highlight/blob/master/window-highlight.el. >> I worked around the bug we're discussing using redraw-display. I see >> that Michal (++) implemented the same feature independently and reported >> the same bug just a few weeks before I got around to reporting the same >> bug from seven years ago! Pure serendipity. > > Yes, redrawing everything will work, but will also cause flicker, and > is generally expensive, thus undesirable. FWIW, it doesn't seem to cause flicker in practice. I see flicker only when walking through messages in mu4e --- we do redisplay and draw only the background, and I haven't figured out why yet. But in general, on a modern window system, turning a given redisplay into a full redisplay shouldn't cause flicker, even if it's inefficient. >> Anyway, given that the feature has been implemented twice now, maybe we >> can find some way to make it work efficiently? I haven't looked into >> how exactly we do fringe invalidation, but isn't there a way we can >> limit the blast radius of the redraw by providing a lisp-level function >> to invalidate extra GUI parts of specific windows rather than forcing a >> redraw-frame? It's not clear to me why we couldn't skip redrawing every >> row's content but redraw every row's fringe anyway. >> >> Ideally, a change to a face in which the change couldn't possibly affect >> layout (e.g. changing a background color) would be pretty efficient from >> a redisplay POV, since we wouldn't have to even try to reflow any text. > > AFAIR, the current implementation is the other way around: when some > glyph row changes, we consider redrawing its fringes. E.g., > draw_window_fringes only considers glyph rows that are enabled in the > glyph matrix, which means redisplay found that glyph row has changed. > Clearly, someone didn't think the fringe face will change during a > session! I came across overlay_arrows_changed_p --- isn't this function trying to deal with exactly the case of something in the fringe changing outside the changed text region? > Regarding your idea about Lisp function that would invalidate GUI > parts: it is not very easy, since a Lisp program cannot easily know > where on the screen a given region of buffer positions will be. > There is posn-at-point, of course, but (a) it is quite expensive, and > (b) when Lisp runs, display could be outdated, so what posn-at-point > returns could be inaccurate. I was imagining a lisp function that would make the next redisplay of a window do what you suggest in the next paragraph. I'm not sure we'd even need an explicit Lisp function though. Face filters with :window are defined to compare window parameter values with eq, so couldn't we keep track of all the :filtered face specifications we encounter during face resolution and have set-window-parameter check whether the parameter it's setting is on the list of possible face filters and, if so, force next redisplay to evaluate faces? set-window-parameter wouldn't even have to do a deep comparison, because it's just eq. > In any case, I don't think this will be needed in the case in point, > because when the fringe face changes, we'd want to redraw the fringes > of the entire window, right? So redisplay_window would need to notice > the change in the face, and invoke update_window_fringes in a special > way, such that update_window_fringes marks fringes to be redrawn not > only when the glyph row is enabled. Maybe that would work. > The way to "notice the change in the face" is not a simple problem to > solve, btw. We currently don't know which faces change when some face > is modified. So we have a frame-global flag that is set when any face > changes its attributes. If we use that flag for detecting potential > changes in the fringe face, we'd start redrawing fringes > unnecessarily. How many unnecessary face recalculations would we do? ISTM we could make the invalidation pretty precise as long as we're just looking at window parameters. > We could add a special flag for the fringe face, but > then we'd need to add a special mechanism in xfaces.c which would > analyze each change in some face's attribute and determine whether it > could possibly affect the fringe face. Or maybe I'm missing some more > elegant/easier solution.