GNU bug report logs - #50506
28.0.50; display-line-numbers equivalent for linum-format?

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Gallagher - NOAA Affiliate <michael.r.gallagher <at> noaa.gov>
Cc: 50506 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#50506: 28.0.50; display-line-numbers equivalent for linum-format?
Date: Wed, 15 Sep 2021 19:53:30 +0300

> From: Michael Gallagher - NOAA Affiliate <michael.r.gallagher <at> noaa.gov>
> Date: Wed, 15 Sep 2021 10:45:01 -0600
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 50506 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.