GNU bug report logs -
#30226
Fixing it->pixel_width / it->current_x when tabs and line numbers.
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 126 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.