Re: Problems with move_it_in_display_line_to X when tabs exist.

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

x_produce_glyphs runs multiple times on the line containing the STRETCH tab.  The value for it->pixel_width of the STRETCH tab (in this example) is _only_ correct when it->current_x is >= it->lnum_pixel_width.  Inasmuch as move_it_in_display_line_to is reporting that it.pixel_width remains at 49 even though the STRETCH shrinks (as we call scroll-left 1) to 42 to 35 to 28, it appears that x_produce_glyphs may be overwriting the correct value with the wrong value.  I restricted the floodgate of STDERR messages coming from x_produce_glyphs to only the situation when x0 >= it->lnum_pixel_width.  x_produce_glyphs probably runs _again_ when x0 < it->lnum_pixel_width, which overwrites the good value with the bad value.  Then, when I run move_it_in_display_line_to in screenshots 02 and 03, the err
 oneous value of 49 is returned -- the correct value in screenshot 02 should be 35, and the correct value in screenshot 03 should be 28.  If the previous value of it->pixel_width for the prior comman
 d loop were correct, then we would not see a consistent value of 49 in schreenshots 02 and 03 -- instead, we would see a value of 42 in screenshot 02 [which is really 35] and we would see a value 35 in screenshot 03 [which is really 28].

It may be the case that it is presently impossible to know the prospective _new_ value of it->pixel_width for a STRETCH tab (in this example) when calling move_it_in_display_line_to.  Since x_produce_glyphs knows how to calculate the correct value of it->pixel_width (when x0 >= it->lnum_pixel_width), perhaps there is a way to teach move_it_in_display_line_to how to do this?

Keith

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

DATE:  [01-16-2018 09:00:43] <16 Jan 2018 19:00:43 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date:  Mon, 15 Jan 2018 20:41:52 -0800
> > From:  Keith David Bershatsky <esq@lawlist.com>
> > Cc:  emacs-devel@gnu.org
> > 
> > The following screenshots with stderr results were obtained by calling the function debug-tab-pixel-width, which is contained in the attached patch.diff.  I saw that x_produce_glyphs is able to achieve the correct it->pixel_width for the STRETCH tab when x0 >= it->lnum_pixel_width; however, it is run subsequent in time to when we call move_it_in_display_line_to.
> > 
> > 
> > 0.  Opening screenshot -- just setting up the test buffer.
> > 
> >   https://www.lawlist.com/images/tab_width_bug_00.png
> > 
> > 
> > 1.  Place the cursor on the line that begins with a tab, and press the f5 key once.
> > 
> >   https://www.lawlist.com/images/tab_width_bug_01.png
> > 
> >   OBSERVATIONS (w->hscroll == 1):  The expected result is that the STRETCH tab will have an it.pixel_width of 42.  The third (3rd) iteration/loop has the wrong value; i.e., 49.  The fourth (4th) iteration/loop has the correct value; i.e., 42.  x_produce_glyphs runs subsequent in time and contains the desired value of 42 when x0 >= it->lnum_pixel_width.
> 
> What do you mean by "x_produce_glyphs runs subsequent in time"?  The
> value of it->pixel_width is updated by x_produce_glyphs, so before it
> was called, that value is outdated (belongs to the previous glyph).
> If that is what you observe, then it's the expected behavior, and not
> a bug.