[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30226: Fixing it->pixel_width / it->current_x when tabs and line num
From: |
Keith David Bershatsky |
Subject: |
bug#30226: Fixing it->pixel_width / it->current_x when tabs and line numbers. |
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.
- bug#30226: Fixing it->pixel_width / it->current_x when tabs and line numbers.,
Keith David Bershatsky <=