Re: Problems with move_it_in_display_line_to X when tabs exist.

[Keith David Bershatsky <esq@lawlist.com>]

The test assumes:

* The variable word-wrap is non-nil.

* The variable tab-width is 2.

* The buffer-display table entry for a tab is:  [(187 . 120) (9 . 121)].

* Native line numbers are _not_ enabled.

I have a long line that wraps at the window edge and I put a space to simulate a new word that should be wrapped to the following line.  To make it easier to read, I am using the backslash symbol (below) to signify a word-wrap with a space at the window edge.  The next line has three "x" followed by a tab and then the word "hello-world".  The STRETCH glyph is 22 pixels wide; however, it.pixel_width is erroneously (?) reporting that it is 11 pixels wide.

I have hard-coded an emacs_abort () when it.c == '\t', which means that we have just moved passed character 187 (aka "»") and we are now on a STRETCH tab-width.

Here is a link to a screen-shot of this particular issue:

https://www.lawlist.com/images/pgrowx_a.png

What would be the next step(s), please, to continue working on debugging this particular issue?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx \
xxx	hello-world


(gdb) pgrowx glyph_row
[New Thread 0x1c0b of process 16745]
TEXT: 18 glyphs
  0    0: CHAR[x] pos=1197 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  1   11: CHAR[x] pos=1198 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  2   22: CHAR[x] pos=1199 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  3   33: CHAR[0xbb] pos=1200 blev=0,btyp=UNDEF w=11 a+d=16+4 face=31 MB
  4   44: STRETCH[20+16] pos=1200 w=22 a+d=16+4 face=30 MB
  5   66: CHAR[h] pos=1201 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  6   77: CHAR[e] pos=1202 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  7   88: CHAR[l] pos=1203 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  8   99: CHAR[l] pos=1204 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
  9  110: CHAR[o] pos=1205 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 10  121: CHAR[-] pos=1206 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 11  132: CHAR[w] pos=1207 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 12  143: CHAR[o] pos=1208 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 13  154: CHAR[r] pos=1209 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 14  165: CHAR[l] pos=1210 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 15  176: CHAR[d] pos=1211 blev=0,btyp=UNDEF w=11 a+d=16+4 MB
 16  187: CHAR[0xb6] pos=1212 blev=0,btyp=UNDEF w=11 a+d=16+4 face=26 MB
 17  198: CHAR[ ] pos=0 blev=0,btyp=UNDEF w=11 a+d=16+4 MB

(gdb) print it.c
$1 = 9

(gdb) print it.pixel_width
$2 = 11

Thanks,

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [11-29-2017 10:04:14] <29 Nov 2017 20:04:14 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Tue, 28 Nov 2017 22:12:35 -0800
> > From: Keith David Bershatsky <esq@lawlist.com>
> > 
> > I can see that X and/or HPOS are wrong when tabs are present on the current line because I get superimposed letters and double of the same word slightly off to the left and/or the right of where the word should be.
> > 
> > HYPOTHESIS:  I would venture to say that what is displayed on screen does _not_ coincide with what IT reports when running move_it_in_display_line_to.
> 
> Does this happen only when line numbers are displayed?
> 
> In any case, your description provides a lot of details that are hard
> to reason about, because most of the code is not shown.  OTOH, if
> indeed there's a bug in move_it_in_display_line_to, then presenting
> evidence for it is very simple: show a line of text and its line
> number, and then show the X and HPOS values for each tab in that line
> as calculated by move_it_in_display_line_to vs the same values in a
> displayed line.  (For the latter, you can use the pgrowx command
> defined in src/.gdbinit, or manually display the values using the
> debugger.)
> 
> If you do that, any mismatches between displaying a line and moving
> through it with move_it_in_display_line_to will be immediately
> apparent, and it should be easy to fix them.