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
[Message part 1 (text/plain, inline)]
Ok. Correct me if I'm wrong, but this is extremely ugly in that it requires
a deep knowledge of how the glyphs are drawn and how move_it_by_lines
operates on the glyphs. Because, as it appears to me, once the line number
glyphs are sent to what I will call the "glyph queue" via PRODUCE_GLYPHS
you have very little (no?) information about what is responsible for those
glyphs? Actually. I don't fully understand where in the code the line
numbers get moved to the right side. Because it should be, conceptually,
easy to swap the last glyph to the first glyph if there is a separator
character at that point in the code. But when I "M-s o" for occurences of
R2L and then look for the place where the lnum glyphs are moved to the
right side, I can't find it.
On Wed, Sep 15, 2021 at 10:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 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.
>
--
Michael Gallagher, PhD
CIRES Research Scientist
Polar Observations and Processes Team (ESRL/NOAA/PSD)
325 Broadway, Boulder, Colorado 80305
[Message part 2 (text/html, inline)]
This bug report was last modified 3 years and 269 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.