From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Gallagher - NOAA Affiliate via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#50506: 28.0.50; display-line-numbers equivalent for linum-format? Date: Wed, 15 Sep 2021 10:45:01 -0600 Message-ID: References: <87czpgc1yb.fsf@noaa.gov> <83fsucipdz.fsf@gnu.org> <87tuirnwu0.fsf@gnus.org> <83sfy8cpvz.fsf@gnu.org> <83pmtccovd.fsf@gnu.org> <834kancb73.fsf@gnu.org> <83ilz1bzyx.fsf@gnu.org> <83ee9pby9t.fsf@gnu.org> Reply-To: Michael Gallagher - NOAA Affiliate Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000085602605cc0b6d43" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19162"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50506@debbugs.gnu.org, Lars Ingebrigtsen To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 15 19:00:22 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mQYGd-0004bJ-JU for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 19:00:15 +0200 Original-Received: from localhost ([::1]:46312 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQYGc-000117-Jc for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 13:00:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQY2u-0007oq-CF for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:46:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41587) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQY2s-00007X-5D for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:46:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQY2s-0003dr-4B for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Gallagher - NOAA Affiliate Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Sep 2021 16:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50506 X-GNU-PR-Package: emacs Original-Received: via spool by 50506-submit@debbugs.gnu.org id=B50506.163172434613976 (code B ref 50506); Wed, 15 Sep 2021 16:46:02 +0000 Original-Received: (at 50506) by debbugs.gnu.org; 15 Sep 2021 16:45:46 +0000 Original-Received: from localhost ([127.0.0.1]:53133 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQY2c-0003dM-4A for submit@debbugs.gnu.org; Wed, 15 Sep 2021 12:45:46 -0400 Original-Received: from mail-pf1-f182.google.com ([209.85.210.182]:41959) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQY2Z-0003d8-Ni for 50506@debbugs.gnu.org; Wed, 15 Sep 2021 12:45:44 -0400 Original-Received: by mail-pf1-f182.google.com with SMTP id x7so3145871pfa.8 for <50506@debbugs.gnu.org>; Wed, 15 Sep 2021 09:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noaa.gov; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VUvQUxY4Uiy0qosk6JSjK7/a0V/YmdTCLautbVElQQY=; b=js2UvPzpHdvdS1o5YZwFEjga+v8izOH7qd6/noPCkv3H0icft4IsGr2bZVwAkCyXWn YfX+DqZvAdfVXwNzO0vzf2b9jacm4n1VTLuj/bg/v7bwVRhVnpa2UpauOn4EE2Q0pGcT 4lhH+Fbge9oiXMwS6lwM3R6cTqMXtv+tXlKCytW6UP2uLTPhZ+t3xBG8x3ADUZhqPH80 YF9U2F7Nd+YIBwTzhFTJUwIZb0I8vg+d0qUI8kHRqVD8blkvhdUwCBXwX9VJQuArGJGP BON8fJSsQpdYsxxEwaUAJUkFEjLEbm/odo/134GJUz70t3Xxgz6aZEkTFFrHX4Zho08j dXnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VUvQUxY4Uiy0qosk6JSjK7/a0V/YmdTCLautbVElQQY=; b=aSsh3HxrLYz0OLG4EqvLF1mTdPq5QRTBjuC8XM9Occhtlfv7REqEwirR4ya0TKQZH8 yZoiuMM/78h2/W0ONaT8OSoSm9bmBwRya5vOAcjsZ0LzNo1dEP/i1ks4eXjSf8Tr9oQu 2+zxY7jVfn+24Wl+0cUR8HwkJR8n9U1hme5dKA0gJ8vWSeVBA2vFQk6iNI5pvSuTZdrv L5LmhA9DE2ptsY/kVGkMfUWPP1/s4NlAK0VJrCbus3FGqlbCAaGMCm2qltiJ45Ad7lss zbmZFVAeRZRx8mFlaxDaTvEWLARlP+luj1xzxKFy1ej/sdR4eNX/BKme2y4Gmynj1/P+ rUXg== X-Gm-Message-State: AOAM531pblxMm4AKbxsHmFOSxBX536GZSt93yDVs8B8pNQNCe8M513NO 2dLOnsAsunXbMovHnI+oZFXp3KiWtV8ali5+yyosqA== X-Google-Smtp-Source: ABdhPJxPWfKCd/nufNAzsj8g3lSvMNi7amkK3/QFRG4MQTjnhGmwWV5GzWXrOwY3sZ8mjxipu4nHXRVS14JOX3vBZZE= X-Received: by 2002:a65:4008:: with SMTP id f8mr640510pgp.310.1631724337683; Wed, 15 Sep 2021 09:45:37 -0700 (PDT) In-Reply-To: <83ee9pby9t.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:214415 Archived-At: --00000000000085602605cc0b6d43 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > From: Michael Gallagher - NOAA Affiliate > > Date: Wed, 15 Sep 2021 10:08:49 -0600 > > Cc: Lars Ingebrigtsen , 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 --00000000000085602605cc0b6d43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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&= #39;t yet know the direction of the text. The correct fix is to somehow hav= e 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 the= n 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 para= graph_direction instead of embedding, the first line number displays incorr= ectly because this flag has yet to be set.

Ei= ther way, I hate to admit it, but any solution to that problem is way beyon= d 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.g= ov>
> 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?=C2=A0 It should be nil.

Your code does this:

=C2=A0 +=C2=A0 if (FIXNATP (Vdisplay_line_numbers_separator_character)
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 && it->paragraph_embedding !=3D L2R= )
=C2=A0 +=C2=A0 =C2=A0 {
=C2=A0 +=C2=A0 =C2=A0 =C2=A0 tem_it.c =3D tem_it.char_to_display =3D XFIXNA= T (Vdisplay_line_numbers_separator_character);

That is, it treats any value of it->paragraph_embedding that is not
L2R as if it were R2L.=C2=A0 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.=C2=A0 That nil value means to determine the actual paragraph direction dynamically from the
contents of the paragraph.=C2=A0 It is this nil value that presents the
problem.=C2=A0 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.=C2=A0 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 th= e 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.=C2=A0 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.=C2=A0 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.=C2=A0 And by that time, the line number was already generated.=C2=A0 This is the problem that needs
fixing for this to work reliably with all scripts.

Thanks.


--
Michael G= allagher, PhD
CIRES Res= earch Scientist
<= /div>
Polar Observations and Processes Te= am (ESRL/NOAA/PSD)
325 Broadway, Boulder, Colora= do 80305
--00000000000085602605cc0b6d43--