Received: (at 70637) by debbugs.gnu.org; 11 May 2024 09:42:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat May 11 05:42:03 2024 Received: from localhost ([127.0.0.1]:47342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s5jEw-0007L3-Kb for submit <at> debbugs.gnu.org; Sat, 11 May 2024 05:42:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s5jEu-0007Kf-Vk for 70637 <at> debbugs.gnu.org; Sat, 11 May 2024 05:42:01 -0400 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 <eliz@HIDDEN>) id 1s5jEq-0003Wz-FQ; Sat, 11 May 2024 05:41:56 -0400 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=mj+2uP2cvZrZaZANcnWsgstLyVzUrbGfGXi+WfDKvxo=; b=f/ayoQqVx7Z2 CfbKDyk1WbovW4YW7tG1czYEN9CZnW/uxJsL00zP8Iw5jft1wLSQgnZkOC0n5rFQP8aPn9YKwNwRz /vo2j44+9zZ+NewEfLt257GJOehcxuKtj6F/5tySIqD7kyi8PrIlvv0E9WSUenqmcaytqyw2Y6qke 4MgYWXV97NMt23hTJRG2DgdeW8rvApGXvV8Ft9kGA4Kmgm/GUnLT9Quw8doWThN2KOmrF3pZRdrzG 4Tv0vgS7cXXEblqYMjRqtGccvqSc8SkHKq6YR++H8+XTypwMlVsSBrQ4gDoPV6vGy6IqKOSeIgRuo B9Wzt8itsVmCbZwzd3etLA==; Date: Sat, 11 May 2024 12:41:52 +0300 Message-Id: <86cyps3ctb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <E38688B6-F36C-4285-93DA-D861FB6EBB11@HIDDEN> (message from JD Smith on Thu, 9 May 2024 09:31:28 -0400) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> <86y18wqpmk.fsf@HIDDEN> <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> <86o79sqj1r.fsf@HIDDEN> <86r0eb77xq.fsf@HIDDEN> <E38688B6-F36C-4285-93DA-D861FB6EBB11@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: JD Smith <jdtsmith@HIDDEN> > Date: Thu, 9 May 2024 09:31:28 -0400 > Cc: 70637 <at> debbugs.gnu.org > > 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. Actually, this is specific to :box, since only for that attribute we need to determine the beginning and the end of the box. > Maybe a bit too wordy. Yes, I agree. If you can reword it to be specific to :box and to include an example, I think it would be good. Thanks.
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 9 May 2024 13:32:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 09 09:32:18 2024 Received: from localhost ([127.0.0.1]:55292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s53sf-0002qa-L3 for submit <at> debbugs.gnu.org; Thu, 09 May 2024 09:32:18 -0400 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 <jdtsmith@HIDDEN>) id 1s53sa-0002qS-8V for 70637 <at> debbugs.gnu.org; Thu, 09 May 2024 09:32:16 -0400 Received: by mail-io1-xd2f.google.com with SMTP id ca18e2360f4ac-7da3ec3e044so32903239f.2 for <70637 <at> 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) 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) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <E38688B6-F36C-4285-93DA-D861FB6EBB11@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries Date: Thu, 9 May 2024 09:31:28 -0400 In-Reply-To: <86r0eb77xq.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> <86y18wqpmk.fsf@HIDDEN> <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> <86o79sqj1r.fsf@HIDDEN> <86r0eb77xq.fsf@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --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 <eliz@HIDDEN> = wrote: >=20 >> Cc: 70637 <at> debbugs.gnu.org >> Date: Mon, 29 Apr 2024 18:34:40 +0300 >> From: Eli Zaretskii <eliz@HIDDEN> >>=20 >>> From: JD Smith <jdtsmith@HIDDEN> >>> Date: Mon, 29 Apr 2024 11:19:52 -0400 >>> Cc: 70637 <at> 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 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">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:<div><br></div><blockquote style=3D"margin: 0 0 0 = 40px; border: none; padding: 0px;"><div>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 <span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">`display' </span>replacement text = itself.</div><div><br></div></blockquote>Maybe a bit too = wordy.<br><div><div><br><blockquote type=3D"cite"><div>On May 9, 2024, = at 3:36=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div><blockquote = type=3D"cite">Cc: 70637 <at> debbugs.gnu.org<br>Date: Mon, 29 Apr 2024 = 18:34:40 +0300<br>From: Eli Zaretskii = <eliz@HIDDEN><br><br><blockquote type=3D"cite">From: JD Smith = <jdtsmith@HIDDEN><br>Date: Mon, 29 Apr 2024 11:19:52 = -0400<br>Cc: 70637 <at> debbugs.gnu.org<br><br> This happens when the glyph = under cursor has the beginning-of-box or<br> end-of-box flag set. = When we display the entire stretch of characters<br> on that line, = we (correctly) don't pay attention to these flags in the<br> middle of = the glyph sequence, but redrawing the cursor draws just one<br> glyph, = and knows nothing about those before or after it. So it draws<br> = the unnecessary border, because the glyph under cursor has the flag<br> = set.<br><br> Those box flags are set on the glyphs produced from the = display<br> strings because when we process the beginning or end of the = string, we<br> don't have any idea whether the characters of the = underlying buffer<br> text before/after the string have the same value = of the :box face, so<br> we cannot avoid setting these flags at the = first and the last<br> character of the display string.<br><br><br>I = see, makes sense. So the cursor blink code would also have to = "look ahead/behind" the underlying glyph to<br>know whether to ignore = the flag.<br></blockquote><br>It's not just to "look", it's actually to = redraw. because the logic<br>which determines whether we draw the = borders lives in the code that<br>draws the glyphs on the glass, and to = DTRT it needs to be presented<br>with a sequence of glyphs that begins = before the one under cursor and<br>ends after it.<br><br><blockquote = type=3D"cite">Probably this is such a rare case that unless there are = other related<br>artifacts, it's worth documenting but not = fixing.<br></blockquote><br>Suggestions for how to document this are = welcome.<br></blockquote><br>Ping!<br></div></div></blockquote></div><br><= /div></body></html>= --Apple-Mail=_FD8F2103-70E3-49C1-B72C-33C980AA0EBB--
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 9 May 2024 07:37:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 09 03:37:24 2024 Received: from localhost ([127.0.0.1]:53695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s4yLE-0001cd-3c for submit <at> debbugs.gnu.org; Thu, 09 May 2024 03:37:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s4yLC-0001cX-ND for 70637 <at> debbugs.gnu.org; Thu, 09 May 2024 03:37:23 -0400 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 <eliz@HIDDEN>) id 1s4yKh-0003im-6c; Thu, 09 May 2024 03:36:51 -0400 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=yFjp4aV8dtkVRcCXdRG3nJLDmPknghjtX20ntlF4kXY=; b=MlEZ3nlCYTLQ jtGZyQvujZGUN+Fsho0YHnRiQBXPzwmwa44ep29wx5ntABgPu/Y1K//AqzifHkLZpcpifQWjBSfQY 9zPVssgc14NvRkmcuicbEOhKkmgmxz/WYTkYrTMg5xUx0u9WYFZbd3ooXkJLO0SAMfNryALHYoFlj /mwUK50np6MNDG/pbIBOCXEhDZp0u7cj+5oJb4w/BCnhLmBtdimoBTE0Vgdpb2tAZNQGHS3/89hPy eHvPtb6HMQWFxfjmupIssoi2mpvGDsgsWMyyyT/tykvjYEBoYevZh0QoWofhI0JvXwSfSSOjm5//5 95+uM3nW8wilRchkXfrL+g==; Date: Thu, 09 May 2024 10:36:49 +0300 Message-Id: <86r0eb77xq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: jdtsmith@HIDDEN In-Reply-To: <86o79sqj1r.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 29 Apr 2024 18:34:40 +0300) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> <86y18wqpmk.fsf@HIDDEN> <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> <86o79sqj1r.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 70637 <at> debbugs.gnu.org > Date: Mon, 29 Apr 2024 18:34:40 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: JD Smith <jdtsmith@HIDDEN> > > Date: Mon, 29 Apr 2024 11:19:52 -0400 > > Cc: 70637 <at> 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!
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 29 Apr 2024 15:35:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 29 11:35:13 2024 Received: from localhost ([127.0.0.1]:57861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1T28-0004G9-N9 for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 11:35:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s1T24-0004G3-BP for 70637 <at> debbugs.gnu.org; Mon, 29 Apr 2024 11:35:11 -0400 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 <eliz@HIDDEN>) id 1s1T1e-0000Dg-WC; Mon, 29 Apr 2024 11:34:43 -0400 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=OeNCXKGao1xaxtt88fcXJPRpfGinxJd7YrkhdK5EPF4=; b=qjPzrCuD8JAR zXf2scxwin0dj4X5p6LBbnAS7llJdzOqlhsiK0R3NZ8iC0nSx90MVfOEueP8Hch6SRgB7o6ZaRb8R /LJgAdegVo45CX/xQ8zYioISfQkCWKe1kMxQT8I0obwUbz+p7zneEwnatX/fRvevRrTlLJj1S1XT5 5VYvJ21qSi2Xr9O9bYB8+qWxqpjC0EWudEJGgBcNxddZ7fZddVkxFH5bzbD0DfD0SfOkyxcBieTML wqEhZWc3sIrp7DiqW8V4MukoTK4UFevIjDbxqiH+cFZWty42lPLPs31GsFXHcfUTmdEezwNi6SL7G Ww0WA/+vM05aVV8FOo2sFw==; Date: Mon, 29 Apr 2024 18:34:40 +0300 Message-Id: <86o79sqj1r.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> (message from JD Smith on Mon, 29 Apr 2024 11:19:52 -0400) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> <86y18wqpmk.fsf@HIDDEN> <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: JD Smith <jdtsmith@HIDDEN> > Date: Mon, 29 Apr 2024 11:19:52 -0400 > Cc: 70637 <at> 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.
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 29 Apr 2024 15:20:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 29 11:20:34 2024 Received: from localhost ([127.0.0.1]:57762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1Sny-00045P-2e for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 11:20:34 -0400 Received: from mail-il1-x12e.google.com ([2607:f8b0:4864:20::12e]:49245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1s1Snu-00045F-D7 for 70637 <at> debbugs.gnu.org; Mon, 29 Apr 2024 11:20:32 -0400 Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-36c16ed12bdso18175135ab.2 for <70637 <at> debbugs.gnu.org>; Mon, 29 Apr 2024 08:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714404004; x=1715008804; 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=+sqNYCxdae9Ez+5VJgmkJ5/N0dx1Ptgi5YeVrUA5q5c=; b=mfA8HMUHCoYK4W1rW5iS62ioc/1Y9xEXyg5YqmRNphsQwGfcmesDKYdCxc75WiBEnP ZBKS4XbJKLh2LozEJeNI/wwNSLPgYJmmY18sIAhnuHxOaMGnqwfH/o3yff7hXVYVkecp 2+Za4oN5YBzjFh3g6ftWwROVnvwkiiHNlgrhxIS7WUFq1XMUHcBkcpWHx0atLknh3jxG 5ZHjRFc5zJrLr0Pc3rBcOZbHk+x43uQQ6Hr+VIueivqO1ajNlB08f5yvKuTHtYYUsjJe 61Odrmb9egc8gXXd6JT7Gr/fs7m5PNz/tQRvykm0JzgfGa5Eq3VuWMihyU8+817UhQ5H Hzgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714404004; x=1715008804; 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=+sqNYCxdae9Ez+5VJgmkJ5/N0dx1Ptgi5YeVrUA5q5c=; b=w9xKN3wygUoJ4xpbNiSyEXa/giQBpuq7ZTclK/GBdSqoxYAx/CEbps+GRRPgv7Qbv6 8RJEENXEik4rxs4azdVkPDTo86fkkrfvcu9lFNd0ULf3GE2Xd1gFt6aYUz8aUU3+xxYW xnNrYwl8IjF+w/gMfrmrJdSgH4YmClFGp4VywUEEfti8XWJOOgGQ80kRsSJuYYvbnFwb 04vBdCCHgE3CzIrgJQLt90pDYngEmB4urF9DR21exHhlRkNkB14k2hU3uf9ZJh5LE1sK zRQNJiH+Q8zmcLJkRjeKe2sQlIdIXSmOILz1X8mvyww9lWeTHvLqd08KGtgcI5MSDj8u rDhA== X-Gm-Message-State: AOJu0Yz3tv3MdKCW4Dh+6wr5pt+P3hZm1qJCjb1JND20TXR8AcpGlu8C pjGkeZEbXl9y6Q4CaLubOoRaxoG3iahneZbrNAEkj9/1huudS65+UOl1/Q== X-Google-Smtp-Source: AGHT+IFt18301dMVHP/g6sNbh9snjhGAo1XrzteIQoeottorDqLbR4Do/UAPshI7Pw01jKF30ENW+A== X-Received: by 2002:a05:6e02:1d87:b0:36c:5023:2367 with SMTP id h7-20020a056e021d8700b0036c50232367mr74393ila.11.1714404004445; Mon, 29 Apr 2024 08:20:04 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id b17-20020a92db11000000b003698fc3a541sm5210017iln.80.2024.04.29.08.20.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2024 08:20:03 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Message-Id: <BF753F9C-6DF4-4302-9EB6-3F05467BD54D@HIDDEN> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9565B41-69D3-483B-BE83-3910EE69C41C" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries Date: Mon, 29 Apr 2024 11:19:52 -0400 In-Reply-To: <86y18wqpmk.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> <86y18wqpmk.fsf@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --Apple-Mail=_A9565B41-69D3-483B-BE83-3910EE69C41C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 29, 2024, at 9:12=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> = wrote: >=20 >> From: JD Smith <jdtsmith@HIDDEN> >>=20 >> The workaround may be enough for most cases, unless you can't apply = an overall 'face for some reason. >=20 > Why would we be unable to apply the box face on characters that are > not actually shown? I guess I should rephrase to "if it's inconvenient to apply an overall = face with :box", e.g. if you're adding on the output of another package. = There's also of course the need to discover the workaround. >> Any sense why it leaves the vertical bars behind? >=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 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. = Probably this is such a rare case that unless there are other related = artifacts, it's worth documenting but not fixing.= --Apple-Mail=_A9565B41-69D3-483B-BE83-3910EE69C41C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;"><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Apr 29, 2024, at 9:12=E2=80=AFAM, Eli Zaretskii = <eliz@HIDDEN> wrote:</div><br = class=3D"Apple-interchange-newline"><div><meta = charset=3D"UTF-8"><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">From: JD Smith = <jdtsmith@HIDDEN><br><br>The workaround may be enough for most = cases, unless you can't apply an overall 'face for some = reason.<br></blockquote><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">Why = would we be unable to apply the box face on characters that = are</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">not actually = shown?</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"></div></blockquote><div><br></div><div>I guess I should rephrase = to "if it's inconvenient to apply an overall face with :box", e.g. if = you're adding on the output of another package. There's also of = course the need to discover the workaround.</div><br><blockquote = type=3D"cite"><div><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;">Any sense why it leaves the vertical bars = behind?<br></blockquote><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">This = happens when the glyph under cursor has the beginning-of-box = or</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">end-of-box flag set. = When we display the entire stretch of characters</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">on that line, we (correctly) don't pay = attention to these flags in the</span><br style=3D"caret-color: rgb(0, = 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">middle = of the glyph sequence, but redrawing the cursor draws just one</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">glyph, and knows nothing about those before = or after it. So it draws</span><br style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">the = unnecessary border, because the glyph under cursor has the = flag</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">set.</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">Those box flags are set on the glyphs = produced from the display</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">strings = because when we process the beginning or end of the string, we</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;">don't have any idea whether the characters = of the underlying buffer</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;">text = before/after the string have the same value of the :box face, = so</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;"><span style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none; float: none; display: inline !important;">we cannot avoid setting = these flags at the first and the last</span><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: 400; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;"><span style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline = !important;">character of the display = string.</span></div></blockquote></div> <div>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. Probably = this is such a rare case that unless there are other related artifacts, = it's worth documenting but not fixing.</div></body></html>= --Apple-Mail=_A9565B41-69D3-483B-BE83-3910EE69C41C--
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 29 Apr 2024 13:13:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 29 09:13:10 2024 Received: from localhost ([127.0.0.1]:57204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1Qog-0002QY-84 for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 09:13:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s1Qob-0002QB-EA for 70637 <at> debbugs.gnu.org; Mon, 29 Apr 2024 09:13:08 -0400 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 <eliz@HIDDEN>) id 1s1QoB-00031M-W9; Mon, 29 Apr 2024 09:12:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Dynnigrn8HiT0imaMWVpn44JEa4754T+H4LerEb45Y4=; b=aisFYNotsxmIrfz/6Gba +6szS6dgNmesEWnZbpJKf59WhCbHNJytFiAuQ0XkcjNfb9pklmoZbW5vZLx4x3s7jnSt/M5Sohtv7 YB78po3TpRbPskMY09kklI1G4H8hVFFFbdyVsmN5d/I1K0ANL0LfkPXILUlYZNS7OaTnwmtgyhcNW IEtYuN0+Wm7OmjUF+fG2CzfRO75aFE02Vx41Xva5NZKks820vy+KpPvRZV/H+cdzo9zk/Q5oAoUox ezjlrhiIg2l01ruRxljr/GMYyT2FBXFcLTPn7l1gmUV42CZH6Y6Zki6PFtPL2YFvtc2O4j+DsP5fj BMJQqkQtLTfMQw==; Date: Mon, 29 Apr 2024 16:12:35 +0300 Message-Id: <86y18wqpmk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> (message from JD Smith on Mon, 29 Apr 2024 08:01:09 -0400) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: JD Smith <jdtsmith@HIDDEN> > Date: Mon, 29 Apr 2024 08:01:09 -0400 > Cc: 70637 <at> debbugs.gnu.org > > > > > On Apr 29, 2024, at 7:40 AM, Eli Zaretskii <eliz@HIDDEN> wrote: > > > >> From: JD Smith <jdtsmith@HIDDEN> > >> Date: Sun, 28 Apr 2024 20:50:31 -0400 > >> > >> > >> I have identified a display bug related to placing :box face parameters within 'display strings. Disable font-lock mode in *scratch* and evaluate: > >> > >> (insert "\n" > >> (propertize " " 'display (propertize " " 'face '(:box t))) > >> (propertize "middle" 'face '(:box t)) > >> (propertize " " 'display (propertize " " 'face '(:box t)))) > >> > >> So far so good: the box is correctly merged across all three elements and wraps around them. But now move point within and across the displayed boxed text. Internal vertical divisions bars separating the 'display and normal :box regions appear. > >> > >> If you add a face box property to the blank flanking strings as well, this prevents the internal boundary from appearing. > > > > How important is it to fix this use case (as opposed to using the > > workaround you describe in the last sentence)? The price for fixing > > it would be that we will need to redraw more than the single glyph > > below the cursor when showing the cursor (which with the default > > blink-cursor-mode happens twice a second), which will cause flickering > > around the cursor, and I wonder whether it's justified? > > The workaround may be enough for most cases, unless you can't apply an overall 'face for some reason. Why would we be unable to apply the box face on characters that are not actually shown? > Any sense why it leaves the vertical bars behind? 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.
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 29 Apr 2024 12:01:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 29 08:01:49 2024 Received: from localhost ([127.0.0.1]:56869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1Phd-0001hf-5i for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 08:01:49 -0400 Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]:56573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1s1Phb-0001hX-Jc for 70637 <at> debbugs.gnu.org; Mon, 29 Apr 2024 08:01:48 -0400 Received: by mail-il1-x134.google.com with SMTP id e9e14a558f8ab-36a1b0777b7so17537305ab.0 for <70637 <at> debbugs.gnu.org>; Mon, 29 Apr 2024 05:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714392082; x=1714996882; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=3MdNvRqrEFp49mOk4+aS74xZOmbE9PlfPQkIHThtXOU=; b=afBqYoQWANhMIO69xVz0uvuMCJAbPFALGeJW7Erd5x+Nej4QtDDECNJTQjLsowE9yn 3PcKAfXmMrLl+8ok8+Yxj7Ad6E6k0onHqwoB7x61kUiOd0OUOu2G9KlKU39ggh27baBI wd8U4EKNwm2vUBBVxJ0W1cE/P6DclVquMMt+R4mY2qX0EBdvNT6KCriU4PH0mXztjnZ6 yQ4liWmKnlDPc3JlbtgFMpD+iHlWecAfpAk+whQ1U+VFQknToKalZ/hF6OfuQKWHEcXN A8fe1dplQCGOVyCIiq+fOgzyFC3UnPu2rmlRuKakXqApVsA4jp8s/1NLGrKL8bLaaDv7 1gsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714392082; x=1714996882; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3MdNvRqrEFp49mOk4+aS74xZOmbE9PlfPQkIHThtXOU=; b=f6R5jBIprTx+AhHFnOHPpkTpvPdn/0XXfdn/hwHP6IxluUeySwGmdkOkSQ5oOXaRt+ WHA5TBvXBL96geVAqKCiXIMihQ+3pSOsXmnI2e0Y0yK0Sy+RnAKp9hLvRFSkmRQ+/zTG WwJOzNdrcocr5kZKoqhpsEBPiZXuvdE+QuFG1dq7xmWa4TswFPKN+PoDXAbHct3faGHy s8Vz3Q3X7b2GMsCDKJ8lS1Fp6SCwULFxAMdbNRS3JDXUL/U3tlc9OHkHdV+rOkuJsSXd x9Bj3Q2py5E2GOk6Z90SJyGBG4LURKm3Z2AScrl6TSbjBUcKyslI0E9WckkE2qX40yVK wQIw== X-Gm-Message-State: AOJu0Yw3FGuVYPGZKa/68TCS+lLM6i/reeHemMZTt2GX3P1lC3JdhnzY rYkw6IOO/CbuVNcTe1Ff9RsrQql2sp0cqE8SrSa7Cdb/YUkQOyx0 X-Google-Smtp-Source: AGHT+IFIZujGIdp9o3Km3GHRCRx5j+MfE6gU8Msi5fwfwLcZ9XiaPHd8igO5/AWB0Vd/pmLlEbDSGg== X-Received: by 2002:a05:6e02:1a88:b0:36b:f8:e884 with SMTP id k8-20020a056e021a8800b0036b00f8e884mr13145495ilv.20.1714392081560; Mon, 29 Apr 2024 05:01:21 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id n10-20020a056e02148a00b0036c50c7dc80sm332128ilk.40.2024.04.29.05.01.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Apr 2024 05:01:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries From: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <867cggs8h9.fsf@HIDDEN> Date: Mon, 29 Apr 2024 08:01:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <CB352F21-99FB-45E1-858F-C3401E207C91@HIDDEN> References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> <867cggs8h9.fsf@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> X-Mailer: Apple Mail (2.3774.500.171.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > On Apr 29, 2024, at 7:40=E2=80=AFAM, Eli Zaretskii <eliz@HIDDEN> = wrote: >=20 >> From: JD Smith <jdtsmith@HIDDEN> >> Date: Sun, 28 Apr 2024 20:50:31 -0400 >>=20 >>=20 >> I have identified a display bug related to placing :box face = parameters within 'display strings. Disable font-lock mode in *scratch* = and evaluate: >>=20 >> (insert "\n" >> (propertize " " 'display (propertize " " 'face '(:box t))) >> (propertize "middle" 'face '(:box t)) >> (propertize " " 'display (propertize " " 'face '(:box t)))) >>=20 >> So far so good: the box is correctly merged across all three elements = and wraps around them. But now move point within and across the = displayed boxed text. Internal vertical divisions bars separating the = 'display and normal :box regions appear. =20 >>=20 >> If you add a face box property to the blank flanking strings as well, = this prevents the internal boundary from appearing. >=20 > How important is it to fix this use case (as opposed to using the > workaround you describe in the last sentence)? The price for fixing > it would be that we will need to redraw more than the single glyph > below the cursor when showing the cursor (which with the default > blink-cursor-mode happens twice a second), which will cause flickering > around the cursor, and I wonder whether it's justified? The workaround may be enough for most cases, unless you can't apply an = overall 'face for some reason. Any sense why it leaves the vertical = bars behind?
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at 70637) by debbugs.gnu.org; 29 Apr 2024 11:40:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 29 07:40:37 2024 Received: from localhost ([127.0.0.1]:56762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1PN6-0001Lw-Q8 for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 07:40:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1s1PN4-0001Ll-F1 for 70637 <at> debbugs.gnu.org; Mon, 29 Apr 2024 07:40:35 -0400 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 <eliz@HIDDEN>) id 1s1PMe-0007fm-Od; Mon, 29 Apr 2024 07:40:08 -0400 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=/fhHtXfC0n3Q7YlkI+4z/T91wXZgfES/55W8rokLPA0=; b=nZJFOT5Ko/DZ lhxQcRBS25qWSXweQeCMPXJLJtxX2J9e83Ly/z+ToPK7/Jl5OXZIO23fzILSHItVhNMa766Ux21SL 3Q+aQjkxfqhFaih+pjRUtGlhRtEBABehOd5q5I27caXpNAzqB95nhg/fQWjTjTfzYOVQ4f+OouA/F QR3goIh8J1YhWlEKsYzrzpYYWG/oKPiyyyXcqknXwyQ75QbspqPwU5KSzYqk2Vpmu9B2lgOaPPtHn NHYlkgYwaAEcpx6f+UWnZHY2b8pUM97A4ekjkPQQldSJw5ShAmqIhx32S08u17VZolRBSMoxEvf+a JF6gLn2Gh246/uJNfgVz9g==; Date: Mon, 29 Apr 2024 14:40:02 +0300 Message-Id: <867cggs8h9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: JD Smith <jdtsmith@HIDDEN> In-Reply-To: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> (message from JD Smith on Sun, 28 Apr 2024 20:50:31 -0400) Subject: Re: bug#70637: :box vertical bar artifacts at 'display boundaries References: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 70637 Cc: 70637 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: JD Smith <jdtsmith@HIDDEN> > Date: Sun, 28 Apr 2024 20:50:31 -0400 > > > I have identified a display bug related to placing :box face parameters within 'display strings. Disable font-lock mode in *scratch* and evaluate: > > (insert "\n" > (propertize " " 'display (propertize " " 'face '(:box t))) > (propertize "middle" 'face '(:box t)) > (propertize " " 'display (propertize " " 'face '(:box t)))) > > So far so good: the box is correctly merged across all three elements and wraps around them. But now move point within and across the displayed boxed text. Internal vertical divisions bars separating the 'display and normal :box regions appear. > > If you add a face box property to the blank flanking strings as well, this prevents the internal boundary from appearing. How important is it to fix this use case (as opposed to using the workaround you describe in the last sentence)? The price for fixing it would be that we will need to redraw more than the single glyph below the cursor when showing the cursor (which with the default blink-cursor-mode happens twice a second), which will cause flickering around the cursor, and I wonder whether it's justified?
bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 29 Apr 2024 00:51:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 28 20:51:15 2024 Received: from localhost ([127.0.0.1]:53816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1s1FEh-0007Tu-AW for submit <at> debbugs.gnu.org; Sun, 28 Apr 2024 20:51:15 -0400 Received: from lists.gnu.org ([2001:470:142::17]:35632) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <jdtsmith@HIDDEN>) id 1s1FEf-0007To-Gp for submit <at> debbugs.gnu.org; Sun, 28 Apr 2024 20:51:13 -0400 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 <jdtsmith@HIDDEN>) id 1s1FEG-0003Ut-4T for bug-gnu-emacs@HIDDEN; Sun, 28 Apr 2024 20:50:48 -0400 Received: from mail-io1-xd2d.google.com ([2607:f8b0:4864:20::d2d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <jdtsmith@HIDDEN>) id 1s1FEE-0004Xv-Mh for bug-gnu-emacs@HIDDEN; Sun, 28 Apr 2024 20:50:47 -0400 Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-7decef0e157so14321439f.1 for <bug-gnu-emacs@HIDDEN>; Sun, 28 Apr 2024 17:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714351844; x=1714956644; darn=gnu.org; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:from:to:cc:subject:date:message-id:reply-to; bh=+BihIfnT2stjkqqenZMBt1F1Hz6JPA9eAKaKwVqN0s4=; b=RYHmHTAM3+dB1Vkv/qaFjHevBoo0BcPqHVuUGROBAyY/n901WrWCJy3KGHmoUviI7X 7sUtIywEDBGte9j+NyEZDlPr5OKVnxHfK8qTH3oXurNWhrKmB5bewmO5Q2fUUbrbG8yI 1GMTuB46xelUAZHU291j4eSlV9YvvU1gMbSOlQkMqSp6jo0MrqHGWYQAo6UoWkwcBqKc sMinAkv2syGf3c4j3lTOKFhpFb6L6yBCl00AzMGplQbM6RkEfXchHCzZs8kDejphNpBR gVYxf6hNWxR1nLl+zrbzB7Pyya4YPMzjOmEvomdfSP+68OMi2IfbzSzxSTtuapeuKiKG x1BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714351844; x=1714956644; h=to:date:message-id:subject:mime-version:content-transfer-encoding :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+BihIfnT2stjkqqenZMBt1F1Hz6JPA9eAKaKwVqN0s4=; b=Ux2XkkoWpumhHlbmR1brfUg8+VcjzTru6eoK65BN9iINQ6BHdinU78hQJm7tCAoqL9 0bhgdDUIv/VTEjA6G9H+7vqFJEXzfcITNAipOpDy29b0i/GHvo5bTrmRkJlW54Qf8W6h M5EHJlR8lnIjxGL0WzHB/dl/U61xyMPwUKjlEqmpXHkGzeoGj4b2CLx4Bz8JbAq3PjnO ANgTXYa4usIDYZt4Q4jgPNvdH0x0egJWrJ/RFc74NP54unD/layxTLrfhy4SkV+FmGzp q9px00a2D8l9Gz5uv2rB6EajlFgnF0g1WlVd4azf8wDkI2q0rRn1LgTa0IpdHpZSKKDu mI/g== X-Gm-Message-State: AOJu0Yzjgvjl8DqWIAiUzJ6aspMIXbbC3x8CxC3q0iZcGLZXsK4xaotJ aVNaccjyN67RQB4UwrirWD/15HnCFzmCf5TsQKSjeJt9OFcIwPqJnSLrYw== X-Google-Smtp-Source: AGHT+IF8pzN59Ta1a4GNiiNsFfVD8s9QmNZGQ0C7zsHDS5iqcy405YYc4/Pm5MnsjiPAMdRM7NEGuA== X-Received: by 2002:a5e:d503:0:b0:7da:303c:9a5f with SMTP id e3-20020a5ed503000000b007da303c9a5fmr8933472iom.20.1714351843825; Sun, 28 Apr 2024 17:50:43 -0700 (PDT) Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id v14-20020a056638250e00b004849340e49csm6924289jat.178.2024.04.28.17.50.42 for <bug-gnu-emacs@HIDDEN> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Apr 2024 17:50:42 -0700 (PDT) From: JD Smith <jdtsmith@HIDDEN> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Subject: :box vertical bar artifacts at 'display boundaries Message-Id: <646DB63C-1CD0-4BF4-8303-4A92B06D08DE@HIDDEN> Date: Sun, 28 Apr 2024 20:50:31 -0400 To: bug-gnu-emacs@HIDDEN X-Mailer: Apple Mail (2.3774.500.171.1.1) Received-SPF: pass client-ip=2607:f8b0:4864:20::d2d; envelope-from=jdtsmith@HIDDEN; helo=mail-io1-xd2d.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) I have identified a display bug related to placing :box face parameters = within 'display strings. Disable font-lock mode in *scratch* and = evaluate: (insert "\n" (propertize " " 'display (propertize " " 'face '(:box t))) (propertize "middle" 'face '(:box t)) (propertize " " 'display (propertize " " 'face '(:box t)))) So far so good: the box is correctly merged across all three elements = and wraps around them. But now move point within and across the = displayed boxed text. Internal vertical divisions bars separating the = 'display and normal :box regions appear. =20 If you add a face box property to the blank flanking strings as well, = this prevents the internal boundary from appearing.=20
JD Smith <jdtsmith@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#70637; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.