bug#50506: 28.0.50; display-line-numbers equivalent for linum-format?

[Eli Zaretskii]

> From: Michael Gallagher - NOAA Affiliate <michael.r.gallagher@noaa.gov>
> Date: Wed, 15 Sep 2021 10:45:01 -0600
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50506@debbugs.gnu.org
> 
> So, in concept then, as the display-line-numbers code operates now adding a 
> separator character that
> respects direction isn't possible because when maybe_produce_line_number is 
> called the code doesn't yet
> know the direction of the text. The correct fix is to somehow have the 
> function call for generating the line
> number glyphs after the buffer glyphs are computed... or to generate both L2R 
> and R2L line numbers and
> then let the code decide what to display once reversed_p is decided.

Yes.

> This is verified by the fact that if I make a check on paragraph_direction 
> instead of embedding, the first line
> number displays incorrectly because this flag has yet to be set. 

Exactly.

> Either way, I hate to admit it, but any solution to that problem is way 
> beyond my skillset and you'd have to
> spend a lot of time checking/fixing any my work if I did make the attempt.

The idea I had, which is somewhat ugly, is to rearrange the glyphs in
the line-number part if the value of the reversed_p flag changes
between the time the line number was produced and the time the first
following glyph is produced in display_line.