From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.bugs Subject: bug#70637: :box vertical bar artifacts at 'display boundaries Date: Thu, 9 May 2024 09:31:28 -0400 Message-ID: References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@gmail.com> <867cggs8h9.fsf@gnu.org> <86y18wqpmk.fsf@gnu.org> <86o79sqj1r.fsf@gnu.org> <86r0eb77xq.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28009"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70637@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 09 15:33:02 2024 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 1s53tN-00071O-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 09 May 2024 15:33:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s53t1-0006Zb-LP; Thu, 09 May 2024 09:32:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s53sz-0006ZQ-QM for bug-gnu-emacs@gnu.org; Thu, 09 May 2024 09:32:38 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1s53sy-0001s3-Dq for bug-gnu-emacs@gnu.org; Thu, 09 May 2024 09:32:37 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s53tN-0002qq-Rj for bug-gnu-emacs@gnu.org; Thu, 09 May 2024 09:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: JD Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 May 2024 13:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70637 X-GNU-PR-Package: emacs Original-Received: via spool by 70637-submit@debbugs.gnu.org id=B70637.171526153810952 (code B ref 70637); Thu, 09 May 2024 13:33:01 +0000 Original-Received: (at 70637) by debbugs.gnu.org; 9 May 2024 13:32:18 +0000 Original-Received: from localhost ([127.0.0.1]:55292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s53sf-0002qa-L3 for submit@debbugs.gnu.org; Thu, 09 May 2024 09:32:18 -0400 Original-Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]:47315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s53sa-0002qS-8V for 70637@debbugs.gnu.org; Thu, 09 May 2024 09:32:16 -0400 Original-Received: by mail-io1-xd2f.google.com with SMTP id ca18e2360f4ac-7da3ec3e044so32903239f.2 for <70637@debbugs.gnu.org>; Thu, 09 May 2024 06:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715261500; x=1715866300; darn=debbugs.gnu.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=eTzxB2wrLyM/8Tgn09l9HAbG8ZqO6WW9vUHNMnMbc3g=; b=CPs1AJNUmpoFphBvvSdQ8GeH72zhMoDxF1n900S2guqRTCQmHfrgVkY7721+WEyqeo QYaBsgjF2b2Tj1mIFYclSc4XR3IQUY4guLA0RVqmR1L4zrWjba5YwhrYGXzFRJZfPBxC SbDHTjCiphv6zA3yNAijRBUEBFitp/Z+57GkJuFTqZ01mA1xhKTE/JKzVmhd9Jc50cPJ dHuJgId5vFzpbCKkzq6Vi00E25uuCx6/GvxH0+CeD3yOsEttksA/868+2l+1UoP1S9Ta 0/7ip0oug4keD9JyqEMIBD9Huf9DhCq9Mv1+A8uPwhwC4GL+kmHPo5jp5NY2xcZ6mWMP SrMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715261500; x=1715866300; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eTzxB2wrLyM/8Tgn09l9HAbG8ZqO6WW9vUHNMnMbc3g=; b=lP3T00xNRZF6Ks2lBGi199/9kRWUty+S9kHWG9TYK/YyedSqsIi+GzqqJmSayYcK++ 2MvytBwC5JqUETeWBp/CWZtfFwPEOFuO5+YzIpxO0KitOJcui6wLSpBIFfxr+DBQH9Sv /oILRyfb8SRExBDZAglYzg26WGT7ZRYaAAD2xeKbZi3mUMiXBA6LI44nVVFh+MUFiBqw C61pWQvZmhSXVspYHH28SksHN4fZk4mpeBmxENyxwdatP5Qi5TlDY2ZUMflQj10rwm5I Rnr21CW2deLveIEdPJsmmF/nfXQ3RxGwKdhLU15am+8/YxnMs31OoaJ/0W6wQp7Mn53G aEmw== X-Gm-Message-State: AOJu0YzqnYYfkHt3VplEOABq4mEUdDO/KEWVngDlUA1fXAHn53YqYDAo to9zVhY9H6hPuDwFlwTnPbwQIlKe0582UCbJrTBCQr7rdND3PHdMIECNlQ== X-Google-Smtp-Source: AGHT+IEFO25quNzuGrCt9ZOfy0QggueNCgkLO49gnTgsCz5igaY6pXbB0GXNWK52Wv3WGDWSnMReLA== X-Received: by 2002:a5e:8d0c:0:b0:7e1:8194:c27b with SMTP id ca18e2360f4ac-7e18fd5a719mr579537939f.10.1715261500270; Thu, 09 May 2024 06:31:40 -0700 (PDT) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-489376fc67csm359600173.175.2024.05.09.06.31.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 May 2024 06:31:39 -0700 (PDT) In-Reply-To: <86r0eb77xq.fsf@gnu.org> X-Mailer: Apple Mail (2.3774.500.171.1.1) 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:284754 Archived-At: --Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I presume this is a more general issue than just :box. One idea is to = add a warning to the Elisp section "Display Specs That Replace The = Text", perhaps at the end: Note: certain `face' attributes such as `:box' can lead to display = artifacts when applied to the replacing text in a `display' = specification. These attributes may be incorrectly merged with adjacent = non-`display' `face' properties. This can be mitigated by applying the = `face' attributes directly to the text being replaced, rather than (or = in addition to) the `display' replacement text itself. Maybe a bit too wordy. > On May 9, 2024, at 3:36=E2=80=AFAM, Eli Zaretskii = wrote: >=20 >> Cc: 70637@debbugs.gnu.org >> Date: Mon, 29 Apr 2024 18:34:40 +0300 >> From: Eli Zaretskii >>=20 >>> From: JD Smith >>> Date: Mon, 29 Apr 2024 11:19:52 -0400 >>> Cc: 70637@debbugs.gnu.org >>>=20 >>> This happens when the glyph under cursor has the beginning-of-box or >>> end-of-box flag set. When we display the entire stretch of = characters >>> on that line, we (correctly) don't pay attention to these flags in = the >>> middle of the glyph sequence, but redrawing the cursor draws just = one >>> glyph, and knows nothing about those before or after it. So it = draws >>> the unnecessary border, because the glyph under cursor has the flag >>> set. >>>=20 >>> Those box flags are set on the glyphs produced from the display >>> strings because when we process the beginning or end of the string, = we >>> don't have any idea whether the characters of the underlying buffer >>> text before/after the string have the same value of the :box face, = so >>> we cannot avoid setting these flags at the first and the last >>> character of the display string. >>>=20 >>>=20 >>> I see, makes sense. So the cursor blink code would also have to = "look ahead/behind" the underlying glyph to >>> know whether to ignore the flag. >>=20 >> It's not just to "look", it's actually to redraw. because the logic >> which determines whether we draw the borders lives in the code that >> draws the glyphs on the glass, and to DTRT it needs to be presented >> with a sequence of glyphs that begins before the one under cursor and >> ends after it. >>=20 >>> Probably this is such a rare case that unless there are other = related >>> artifacts, it's worth documenting but not fixing. >>=20 >> Suggestions for how to document this are welcome. >=20 > Ping! --Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I presume this = is a more general issue than just :box.  One idea is to add a = warning to the Elisp section "Display Specs That Replace The Text", = perhaps at the end:

Note: certain `face' attributes = such as `:box' can lead to display artifacts when applied to the = replacing text in a `display' specification.  These attributes may = be incorrectly merged with adjacent non-`display' `face' properties. =  This can be mitigated by applying the `face' attributes directly = to the text being replaced, rather than (or in addition to) = the `display' replacement text = itself.

Maybe a bit too = wordy.

On May 9, 2024, = at 3:36=E2=80=AFAM, Eli Zaretskii <eliz@gnu.org> wrote:

Cc: 70637@debbugs.gnu.org
Date: Mon, 29 Apr 2024 = 18:34:40 +0300
From: Eli Zaretskii = <eliz@gnu.org>

From: JD Smith = <jdtsmith@gmail.com>
Date: Mon, 29 Apr 2024 11:19:52 = -0400
Cc: 70637@debbugs.gnu.org

This happens when the glyph = under cursor has the beginning-of-box or
end-of-box flag set. =  When we display the entire stretch of characters
on that line, = we (correctly) don't pay attention to these flags in the
middle of = the glyph sequence, but redrawing the cursor draws just one
glyph, = and knows nothing about those before or after it.  So it draws
= the unnecessary border, because the glyph under cursor has the flag
= set.

Those box flags are set on the glyphs produced from the = display
strings because when we process the beginning or end of the = string, we
don't have any idea whether the characters of the = underlying buffer
text before/after the string have the same value = of the :box face, so
we cannot avoid setting these flags at the = first and the last
character of the display string.


I = see, makes sense.  So the cursor blink code would also have to = "look ahead/behind" the underlying glyph to
know whether to ignore = the flag.

It's not just to "look", it's actually to = redraw.  because the logic
which determines whether we draw the = borders lives in the code that
draws the glyphs on the glass, and to = DTRT it needs to be presented
with a sequence of glyphs that begins = before the one under cursor and
ends after it.

Probably this is such a rare case that unless there are = other related
artifacts, it's worth documenting but not = fixing.

Suggestions for how to document this are = welcome.

Ping!

<= /div>= --Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB--