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

[Eli Zaretskii <eliz@gnu.org>]

> Date:  Sun, 18 Feb 2018 18:17:26 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  30226@debbugs.gnu.org
> 
> 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 latter.

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)
	it->hpos++;
      if (p)
	{
	  *p++ = *g;
	  (*u)++;
	}
    }

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...