unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 75291@debbugs.gnu.org, mina86@mina86.com
Subject: bug#75291: Redisplay not updating fringe when face filter changes
Date: Fri, 03 Jan 2025 12:25:05 -0500	[thread overview]
Message-ID: <87ldvrajym.fsf@dancol.org> (raw)
In-Reply-To: <86h66hhr3a.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2025 22:56:57 +0200")

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Colascione <dancol@dancol.org>
>> Cc: 75291@debbugs.gnu.org,  mina86@mina86.com
>> Date: Thu, 02 Jan 2025 14:50:54 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > 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.
>
> I think it depends on whether you use double-buffering (some people
> don't or cannot) and whether you have the mouse pointer over an Emacs
> frame.  Also, depending on the GUI toolkit, the decorations might
> flicker.

TTY windows don't have fringes, and the most commonly-used window
systems all do atomic updates nowadays.

>> 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?
>
> So you want to add to display_line code that sets each glyph_row's
> redraw_fringe_bitmaps_p flag when the fringe face changes?  That could
> probably work, provided that we disable redisplay optimizations which
> might avoid calling display_line (you will see that we already disable
> such optimizations when overlay_arrows_changed_p returns non-zero).
> We might actually need to disable more of the optimizations, because
> the overlay-arrow thing doesn't contradict the optimizations that
> scroll the pixels, something that reaction to changes in the fringe
> face cannot tolerate.

That might work, but I don't think we even need anything that
complicated or low-level.  Not many are using :filtered now, and those
that do big redraws anyway.  How about this simpler code that gets us
correctness, albeit more conservatively?

diff --git a/src/window.c b/src/window.c
index 5a10c381eaf..6d135a67a66 100644
--- a/src/window.c
+++ b/src/window.c
@@ -2396,11 +2396,29 @@ DEFUN ("set-window-parameter", Fset_window_parameter,
   Lisp_Object old_alist_elt;
 
   old_alist_elt = Fassq (parameter, w->window_parameters);
+
+  /* If this window parameter has been used in a face remapping filter
+     expression and we changed its value, force a from-scratch redisplay
+     to make sure that everything that depends on the window parameter
+     value is up-to-date.  FIXME: instead of taking a sledgehammer to
+     redisplay, we could be more precise in tracking what display bits
+     depend on which remapped faces.  Skip redrawing TTY frames: they
+     don't have fringes or other graphical bits we might have to redraw
+     here.  */
+  if (SYMBOLP (parameter) &&
+      WINDOW_LIVE_P (window) &&
+      FRAME_WINDOW_P (WINDOW_XFRAME (w)) &&
+      !NILP (Fget (parameter, Qface_filter)) &&
+      !EQ (CDR_SAFE (old_alist_elt), value))
+    redraw_frame (WINDOW_XFRAME (w));
+
   if (NILP (old_alist_elt))
     wset_window_parameters
       (w, Fcons (Fcons (parameter, value), w->window_parameters));
   else
     Fsetcdr (old_alist_elt, value);
+
+
   return value;
 }
 
diff --git a/src/xfaces.c b/src/xfaces.c
index d1ca2e0d5d4..1f58bdbf6ae 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -2512,6 +2512,9 @@ evaluate_face_filter (Lisp_Object filter, struct window *w,
     if (!NILP (filter))
       goto err;
 
+    if (NILP (Fget (parameter, Qface_filter)))
+      Fput (parameter, Qface_filter, Qt);
+
     bool match = false;
     if (w)
       {
@@ -7623,6 +7626,8 @@ syms_of_xfaces (void)
   Vface_remapping_alist = Qnil;
   DEFSYM (Qface_remapping_alist,"face-remapping-alist");
 
+  DEFSYM (Qface_filter, "face-filter");
+
   DEFVAR_LISP ("face-font-rescale-alist", Vface_font_rescale_alist,
 	       doc: /* Alist of fonts vs the rescaling factors.
 Each element is a cons (FONT-PATTERN . RESCALE-RATIO), where





  reply	other threads:[~2025-01-03 17:25 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02 17:30 bug#75291: Redisplay not updating fringe when face filter changes Daniel Colascione
2025-01-02 17:50 ` Eli Zaretskii
2025-01-02 18:36   ` Daniel Colascione
2025-01-02 19:24     ` Michal Nazarewicz
2025-01-02 19:26     ` Eli Zaretskii
2025-01-02 19:50       ` Daniel Colascione
2025-01-02 20:56         ` Eli Zaretskii
2025-01-03 17:25           ` Daniel Colascione [this message]
2025-01-03 19:31             ` Eli Zaretskii
2025-01-03 19:46               ` Daniel Colascione
2025-01-03 20:10                 ` Eli Zaretskii
2025-01-03 20:27                   ` Eli Zaretskii
2025-01-03 20:57                   ` Daniel Colascione
2025-01-04  7:12                     ` Eli Zaretskii
     [not found]                       ` <C3F80FE6-077F-4A74-9C48-DD9EAE4E3266@dancol.org>
2025-01-18  9:29                         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ldvrajym.fsf@dancol.org \
    --to=dancol@dancol.org \
    --cc=75291@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).