[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
bug#30226: Fixing it->pixel_width / it->current_x when tabs and line numbers.
Mon, 19 Feb 2018 18:28:38 +0200
> Date: Sun, 18 Feb 2018 18:17:26 -0800
> From: Keith David Bershatsky <address@hidden>
> Cc: address@hidden
> A major break-through in the tracing of bug 30226 .... it->current_x differs
> between the real thing (when display_line calls PRODUCE_GLYPHS), versus the
> simulation (when move_it_in_display_line_to calls PRODUCE_GLYPHS), _because_
> maybe_produce_line_number advances it->current_x in the former but _not_ the
How do you see that maybe_produce_line_number doesn't advance
current_x? AFAICS, it does that unconditionally:
for ( ; g < e; g++)
it->current_x += g->pixel_width; <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/* The following is important when this function is called
from move_it_in_display_line_to: HPOS is incremented only
when we are in the visible portion of the glyph row. */
if (it->current_x > it->first_visible_x)
*p++ = *g;
Did you mean hpos instead? Or did you mean that
maybe_produce_line_number is not called from
move_it_in_display_line_to in some case, whereas it is called from
display_line? Or something else?
> SOLUTION (suggested): Revise move_it_in_display_line_to advance X by
> simulating a call to maybe_produce_line_number and permitting that function
> to advance X.
But this is already done...