bug#55387: 28.1.50; csv-mode: header does not align when line numbers are displayed

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: joostkremers@fastmail.fm,  55387@debbugs.gnu.org
> Date: Fri, 13 May 2022 15:41:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I understand how this could work.  The line-number width
> > is not fixed, it changes dynamically as needed.  How would the
> > header-line adapt itself, except in some hook that is called by
> > redisplay?
> 
> header-line-format would look like
> 
> (display-line-spaces <the rest>)
> 
> where display-line-spaces would indeed be updated by the redisplay code
> (to be of the same length as (line-number-display-width 'columns)).

This last bit is what I don't understand.  Redisplay code works one
screen line at a time, and it does that from the highest line to the
lowest line ("highest" and "lowest" don't necessarily mean the first
and the last visible lines in a window, they could mean line number N
and line number M, where N <= M).  When (and if) it displays the
header-line, it doesn't yet know that the lines showing text will need
a wider line-number display; it will know that only when it works on
the first screen line of text it was asked to display.  And when it
displays a screen line of text, it doesn't consider
header-line-format, not even whether the window has a header-line.

Moreover, the code which produces the line-numbers can be called when
the line doesn't need to be displayed at all, only its metrics
measured, for some job related to layout of text.  In this case, it
would be unthinkable to modify the header-line as a side effect,
because no one expects the header-line to be updated on display when,
say, the user presses C-n in the middle of a window.

So again, I don't understand how this can work.

This is why we have hooks that redisplay calls in strategic places,
and tabulated-list.el uses them to update the header-line.  Why isn't
that a better way?