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

[Michael Gallagher - NOAA Affiliate via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

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.

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.

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.

On Wed, Sep 15, 2021 at 10:26 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Michael Gallagher - NOAA Affiliate <michael.r.gallagher@noaa.gov>
> > Date: Wed, 15 Sep 2021 10:08:49 -0600
> > Cc: Lars Ingebrigtsen <larsi@gnus.org>, 50506@debbugs.gnu.org
> >
> >
> > [1:text/plain Show]
> >
> >
> > [2:text/html Hide Save:noname (5kB)]
> >
> > The code as it stands displays correctly with TUTORIAL.he.
>
> What is the value of bidi-paragraph-direction in the buffer where you
> visit TUTORIAL.he for testing this feature?  It should be nil.
>
> Your code does this:
>
>   +  if (FIXNATP (Vdisplay_line_numbers_separator_character)
>   +      && it->paragraph_embedding != L2R)
>   +    {
>   +      tem_it.c = tem_it.char_to_display = XFIXNAT
> (Vdisplay_line_numbers_separator_character);
>
> That is, it treats any value of it->paragraph_embedding that is not
> L2R as if it were R2L.  But that is incorrect, because the usual value
> of it->paragraph_embedding is NEUTRAL_DIR, which corresponds to the
> nil value of bidi-paragraph-direction, the default.  That nil value
> means to determine the actual paragraph direction dynamically from the
> contents of the paragraph.  It is this nil value that presents the
> problem.  Your code treats that value as meaning right-to-left, but
> that is wrong.
>
> For example, all of the paragraphs on TUTORIAL.he are displayed
> right-to-left (because they include right-to-left text), but the last
> paragraph, the one which shows the file-local variables, is displayed
> left-to-right.  Try turning on this feature and look at that last part
> of the buffer to see if your code works correctly.
>
> > I was confused about the relationship between paragraph_embedding and
> bidi-paragraph_direction.
>
> bidi-paragraph-direction determines the value of it->paragraph_embedding.
> However, the default value of bidi-paragraph-direction is nil, and
> that is translated into NEUTRAL_DIR value of it->paragraph_embedding.
>
> > I'm
> > assuming you're saying there needs to be an additional check on the
> value of para_direction in the if
> > statements?
>
> I don't think you can base this on it->paragraph_embedding, because it
> doesn't reflect the actual paragraph direction on display when
> bidi-paragraph-direction is nil, the default.  The display code
> computes the actual direction of each screen line dynamically in that
> case, and stores it in the reversed_p flag of the glyph row.  The
> problem is that when the code generates the line number of the first
> screen line it needs to produce, that flag is not yet computed, it
> will only be computed when the first character on the screen line, the
> one after the line number, will be laid out.  And by that time, the
> line number was already generated.  This is the problem that needs
> fixing for this to work reliably with all scripts.
>
> Thanks.
>


-- 
Michael Gallagher, PhD
CIRES Research Scientist
Polar Observations and Processes Team (ESRL/NOAA/PSD)
325 Broadway, Boulder, Colorado 80305

[-- Attachment #2: Type: text/html, Size: 5167 bytes --]