From unknown Sat Jun 21 03:25:00 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#75291 <75291@debbugs.gnu.org> To: bug#75291 <75291@debbugs.gnu.org> Subject: Status: Redisplay not updating fringe when face filter changes Reply-To: bug#75291 <75291@debbugs.gnu.org> Date: Sat, 21 Jun 2025 10:25:00 +0000 retitle 75291 Redisplay not updating fringe when face filter changes reassign 75291 emacs submitter 75291 Daniel Colascione severity 75291 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 12:30:38 2025 Received: (at submit) by debbugs.gnu.org; 2 Jan 2025 17:30:38 +0000 Received: from localhost ([127.0.0.1]:46466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTP1q-0004xd-EL for submit@debbugs.gnu.org; Thu, 02 Jan 2025 12:30:38 -0500 Received: from lists.gnu.org ([2001:470:142::17]:54210) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTP1o-0004xA-IF for submit@debbugs.gnu.org; Thu, 02 Jan 2025 12:30:36 -0500 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 1tTP1c-0005mF-SE for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:30:28 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTP1Z-0007UD-Tl for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:30:23 -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:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lQfAAvpv9kgxmwg5X9f+1DBPyY0T4OmfD3K6ViA01Tg=; b=T+2odeivbqO0qzH59V8RKAaGYU CLi9u2i8Zo1wCnW8DfwINxNJRjFXQWMtw+N6mvLwlVr8YQBKX5mK8MI8p1HIbKWuLzyfx9HcaX2rb g3ULcE1mbjLFuiZ/qqaG8T+24jQRtxHTD5SgZVcRyDtDBzbnYXR0pcxyH6B5iLg3vDjGCJh4ViX9N wmooDcqGf7OnF7FtDQ1ijUzvnMbINDiWqd1+cPHvQOuBlt4ah5L1F7phJCaHZmyDhmxOBw8kERIGS 69A/RVhRrc8QYL7BKh0P06pGMgm2FN2+2BcR+iJ7fun7Cjc8BAC+9z49RKKwOP+4e7RtEnlzfa9U8 aHoVcAEg==; Received: from 2603-9001-4203-1ab2-bd9e-ad89-4d97-f163.inf6.spectrum.com ([2603:9001:4203:1ab2:bd9e:ad89:4d97:f163]:48858 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTP1V-0000yB-1D for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:30:17 -0500 From: Daniel Colascione To: bug-gnu-emacs@gnu.org Subject: Redisplay not updating fringe when face filter changes User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Thu, 02 Jan 2025 12:30:16 -0500 Message-ID: <874j2h3yzb.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) Sometimes we don't redraw when its effective face changes indirectly due to a face filter condition evaluating differently. An explicit redraw-display works around the problem, but it shouldn't be necessary and is an efficiency hit. See the code below: ;; -*- lexical-binding: t -*- ;; emacs -Q (setf my-window (selected-window)) (dolist (face '(default fringe)) (face-remap-add-relative face `(:filtered (:window foo t) (:background "green")))) (set-window-parameter my-window 'foo t) ;; During this sit-for, background and fringe should be green (sit-for 1) (set-window-parameter my-window 'foo nil) ;; Enable to work around bug (when nil (redraw-display)) ;; During this sit-for, background and fringe should be their original ;; color (probably white), but only the background changes. ;; Without redraw-display, the fringe remains green. (sit-for 1) From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 12:50:42 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 17:50:42 +0000 Received: from localhost ([127.0.0.1]:46513 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTPLG-0005wj-Fu for submit@debbugs.gnu.org; Thu, 02 Jan 2025 12:50:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52184) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTPLD-0005wO-JN for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 12:50:40 -0500 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 1tTPL7-0002Nh-Nj; Thu, 02 Jan 2025 12:50:33 -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=/QJnUk3axpzPuJ2jvUnjAcVxSeDz2UIO6UCHhIxhvME=; b=U9fTWEPUUQI1 /pEs+EM0fnBCXI2JeNUmJV64wZv5kO/6s7EPcL9pQPAMl+azts0GuTv9bkgIlVSQ8D5WmFFrfuBUf CBJHxaienL+Uh6A49oMxo1IC9Snwt6dvgQrJlccv98tx3b5pgX/t6UeEU4IvHuNuYob2yguZx0qPt fcWnb6tq03Y0I4UK7hzPl3Xb3yudO+q0CaZ3Y08BY0EG+IqCk5ALEI4Ab82p8fxb275I0ylWFSlt6 tHEX+RTvh+UqbO0kLuTkF6zLbfEclo4Q4kH4lY6KjRo0bJUDAe1N4WybAC8zrpoS+vjROufgqsDe6 3L641kVC9xlT8xCfNC05nw==; Date: Thu, 02 Jan 2025 19:50:29 +0200 Message-Id: <8634i1jeai.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <874j2h3yzb.fsf@dancol.org> (message from Daniel Colascione on Thu, 02 Jan 2025 12:30:16 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Colascione > Date: Thu, 02 Jan 2025 12:30:16 -0500 > > Sometimes we don't redraw when its effective face changes indirectly due > to a face filter condition evaluating differently. > > An explicit redraw-display works around the problem, but it shouldn't be > necessary and is an efficiency hit. > > See the code below: > > ;; -*- lexical-binding: t -*- > > ;; emacs -Q > > (setf my-window (selected-window)) > > (dolist (face '(default fringe)) > (face-remap-add-relative > face `(:filtered (:window foo t) (:background "green")))) > > (set-window-parameter my-window 'foo t) > > ;; During this sit-for, background and fringe should be green > (sit-for 1) > (set-window-parameter my-window 'foo nil) > > ;; Enable to work around bug > (when nil > (redraw-display)) > > ;; During this sit-for, background and fringe should be their original > ;; color (probably white), but only the background changes. > ;; Without redraw-display, the fringe remains green. > (sit-for 1) 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). From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 13:36:43 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 18:36:43 +0000 Received: from localhost ([127.0.0.1]:46619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTQ3m-0008VS-UA for submit@debbugs.gnu.org; Thu, 02 Jan 2025 13:36:43 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:39780) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTQ3k-0008VF-77 for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 13:36:41 -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=PCkIHZZpAl66jaDNkZWMHvEsMJXXuRqv55qyfAV8nHU=; b=FCXlAs02/NpOD4+roTT7q4E9IT OY+u9ASxxdzPIPFBMJBLaRbrTFTKjV/rdWtYYuH0raHY49pSYDu1RSMW0Oa/aQvA+StyQuMQpYY8i yX+KMQD91Pjg+klNBlWbcpFZ7a9x9LcwtYmxvWqYbaTA1pjMx/FUYzfsfN4FQPjqkY4CbD1AlmJo1 9QLM7aBykIv1FhM47ny69WRvLou9/k6eDxHDeYJ/pT2PcT6X64a4nMxsFPAy6hVBBuLfFVVZ44X5f 0UFUvc+lHcVhI45ePfW3j6EJX3RTLSDmVfiUanvTVgdVadw4c1Cotej2nmV2JMy7LMSXDOJbNApZN T27aQo8A==; Received: from 2603-9001-4203-1ab2-bd9e-ad89-4d97-f163.inf6.spectrum.com ([2603:9001:4203:1ab2:bd9e:ad89:4d97:f163]:50962 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTQ3g-0001Ef-1D; Thu, 02 Jan 2025 13:36:36 -0500 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <8634i1jeai.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2025 19:50:29 +0200") References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Thu, 02 Jan 2025 13:36:34 -0500 Message-ID: <87ttah2hcd.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, Michal Nazarewicz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Date: Thu, 02 Jan 2025 12:30:16 -0500 >> >> Sometimes we don't redraw when its effective face changes indirectly due >> to a face filter condition evaluating differently. >> >> An explicit redraw-display works around the problem, but it shouldn't be >> necessary and is an efficiency hit. >> >> See the code below: >> >> ;; -*- lexical-binding: t -*- >> >> ;; emacs -Q >> >> (setf my-window (selected-window)) >> >> (dolist (face '(default fringe)) >> (face-remap-add-relative >> face `(:filtered (:window foo t) (:background "green")))) >> >> (set-window-parameter my-window 'foo t) >> >> ;; During this sit-for, background and fringe should be green >> (sit-for 1) >> (set-window-parameter my-window 'foo nil) >> >> ;; Enable to work around bug >> (when nil >> (redraw-display)) >> >> ;; During this sit-for, background and fringe should be their original >> ;; color (probably white), but only the background changes. >> ;; Without redraw-display, the fringe remains green. >> (sit-for 1) > > 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. (BTW: my code uses pre-redisplay-function, not a command hook. I've tried it both ways and found the redisplay hook to be more reliable.) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 14:24:51 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 19:24:51 +0000 Received: from localhost ([127.0.0.1]:46713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTQoM-0002oT-V5 for submit@debbugs.gnu.org; Thu, 02 Jan 2025 14:24:51 -0500 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:50646) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tTQoK-0002oI-NW for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 14:24:49 -0500 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d3e9a88793so20803791a12.1 for <75291@debbugs.gnu.org>; Thu, 02 Jan 2025 11:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735845887; x=1736450687; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:face :references:in-reply-to:subject:cc:to:from:sender:from:to:cc:subject :date:message-id:reply-to; bh=OPQquKrTI0VxjYfQaB1HLY8JyJIN/bwUx5vBdFYnfG8=; b=hngw5+K4Xx30YgXMBp+0K4QyvkP0tdez5YwWYBvWgKYh0qJMNbNcmE/1N25TeL6LGS /6oM9IlUVOyQwhxTXL2SCbbAEORTKxw+QwiHc59EzpIYa7oEHw1s3Fy7UsW7DSbsFG4S 6Lj9GHx3fppXbDWbWg7UITALXFIQ3PchhsJ96no5vRiKIP4I5yF+0yMVeFf0KaZq0lET TlcY8y8JECz32AxthSwP7SBxIj4H3hlbVLL4ph5IDcmO2qYTXI/4ObnS3RvuTH5SbJL7 CQyKcHXES1vcXPsZagTPS+BVrVQBrkovaBGyJWP5ObXLgxZV2H/zuHOb0Zt7kXed5JnR EVfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735845887; x=1736450687; h=content-transfer-encoding:mime-version:message-id:date:face :references:in-reply-to:subject:cc:to:from:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OPQquKrTI0VxjYfQaB1HLY8JyJIN/bwUx5vBdFYnfG8=; b=hkkE5MTnLt6Q6TFJDF3+a1nFdOdQfRvqSsOKCRPKpzmNViQzVaUFs6W+SrVTQMFrEU hrYcoRD8fGRfzXq8G/sIr37rYq3Z88ltBdILJMDIV44fyUTQM3vaAJilXLX9KFfKpn+T ym0XjnMFG9iLbsOsvCwoBgwRLeY8lqZ2d/WBS4hXsb6tHnbo0Xg8/Dj94tRaDZMJnizh A9se5A9Hpr8+mVamQ2802VPDCRGXVmUium9BNnmUfvjIQRe+1OG8oajRKMAyk4vpx4XZ IiGMfljlFcF4TVIgD5RzcXoj81MQTUznqfdtrMfn7rwhKu/CAXG/cp7ctymCxHih+roP ixHw== X-Gm-Message-State: AOJu0YzB9vH9qk9WZvNsISrDieaxHsm+J0d6RFb0hiwn1o+bXW+KP6Ap cWWn+LLo+GKDN/UcSHKUKqSc7YK+XEd0i0qNJ8LLUPM4kfgTQd4fGTvnR5lH X-Gm-Gg: ASbGnctmq3oOZbs63ohRzSqDF4DPUTEBHi277CkvPE4aKS5oXkObNb6qBfkWPmhdbj4 vtvLSu9zYpha7Mkk86DvhCpqcjNo5yuBI4/uZFzKw+sNSl6jMoydkPYMopyWp2HywYomSC7p3Z4 3IphqQ61Kk90+iS7c4gHdxpK5x2id45mLRJcTT90Ab9JScIi6Y8ubwT9d3Wi+jx85muz6jbRiDC FRp21TMLH0LcyRlDX1oYaWynDdFNa5Q+25S8CAKNh8mmz5igHBXK+Kd5OyvR1P7PCgPuRXFSa+0 DLth0A== X-Google-Smtp-Source: AGHT+IHM1HuTVrZamwUTekbdDxkJ/npf9WWk5i+eVwVV1dO/VNkRcVLerQyoQrCtmLS6FUa6voiOvg== X-Received: by 2002:a17:907:3f2a:b0:aa6:5603:e03d with SMTP id a640c23a62f3a-aac336631f6mr3836478466b.59.1735845886676; Thu, 02 Jan 2025 11:24:46 -0800 (PST) Received: from erwin (87-205-2-211.static.ip.netia.com.pl. [87.205.2.211]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e894c2esm1843539466b.67.2025.01.02.11.24.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jan 2025 11:24:46 -0800 (PST) From: Michal Nazarewicz To: Daniel Colascione , Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <87ttah2hcd.fsf@dancol.org> References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWjgIPUupJ7V0jLrom4gmjPs42bY0MdFRLHgE5UPDCbfGm9mH6qmkAJAAACNUlEQVQ4y23SMW/aQBQHcKtb2Zx0abZeIxuTCSELJVmiinboRpGHJktloROQzUQcB2vUXFe35XBYUicRAiYUVSjfru/d+QwlnDz5p/97z+dnVcw5WVQ2zxpcdrQTTiIin3bB6lcaTnaBO5c8eoJG2yBl5El+Ob3fglMW3RUIkQ9xxQ8UBEFQafiVZ/5wZqWExM+LvwEegAY856xZO7MgQkq3jxpO56GXxO5VDQAjpVmWqPLYoSGvIahIuvAVHLeEEDd9DRYAkUcKzscAUgCQ0hwSKBOExuh7kvQQUskY4yjsHqeaCfFjLK6x1AzeeyiRD/C1JW5aGqw5IS5mZre+FVz0RVtoUGPJmBCP/4QPJGKUA1oEMJwAHIv+JljYZYCJi1FRQS2DaUw6sgsQTMfb0Fz9RvjyP3iR01x9RGj0N6HgcefS819CSjidDwIFPSFEDgRg1tUw2oBXAB33T2DV63XbM6AqhZzysm3ZcKZrKBAn5O7Q1rAqGoBKNGRsmUG1n0NKaJtd2RnscTWvnom6fGngDaNrCNl728A+c2gLQP8PFpkEjNWjlGqQfPEhWRqoInSyi2p+drsGDjhAeAeSQI8kfjSwbwCn8gblvIftInzT30HdQT2HlU4gwCbLSQ7VFqVEA0RCtjTwtnjdLlkasNjQwF7x02F2iQSL8XIGB8VQ71WBKHHf5XCIgLUUtIcGSBPhdZIQorpEBrxsqT3GYgRpmicIqrsEgSZm3FG+iJbHYid0/wGj+iTGCXRsqQAAAABJRU5ErkJggg== Date: Thu, 02 Jan 2025 20:24:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.9 (++) 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: > 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 c [...] Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mnazarewicz[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2a00:1450:4864:20:0:0:0:52f listed in] [list.dnswl.org] 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.6 MSGID_RANDY Message-Id has pattern used in spam X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.9 (+) 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: > 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 c [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2a00:1450:4864:20:0:0:0:52f listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mnazarewicz[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 2.6 MSGID_RANDY Message-Id has pattern used in spam -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager > 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). On Thu, Jan 02 2025, Daniel Colascione wrote: > (BTW: my code uses pre-redisplay-function, not a command hook. I've > tried it both ways and found the redisplay hook to be more reliable.) FYI, the actual auto-dim-other-buffers code doesn=E2=80=99t use pre-command-hook. It uses hooks for window, buffer or focus changes. > Anyway, given that the feature has been implemented twice now, maybe we > can find some way to make it work efficiently? Since I managed to work-around the issue, I haven=E2=80=99t looked closely = at the low-level details of the redrawing code. From afar it certainly looks like it should be easy to force redrawing of fringes only, but I also trust Eli=E2=80=99s opinion on complexity of this task more than my impressions. While I=E2=80=99d like to have a function indicating that particular window= =E2=80=99s fringes need to be updated (maybe something like =E2=80=98(force-window-upd= ate window t)=E2=80=99, I won=E2=80=99t have time to work on this any time soon. > 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. I don=E2=80=99t think it=E2=80=99s that simple. Even if all you=E2=80=99re= changing is colour, you still need to redraw the text. At best, without anti-aliasing there may be some way to optimise it but I doubt complicating the code to support that would be worth it. --=20 Best regards =E3=83=9F=E3=83=8F=E3=82=A6 =E2=80=9C=F0=9D=93=B6=F0=9D=93=B2=F0=9D=93=B7= =F0=9D=93=AA86=E2=80=9D =E3=83=8A=E3=82=B6=E3=83=AC=E3=83=B4=E3=82=A4=E3=83= =84 =C2=ABIf at first you don=E2=80=99t succeed, give up skydiving=C2=BB From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 14:27:14 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 19:27:14 +0000 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 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 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==; Date: Thu, 02 Jan 2025 21:26:55 +0200 Message-Id: <86v7uxhv9c.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <87ttah2hcd.fsf@dancol.org> (message from Daniel Colascione on Thu, 02 Jan 2025 13:36:34 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 14:51:02 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 19:51:03 +0000 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 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==; 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 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <86v7uxhv9c.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2025 21:26:55 +0200") References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Thu, 02 Jan 2025 14:50:54 -0500 Message-ID: <87ikqx2dwh.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 02 15:57:11 2025 Received: (at 75291) by debbugs.gnu.org; 2 Jan 2025 20:57:11 +0000 Received: from localhost ([127.0.0.1]:46921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTSFi-0008Lp-NI for submit@debbugs.gnu.org; Thu, 02 Jan 2025 15:57:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41882) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTSFg-0008LV-7v for 75291@debbugs.gnu.org; Thu, 02 Jan 2025 15:57:09 -0500 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 1tTSFZ-0007eH-0s; Thu, 02 Jan 2025 15:57:01 -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=8LKDkuLHOqNJyT2Rh/xvEYbpifl62zLvHQ9nL9Zh5C4=; b=IcT2xNAg9plU n24qNf4g0oe32JPj07RHPaXapIM5J+Gvfwn9IBb+lZWm7RV944vN68/x34DkW4hWXDm6Xgn8ZZAT2 6fzf1W14mPJ3sWy4IaYfQnb5oexzleeiDACZv816YFSNXW1fPrWJlEXsw4hSZhjegTTOMMpEm8O/W 0O8NnwqS2j8z99JXJAfAGununB7GDJuIEqjCADlf6E9I2beZ7SBdmjTT1B6g8VSpeNAALgMgt0p69 KE9hi6c996CZOkp1J3Ik8s1OCzyqqsYzyPjnl6eT8iM4rUwyUrGBcHz+g4VUSB6bYgSraxFu1i5HT 5TkidgaxLcSga5alVXC73A==; Date: Thu, 02 Jan 2025 22:56:57 +0200 Message-Id: <86h66hhr3a.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <87ikqx2dwh.fsf@dancol.org> (message from Daniel Colascione on Thu, 02 Jan 2025 14:50:54 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Colascione > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Thu, 02 Jan 2025 14:50:54 -0500 > > Eli Zaretskii 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. > 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. > > 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. What does Lisp know about the fringe face that the display engine doesn't? > 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. First, the fringe face might not be window-specific (by default, it isn't). So I'm not sure how a window parameter will help. face-remapping-alist is per-buffer, not per-window. Next, the main problem with faces is face inheritance and face merging (the latter is not relevant to fringe, I think). Given that some attribute of some face changes, how do you know whether such a change causes the fringe face to change? We'd probably need to realize it anew, and then compare to the cached one? And we'd need to do that for each window, because of face-remapping-alist? > > 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. See above. I think the proof of the proverbial pudding is in eating: maybe doing the above will produce reasonable performance. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 12:25:14 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 17:25:14 +0000 Received: from localhost ([127.0.0.1]:51909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTlQ9-0004Gj-On for submit@debbugs.gnu.org; Fri, 03 Jan 2025 12:25:14 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56822) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTlQ4-0004DU-Uz for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 12:25:11 -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=DSJhAYxvE9sFDAYqTHeNvLweqeKb7pUXOHqKzA8ymnQ=; b=goyzDseDh1jKKjdChjqjsbEPzp MTiijH2GRnDhTSVvt0SH/U5rFcoBAPbCCa0WdAhCAS12G0hgVt1jxqwjQEQr1aI9doHiZI9XxiIRy UbOxrJm/Qof950Bn6SYfoKhEU6tjXh4sSd/tRbAh2U52Nvl/OQYDIlriMj6QvarVFhC5xsmEchqqm CmKDS6eLGbFpUsHxaOlkHmk2pxiyxN2h8KYqrR7Hha2w4/AKO3Nizqlpe7fIDaQSE/0/ZXwWuDRLa iumJGylSFjP7KpL9/PTOno+HQK6cExw+HlZbsfCFVIixDC097Wx4+HnYuftH1xZeNXWtFYEc/j9EA EGgoCCUQ==; Received: from [2600:1006:b1ae:67b6:fce2:e96c:5bed:428] (port=57718 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTlQ1-0006z4-2Q; Fri, 03 Jan 2025 12:25:05 -0500 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <86h66hhr3a.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 02 Jan 2025 22:56:57 +0200") References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Fri, 03 Jan 2025 12:25:05 -0500 Message-ID: <87ldvrajym.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com >> Date: Thu, 02 Jan 2025 14:50:54 -0500 >> >> Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 14:31:26 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 19:31:26 +0000 Received: from localhost ([127.0.0.1]:52173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTnOH-0003ws-Je for submit@debbugs.gnu.org; Fri, 03 Jan 2025 14:31:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42894) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTnOC-0003wM-P8 for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 14:31:23 -0500 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 1tTnO5-0005BK-5N; Fri, 03 Jan 2025 14:31:13 -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=mERhp9GUvLVBRKCjdUwzNT0vIOcyyB7MoL0/BzF5Bn8=; b=FVC9WEM4+RWS o9OLf02sVSbCwpEdDdvcE0skkBC2F5bqYxskH70YLmoGGFnzQEo2q40JGTzp+9Y1nSTMGoHQzD4LM 5naeTJAqCHyVGnUh6B5LYTVg57RnIkcEJFF8u6jbNWkV0Af/h0/+Zea7mNdODxwIrz2xPeeB4eR3m 8jhtQAvSlBunKeMiYgcmoQWsg2F3ddxcrsYjW9O0UK/7ul8PmlvdtSVA/NanNT9gtUrmaFVNZiT6E N+TRodXiwTE4rCkYYx3NWvBcNCvKfFAtVpr/3vXlUamtmxdv8j5lcBD1Pdymvg0+TqwWmBVzODsEF t//JkDrIGEBV0AgIe9awvw==; Date: Fri, 03 Jan 2025 21:31:10 +0200 Message-Id: <867c7bheyp.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <87ldvrajym.fsf@dancol.org> (message from Daniel Colascione on Fri, 03 Jan 2025 12:25:05 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Colascione > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Fri, 03 Jan 2025 12:25:05 -0500 > > > 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. People still report flickering from time to time, so I don't think this never happens. > > 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? Doesn't that only support face remapping with :filtered attribute? What about the more general case where the fringe face is remapped in a way that's independent of the windows? From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 14:46:29 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 19:46:29 +0000 Received: from localhost ([127.0.0.1]:52234 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTncr-0004y4-1S for submit@debbugs.gnu.org; Fri, 03 Jan 2025 14:46:29 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56376) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTncn-0004xZ-Pb for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 14:46:27 -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=/XgSUiLqqirWa5dh2YYN40DsLaZ/kI3hbU2vZvuCGqg=; b=h3eogWw+2N1gK6XFgfXK2QNhki C5by5eE/p8tu5eReW8735F8PlU7iqTyM/IPpAJO340+7unWZat8FsMD1o2vZ8WdjkOZH0fDDhVT4E 9T36jhbX4wnBql+c9UaMzMLUQ2P6qtoTn/7wTw5TikSk7KbW2GY/2pC6fWhgHms+P/26ghQu58594 q5sxHWn9NkR6qJt9qBnL6UPAQziblfgzJ12QUZTsY2zGxmHiUMZ2XHi6/Fawn9AAJ7T5FnB8YB9z1 po+KTrySbpOU6+DGJVbBZpGUzP9zUGt2CaIfGPizpK7wUZpmxDXUxAgM5Ox/zqmBEjcsg9m94quf5 ZzXvelvg==; Received: from syn-097-104-088-154.res.spectrum.com ([97.104.88.154]:41154 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTnck-0007dx-2h; Fri, 03 Jan 2025 14:46:23 -0500 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <867c7bheyp.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Jan 2025 21:31:10 +0200") References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Fri, 03 Jan 2025 14:46:20 -0500 Message-ID: <87sepz65pv.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com >> Date: Fri, 03 Jan 2025 12:25:05 -0500 >> >> > 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. > > People still report flickering from time to time, so I don't think > this never happens. > >> > 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? > > Doesn't that only support face remapping with :filtered attribute? > What about the more general case where the fringe face is remapped in > a way that's independent of the windows? That seems to work already. It's only in the fringe that I see problems --- it just doesn't seem worth it to limit the redraw to the fringe. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 15:11:15 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 20:11:15 +0000 Received: from localhost ([127.0.0.1]:52287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTo0p-0006a4-1y for submit@debbugs.gnu.org; Fri, 03 Jan 2025 15:11:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43002) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTo0m-0006Zn-P4 for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 15:11:13 -0500 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 1tTo0e-0003VT-WA; Fri, 03 Jan 2025 15:11: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=DkuT0dArQSmK+p2rJvKUS581CS+cCAJKY+/NC/IQjYU=; b=CXUvvuRgAf8t FzuLlp2eP8DKSvcQSP5w25LKYu8tTVpCbyXws3apRCFughu5wF8UAEwi9CEUwuLoMsSuUNiwdS8dp SVi0nSdrCCeZSPuQF/UyR0W06t7yrJTSOh1cM1fNTKMHxIy8m4HRug4t6y9eqFxH9Ric+z4g9wAZl lq9qm5gdy0hXgoWb9xaK5ePZLWezZ5mzi0RDzJfsOni/+z69ojVTWdgm+QKruNvpqF77mindRzCPs qUfnBdR2UdSpdtjs56u19NLvAZWp7jEXDwaVOOYdHPFxZyfPp1XB40963ePhVdQ0y3XbEcbTuboAr ubnRCwksXfTFAqsBONa97A==; Date: Fri, 03 Jan 2025 22:10:45 +0200 Message-Id: <86wmfbfyka.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <87sepz65pv.fsf@dancol.org> (message from Daniel Colascione on Fri, 03 Jan 2025 14:46:20 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> <87sepz65pv.fsf@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Colascione > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Fri, 03 Jan 2025 14:46:20 -0500 > > Eli Zaretskii writes: > > >> From: Daniel Colascione > >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com > >> Date: Fri, 03 Jan 2025 12:25:05 -0500 > >> > >> > 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. > > > > People still report flickering from time to time, so I don't think > > this never happens. > > > >> > 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? > > > > Doesn't that only support face remapping with :filtered attribute? > > What about the more general case where the fringe face is remapped in > > a way that's independent of the windows? > > That seems to work already. It's only in the fringe that I see problems > --- it just doesn't seem worth it to limit the redraw to the fringe. Sorry, I don't understand. I _was_ talking about the fringe face. But if redraw_frame solves the issue, and doesn't cause unpleasant or expensive redraws, feel free to install on the master branch. But please change this: + 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)); to say this instead: + if (SYMBOLP (parameter) && + WINDOW_LIVE_P (window) && + FRAME_WINDOW_P (WINDOW_XFRAME (w)) && + EQ (Fget (parameter, Qface_filter), Qt) && <<<<<<<<<<<<<<<<< + !EQ (CDR_SAFE (old_alist_elt), value)) + redraw_frame (WINDOW_XFRAME (w)); (A stylistic comment: our conventions is to put the && operator at the beginning of a line, not at the end of a line.) From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 15:27:59 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 20:27:59 +0000 Received: from localhost ([127.0.0.1]:52314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tToH1-0007dD-7Z for submit@debbugs.gnu.org; Fri, 03 Jan 2025 15:27:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54846) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tToGx-0007ck-Pv for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 15:27:57 -0500 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 1tToGq-0000d4-Jd; Fri, 03 Jan 2025 15:27:48 -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=6bmIcaF7ReTVW4sEVDlYtyC/gGgaELHmmP0pNX5ODiY=; b=bsqP5iYQgfrl 14Kj7+8aGYgBB8E6LDu619419MAawm0GvgLyvp5a6kOhB2LKEhRA6ZrSj8eYMn8OolBeJh5jOWgD0 tIWgv1UrMpf+WHeDyiLwrjtooseDu+9IqRh2FKn86SpRRq+16NXHmyxhKv6U0X3U5+CxbwFPh2QLX 8op+OmttTodFb9spfzP3URDhQZcHTKwFUWgwAG6QIuEgzGMdxPQQbX7lAqf70XhAPSsYFYPjXjdFR fQfQClz8sAthNUaQTNnAJkhacd2GIBsqGnrZeqfKzeYNjH49GJDaJCYi6sXGrUN9L7Zyq3IS2wnNy XOm4QG1ekqhRrzBBg1jrNA==; Date: Fri, 03 Jan 2025 22:27:45 +0200 Message-Id: <86ttaffxry.fsf@gnu.org> From: Eli Zaretskii To: dancol@dancol.org In-Reply-To: <86wmfbfyka.fsf@gnu.org> (message from Eli Zaretskii on Fri, 03 Jan 2025 22:10:45 +0200) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> <87sepz65pv.fsf@dancol.org> <86wmfbfyka.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Fri, 03 Jan 2025 22:10:45 +0200 > From: Eli Zaretskii > > > From: Daniel Colascione > > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > > Date: Fri, 03 Jan 2025 14:46:20 -0500 > > > > Eli Zaretskii writes: > > > > >> From: Daniel Colascione > > >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com > > >> Date: Fri, 03 Jan 2025 12:25:05 -0500 > > >> > > >> > 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. > > > > > > People still report flickering from time to time, so I don't think > > > this never happens. > > > > > >> > 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? > > > > > > Doesn't that only support face remapping with :filtered attribute? > > > What about the more general case where the fringe face is remapped in > > > a way that's independent of the windows? > > > > That seems to work already. It's only in the fringe that I see problems > > --- it just doesn't seem worth it to limit the redraw to the fringe. > > Sorry, I don't understand. I _was_ talking about the fringe face. > > But if redraw_frame solves the issue, and doesn't cause unpleasant or > expensive redraws, feel free to install on the master branch. But > please change this: Btw: this is _really_ a sledgehammer solution, and it will affect similar changes in any face, not just the fringe face. I wonder how long will it take for complaints to come in. How about leaving behind a variable exposed to Lisp that could be used to disable this sledgehammer? Then we at least could tell people who don't want this how to disable it. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 15:57:44 2025 Received: (at 75291) by debbugs.gnu.org; 3 Jan 2025 20:57:45 +0000 Received: from localhost ([127.0.0.1]:52396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTojo-00019e-DU for submit@debbugs.gnu.org; Fri, 03 Jan 2025 15:57:44 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:45560) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTojm-00019U-2i for 75291@debbugs.gnu.org; Fri, 03 Jan 2025 15:57:43 -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=aTZMJXVoJwp3sirHgn4PO4tWa1FmQaLa+3InRXMsvFA=; b=gfT7rn/4m+2J0JGwepEYC1WBM1 uhZveWrl71FxWPfUS8c1rpOrDbVHFwiEp7r0HiFkensYSkoGpX67OpiQCJnOtiyNo5B2OWDlXkHND SAP1h4KGtlbndXU1hjkYTM26JmP8D8XgBhC/3Rr6KYexqDUOKHDHqPEuNt4nXHDe9659f5IPREI2G KLKn2/DpWD9LimZk1nI89M3vIKqqs8TDkLuLUWNS1EIgEXw5uqjZCSPiUiZTyL3dokpETeGyTltU0 dQCs+aJ5txKU4YjKXVSY0tSZgErC8nACjaeOBbrapvm1PyIF9Ak3vKdPsUNxSFnyJ+EagFZQNvyPT iSTX5iJQ==; Received: from 2603-9001-4203-1ab2-f066-27df-9911-13c0.inf6.spectrum.com ([2603:9001:4203:1ab2:f066:27df:9911:13c0]:60688 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tTojj-0007t5-13; Fri, 03 Jan 2025 15:57:39 -0500 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes In-Reply-To: <86wmfbfyka.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 03 Jan 2025 22:10:45 +0200") References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> <87sepz65pv.fsf@dancol.org> <86wmfbfyka.fsf@gnu.org> User-Agent: mu4e 1.12.8; emacs 31.0.50 Date: Fri, 03 Jan 2025 15:57:37 -0500 Message-ID: <87msg762f2.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com >> Date: Fri, 03 Jan 2025 14:46:20 -0500 >> >> Eli Zaretskii writes: >> >> >> From: Daniel Colascione >> >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com >> >> Date: Fri, 03 Jan 2025 12:25:05 -0500 >> >> >> >> > 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. >> > >> > People still report flickering from time to time, so I don't think >> > this never happens. >> > >> >> > 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? >> > >> > Doesn't that only support face remapping with :filtered attribute? >> > What about the more general case where the fringe face is remapped in >> > a way that's independent of the windows? >> >> That seems to work already. It's only in the fringe that I see problems >> --- it just doesn't seem worth it to limit the redraw to the fringe. > > Sorry, I don't understand. I _was_ talking about the fringe face. I misread your question. To answer it: what are the circumstances in which the effective fringe face can change behind our backs? Any change to a face attribute proper will cause a redraw anyway. The face-remap.el functions call force-mode-line-update to make sure face remapping lists take effect, so we should have non-window-specific remapping changes covered. What's left is the window parameters. Any other cases? > But if redraw_frame solves the issue, and doesn't cause unpleasant or > expensive redraws, feel free to install on the master branch. But > please change this: > > + 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)); > > to say this instead: > > + if (SYMBOLP (parameter) && > + WINDOW_LIVE_P (window) && > + FRAME_WINDOW_P (WINDOW_XFRAME (w)) && > + EQ (Fget (parameter, Qface_filter), Qt) && <<<<<<<<<<<<<<<<< > + !EQ (CDR_SAFE (old_alist_elt), value)) > + redraw_frame (WINDOW_XFRAME (w)); > > (A stylistic comment: our conventions is to put the && operator at the > beginning of a line, not at the end of a line.) Thanks for the reminder! From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 02:12:18 2025 Received: (at 75291) by debbugs.gnu.org; 4 Jan 2025 07:12:18 +0000 Received: from localhost ([127.0.0.1]:53149 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTyKX-0007Mr-V5 for submit@debbugs.gnu.org; Sat, 04 Jan 2025 02:12:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40790) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTyKV-0007Md-4G for 75291@debbugs.gnu.org; Sat, 04 Jan 2025 02:12:16 -0500 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 1tTyKO-0002wv-GU; Sat, 04 Jan 2025 02:12:08 -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=n1tSXjDWe0x5hS4auE5FxLswAadXyS5Lg3ERf/eZbvg=; b=rvNeJAt/P/yh KWE+XkjhklGRygw55NXQ4a2RtPxK7oAKIo9Mka7NFxwuePVflll7gC5JxaGpDeCv7rdGvAT4hqAZv xYbpi3mn1fxRFb3xBFKjgvwxigi5SpzEYqCl6R/POoi5PtuvAR6vnL5Un4WGRPpDNAfNT7Ka8tn2I fR0vdTxV7yFmdiViyotzb4KML65/eOvLF/QAiFewyRZbTk2Otg6eQy8SoO9t29gg49zAGrTC/uS6x 0LXkgIXHm2iGnIkk8HvlYatOHgKz3MrMzXKMSOa4FbAnpJ7Q7lKTiyVos9cQzIzYzGHMKkLzHLltS pz9fuwOw8hf2Kme0/ETnoQ==; Date: Sat, 04 Jan 2025 09:12:05 +0200 Message-Id: <86pll3f3y2.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <87msg762f2.fsf@dancol.org> (message from Daniel Colascione on Fri, 03 Jan 2025 15:57:37 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> <87sepz65pv.fsf@dancol.org> <86wmfbfyka.fsf@gnu.org> <87msg762f2.fsf@dancol.org> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75291 Cc: 75291@debbugs.gnu.org, mina86@mina86.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Colascione > Cc: 75291@debbugs.gnu.org, mina86@mina86.com > Date: Fri, 03 Jan 2025 15:57:37 -0500 > > Eli Zaretskii writes: > > >> > Doesn't that only support face remapping with :filtered attribute? > >> > What about the more general case where the fringe face is remapped in > >> > a way that's independent of the windows? > >> > >> That seems to work already. It's only in the fringe that I see problems > >> --- it just doesn't seem worth it to limit the redraw to the fringe. > > > > Sorry, I don't understand. I _was_ talking about the fringe face. > > I misread your question. To answer it: what are the circumstances in > which the effective fringe face can change behind our backs? For example, face remapping via face-remapping-alist. > Any change to a face attribute proper will cause a redraw anyway. Changes in face attributes set the frame's redisplay flag, but that just tells the display engine to disable some radical optimizations, like considering only the selected window and only the line where the cursor is. AFAIU, this will not necessarily cause all the fringes of all the frame's windows to be redrawn, because we only redraw the fringes of the glyph rows that we consider changed. > The face-remap.el functions call force-mode-line-update to make sure > face remapping lists take effect force-mode-line-update sets a buffer-specific flag that disables some redisplay optimizations, but I don't think that guarantees redrawing of all the fringes of all the windows which show that buffer. So I'm not sure we have that covered. But if you have tested that and this actually work, fine; I don't pretend to know for sure this won't work. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 04:29:28 2025 Received: (at 75291-done) by debbugs.gnu.org; 18 Jan 2025 09:29:28 +0000 Received: from localhost ([127.0.0.1]:40176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tZ58x-0001OM-Lx for submit@debbugs.gnu.org; Sat, 18 Jan 2025 04:29:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45438) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tZ58v-0001O7-GA for 75291-done@debbugs.gnu.org; Sat, 18 Jan 2025 04:29:26 -0500 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 1tZ58p-0003Y6-VQ; Sat, 18 Jan 2025 04:29:19 -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=GNcO9VGqaixb+l3WjhRe5WL/89xeOaQLd5F6qL/2m3o=; b=X1SExcpCofyy +InNIqO3w+S/U9RdSe8lVCBHwQIwSCx3+TY6YunMOm84Dk74PGsgtb+Z0Ict4sl2GadKrDKPbeba6 EshY5PYG5aHNy09e9qVcO1bSLGiyU+GksAkmJopm40EHJkSEER4lUmKV3saQ1a6mDhh0nJj+/UKGN jkL8fpoFsYqZfJoFTp+J9S9DlbBtY5ZUIp+eH0YOcrFW7oginrmjd4BchkdsZ+D5N6D4duAeps/zJ oVA+musJogbLW3d00vcSI37i8a2O+skHPsFojYqsoHoiVR9RoNELCV+on2Pg+fGBtvhDA9vI333Ia MY8b9g4j9/ZY+HEGe+KZ+Q==; Date: Sat, 18 Jan 2025 11:29:16 +0200 Message-Id: <86wmesbhcj.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: (message from Daniel Colascione on Sat, 04 Jan 2025 15:24:43 -0500) Subject: Re: bug#75291: Redisplay not updating fringe when face filter changes References: <874j2h3yzb.fsf@dancol.org> <8634i1jeai.fsf@gnu.org> <87ttah2hcd.fsf@dancol.org> <86v7uxhv9c.fsf@gnu.org> <87ikqx2dwh.fsf@dancol.org> <86h66hhr3a.fsf@gnu.org> <87ldvrajym.fsf@dancol.org> <867c7bheyp.fsf@gnu.org> <87sepz65pv.fsf@dancol.org> <86wmfbfyka.fsf@gnu.org> <87msg762f2.fsf@dancol.org> <86pll3f3y2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75291-done Cc: 75291-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sat, 04 Jan 2025 15:24:43 -0500 > From: Daniel Colascione > > On January 4, 2025 2:12:05 AM EST, Eli Zaretskii wrote: > >> From: Daniel Colascione > >> Cc: 75291@debbugs.gnu.org, mina86@mina86.com > >> Date: Fri, 03 Jan 2025 15:57:37 -0500 > >> > >> Eli Zaretskii writes: > >> > >> >> > Doesn't that only support face remapping with :filtered attribute? > >> >> > What about the more general case where the fringe face is remapped in > >> >> > a way that's independent of the windows? > >> >> > >> >> That seems to work already. It's only in the fringe that I see problems > >> >> --- it just doesn't seem worth it to limit the redraw to the fringe. > >> > > >> > Sorry, I don't understand. I _was_ talking about the fringe face. > >> > >> I misread your question. To answer it: what are the circumstances in > >> which the effective fringe face can change behind our backs? > > > >For example, face remapping via face-remapping-alist. > > Directly, without going through face-remap? We already caution against that and should do so more > strongly. I don't think it's worth supporting direct modification of the alist. > > > > >> Any change to a face attribute proper will cause a redraw anyway. > > > >Changes in face attributes set the frame's redisplay flag, but that > >just tells the display engine to disable some radical optimizations, > >like considering only the selected window and only the line where the > >cursor is. AFAIU, this will not necessarily cause all the fringes of > >all the frame's windows to be redrawn, because we only redraw the > >fringes of the glyph rows that we consider changed. > > > >> The face-remap.el functions call force-mode-line-update to make sure > >> face remapping lists take effect > > > >force-mode-line-update sets a buffer-specific flag that disables some > >redisplay optimizations, but I don't think that guarantees redrawing > >of all the fringes of all the windows which show that buffer. > > Somehow, the basic case we have in face-remap seems to work already. I've put a change in master to > handle the window parameter filter case. Seems to work for me now without observable downsides. No extra > flickering. There's also a way to turn it off. No further comments, so I presume the bug is fixed, and I'm closing it. From unknown Sat Jun 21 03:25:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 15 Feb 2025 12:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator