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

From: Keith David Bershatsky <[email-masked]>
Date: Sun, 04 Feb 2018 11:21:38 -0800

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.