bug#68441: Fix the unaligned tab in whitespace mode

bug#68441: Fix the unaligned tab in whitespace mode

[Young Arto]

[-- Attachment #1.1: Type: text/plain, Size: 110 bytes --]

As described in the commit message, this patch is meant to fix the unaligned tab when tab-mark is turned on.

[-- Attachment #1.2: Type: text/html, Size: 464 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-the-unaligned-tab-with-tab-mark-of-whitespace-mo.patch --]
[-- Type: text/x-patch; name="0001-Fix-the-unaligned-tab-with-tab-mark-of-whitespace-mo.patch", Size: 2416 bytes --]

From 595ff1877c750b35077298f00ad1a9a494927ab1 Mon Sep 17 00:00:00 2001
From: Arto Young <arto.young@outlook.com>
Date: Sat, 13 Jan 2024 19:52:44 +0800
Subject: [PATCH] Fix the unaligned tab with tab-mark of whitespace mode

There is a bug in whitespace mode which used the display table to
replace a tab with a tab-mark vector.

If we has a line like this:
------
123\t5678
------

If tab-width is 4 and tab-mark is [?> ?\t],
The line will be displayed as following:
(we use '^' to represent tab extra spaces)
------
123>^^^^5678
------

However, it should be displayed as:
------
123>5678
------

If the line was:
------
12\t5678
------

It would be displayed as:
------
12>^5678
------

It happens on the boundary of tab, so we should adjust the 'next_tab_x'
in this case.

* src/term.c (produce_glyphs): Correct the next_tab_x
* src/xdisp.c (gui_produce_glyphs): Correct the next_tab_x
---
 src/term.c  | 7 +++++++
 src/xdisp.c | 7 +++++++
 2 files changed, 14 insertions(+)

diff --git a/src/term.c b/src/term.c
index d3c858c6bf2..e34b2ed99de 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1642,6 +1642,13 @@ produce_glyphs (struct it *it)
 	   * it->tab_width);
       if (!NILP (Vdisplay_line_numbers) && it->line_number_produced_p)
 	next_tab_x += it->lnum_pixel_width;
+
+      /* For tab-mark display vector like [?> ?\t] for an
+	 original char '\t', we should not display ">\t"
+	 but only '>' at tab-width boundry, or tab real length
+	 will be tab-width+1, so we decrease tab-width here. */
+      if (it->c == '\t' && it->dpvec && it->current.dpvec_index > 0 && absolute_x % it->tab_width == 0)
+	next_tab_x -= it->tab_width;
       int nspaces;
 
       /* If part of the TAB has been displayed on the previous line
diff --git a/src/xdisp.c b/src/xdisp.c
index 14cf030ca4e..13fb6e5a308 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -32621,6 +32621,13 @@ gui_produce_glyphs (struct it *it)
 		    next_tab_x -= it->stretch_adjust;
 		}
 
+	      /* For tab-mark display vector like [?> ?\t] for an
+		 original char '\t', we should not display ">\t"
+		 but only '>' at tab-width boundry, or tab real length
+		 will be tab-width+1, so we decrease tab-width here. */
+	      if (it->c == '\t' && it->dpvec && it->current.dpvec_index > 0 && x % tab_width == 0)
+		next_tab_x -= tab_width;
+
 	      it->pixel_width = next_tab_x - x0;
 	      it->nglyphs = 1;
 	      if (FONT_TOO_HIGH (font))
-- 
2.43.0

bug#68441: Fix the unaligned tab in whitespace mode

[Eli Zaretskii]

> From: Young Arto <jifengsi@hotmail.com>
> Date: Sat, 13 Jan 2024 12:23:27 +0000
> msip_labels: 
> 
> There is a bug in whitespace mode which used the display table to
> replace a tab with a tab-mark vector.
> 
> If we has a line like this:
> ------
> 123\t5678
> ------
> 
> If tab-width is 4 and tab-mark is [?> ?\t],
> The line will be displayed as following:
> (we use '^' to represent tab extra spaces)
> ------
> 123>^^^^5678
> ------
> 
> However, it should be displayed as:
> ------
> 123>5678
> ------

I'm not sure I agree.  We never display a TAB as nothing, no matter if
it comes from a display vector or from a buffer or from any other
source.

So this patch changes long-standing behavior in non-trivial ways, and
I'm not sure what it can break, after so many years.  I understand
that it makes certain customizations in whitespace-mode look better on
display in some cases, but display-tables are used in Emacs not just
in whitespace-mode.

Thanks.

bug#68441: 回复: bug#68441: Fix the unaligned tab in whitespace mode

[Young Arto]

[-- Attachment #1: Type: text/plain, Size: 2320 bytes --]

So this patch changes long-standing behavior in non-trivial ways, and
I'm not sure what it can break, after so many years.  I understand
that it makes certain customizations in whitespace-mode look better on
display in some cases, but display-tables are used in Emacs not just
in whitespace-mode.
Yes, You are right. In fact, I'm not sure what it can break either. So I have
used this patch locally for about one year with self-compiled emacs29.
Fortunately, it didn't bring any side effects for me.  However, of course,
I cannot cover every function and every package for emacs.

It is really fundamental code. On the other hand, it is also annoying to
use whitespace-mode with unaligned tabs-mark. Would you be happy
if I add an option for this behavior like 'display-vector-limit-tab' which
defaults to nil? Finally, it won't change default behavior for all emacsers
and anybody like me who has trouble with this issue can turn it on in
their configuration file so they can test if it has side effects for them or
they can share this fix.

________________________________
发件人: Eli Zaretskii <eliz@gnu.org>
发送时间: 2024年1月14日 10:14
收件人: Young Arto <jifengsi@hotmail.com>
抄送: 68441@debbugs.gnu.org <68441@debbugs.gnu.org>
主题: Re: bug#68441: Fix the unaligned tab in whitespace mode

> From: Young Arto <jifengsi@hotmail.com>
> Date: Sat, 13 Jan 2024 12:23:27 +0000
> msip_labels:
>
> There is a bug in whitespace mode which used the display table to
> replace a tab with a tab-mark vector.
>
> If we has a line like this:
> ------
> 123\t5678
> ------
>
> If tab-width is 4 and tab-mark is [?> ?\t],
> The line will be displayed as following:
> (we use '^' to represent tab extra spaces)
> ------
> 123>^^^^5678
> ------
>
> However, it should be displayed as:
> ------
> 123>5678
> ------

I'm not sure I agree.  We never display a TAB as nothing, no matter if
it comes from a display vector or from a buffer or from any other
source.

So this patch changes long-standing behavior in non-trivial ways, and
I'm not sure what it can break, after so many years.  I understand
that it makes certain customizations in whitespace-mode look better on
display in some cases, but display-tables are used in Emacs not just
in whitespace-mode.

Thanks.

[-- Attachment #2: Type: text/html, Size: 8025 bytes --]

bug#68441: 回复: bug#68441: Fix the unaligned tab in whitespace mode

[Eli Zaretskii]

> From: Young Arto <jifengsi@hotmail.com>
> CC: "68441@debbugs.gnu.org" <68441@debbugs.gnu.org>
> Date: Sun, 28 Jan 2024 10:43:16 +0000
> 
>  So this patch changes long-standing behavior in non-trivial ways, and
>  I'm not sure what it can break, after so many years.  I understand
>  that it makes certain customizations in whitespace-mode look better on
>  display in some cases, but display-tables are used in Emacs not just
>  in whitespace-mode.
> 
> Yes, You are right. In fact, I'm not sure what it can break either. So I have
> used this patch locally for about one year with self-compiled emacs29.
> Fortunately, it didn't bring any side effects for me.  However, of course,
> I cannot cover every function and every package for emacs.
> 
> It is really fundamental code. On the other hand, it is also annoying to
> use whitespace-mode with unaligned tabs-mark. Would you be happy
> if I add an option for this behavior like 'display-vector-limit-tab' which
> defaults to nil? Finally, it won't change default behavior for all emacsers
> and anybody like me who has trouble with this issue can turn it on in
> their configuration file so they can test if it has side effects for them or
> they can share this fix.

Adding an option is better, but I'm not sure I understand in what
circumstances that option will affect the display of a TAB that comes
from a display vector.  Your changes seem to have some conditions
whose exact rationale and effect are not clear to me.  I mean the
following conditions:

   . it->current.dpvec_index > 0
   . absolute_x % it->tab_width == 0

What are the reasons for each of these conditions, and what kinds of
display-table entries they are supposed to support?

Also, did you test the results in situations like line-truncation and
display-line-numbers-mode, including the combination of the two?  And
what about visual-line-mode?  And what about line-prefix and
wrap-prefix?

See, the Emacs display engine supports a gazillion of features, so the
effect of these changes in each of these situations should be well
understood, otherwise we will be unable to document the expected
effect of the option you are suggesting to introduce.

Thanks.