bug#30226: Fixing it->pixel_width / it->current_x when tabs and line numbers.

[Keith David Bershatsky]

I was able to locate the section of code responsible (at least in part) for the 
width of a tab STRETCH taking on a negative value and visually disappearing as 
stated in paragraph II of the preceding email; i.e., thread message #26:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30226#26

xdisp:28250 to xdisp:28252

              /* Adjust for line numbers, if needed.   */
              if (!NILP (Vdisplay_line_numbers) && x0 >= it->lnum_pixel_width)
                x -= it->lnum_pixel_width;

In that section of code (lines 28250 to 28252), x is adjusted for line numbers; 
however, x0 is _not_ adjusted.  This leads to the second (and other subsequent) 
tab STRETCH visually disappearing and take on a negative width value when 
w->hscroll >= 2.  Here is a link to a screenshot of what this looks like:

https://www.lawlist.com/images/30226_a.png

I have not yet been able to figure out why the values for it->current_x are 
different when glyphs are actually produced, versus when we only use 
move_it_in_display_line_to without producing glyphs.  The difference in 
behavior in the value for X and all values derived therefrom (e.g., 
pixel_width) can be seen by setting up a few stderr messages in 
x_produce_glyphs and also move_it_in_display_line_to.  When 
append_stretch_glyph is called (because glyphs are actually being produced), 
the value for it->pixel_width is completely different than when we only call 
move_it_in_display_line_to without producing glyphs.

In the event that I am able to make any additional headway, I'll post a 
follow-up to #30226.