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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 15 Sep 2021 19:53:30 +0300

> From: Michael Gallagher - NOAA Affiliate <[email-masked]>
> Date: Wed, 15 Sep 2021 10:45:01 -0600
> Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked]
> 
> 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.