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

[Eli Zaretskii]

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