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#75291: Redisplay not updating fringe when face filter changes Date: Thu, 02 Jan 2025 21:26:55 +0200 Message-ID: <86v7uxhv9c.fsf@gnu.org> References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12076"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75291@debbugs.gnu.org, mina86@mina86.com To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 20:28:31 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 1tTQru-0002wn-Ph for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 20:28:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTQrV-0008RH-3L; Thu, 02 Jan 2025 14:28: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 1tTQrS-0008Qy-S2 for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:28: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 1tTQrS-0000BT-J1 for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:28:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=mg03liASSVXXZSBV0CrBHa3bHwRNNGLozBpLD8e24gI=; b=uCgh4dKrXo/czpb4JbHjZ/TBFHpzgtH6qZYL1tEbXar5iLooKl4jbmUZjXZrbDtn9MAzMDawwmYlvZLtRrOPea0jv8CHfeaPq47EXf8r7ySEr3lp/jtGfUNTDkWAlxS3E1cG11bdxRnMAo+aMFIOrb0LyuGBXnrMYmgbL0EMhzcLzad9xw0y26lwRZxZO3ijyl7qBtSu48bdFYKCRxnUgZQ3c2L5lbLxxw8zhpZHHtsfETcLt4auA53A0qLzelzjA1WHHllyNzI6LxzxXClAHhO8cNJte0A4OoQEzJAk3h2I4OX1M4+50nUX/1c82PXM2Ct6fCNvVBjFiha//VonSQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTQrS-00032q-E1 for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 14:28:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 19:28: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.173584603411611 (code B ref 75291); Thu, 02 Jan 2025 19:28:02 +0000 Original-Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 19:27:14 +0000 Original-Received: from localhost ([127.0.0.1]:46728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTQqg-00031A-11 for submit@debbugs.gnu.org; Thu, 02 Jan 2025 14:27:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45846) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTQqe-00030t-2M; Thu, 02 Jan 2025 14:27:13 -0500 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 1tTQqV-0008RA-Hx; Thu, 02 Jan 2025 14:27:05 -0500 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=mg03liASSVXXZSBV0CrBHa3bHwRNNGLozBpLD8e24gI=; b=ntDjFcbGhHI/ SGNuTftexudzPIm7acbzZzvl5pqxyBeKUSgGrAHEEHKv19EAdO/tvsoLwQZi+H8czkvDXgiQcuUc9 YGEzZ19Hft12tBSOjZV1n3zCe90lXy5NC46CWoNodnEOBQErQQ4YTCW7HomNu4EmRXK2vClLZsbpu bIaYVIrdPlOlDXZBichuJf9udO7Bt8em7zPlrB9cKWjT2ctR8O4Xck44L60A7f1WIQHgYhQwJt2dL onNVxN3AowP3kM7EEaNR0uLVPWYdGeYM9lq2qZGbpfKnzzp5TCbA8FoNgXPzsAvsvKI6hpEyBllkl K/Jk0AzoAu/1F3I74Omo3Q==; In-Reply-To: <87ttah2hcd.fsf@dancol.org> (message from Daniel Colascione on Thu, 02 Jan 2025 13:36:34 -0500) 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:298223 Archived-At: 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. > 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! 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. 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. 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.