Re: Problems with move_it_in_display_line_to X when tabs exist.

[Keith David Bershatsky]

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 erroneous 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 <address@hidden>
> 
> > Date:  Mon, 15 Jan 2018 20:41:52 -0800
> > From:  Keith David Bershatsky <address@hidden>
> > Cc:  address@hidden
> > 
> > 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.