From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#50506: 28.0.50; display-line-numbers equivalent for linum-format? Date: Wed, 15 Sep 2021 19:26:38 +0300 Message-ID: <83ee9pby9t.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8107"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50506@debbugs.gnu.org, larsi@gnus.org To: Michael Gallagher - NOAA Affiliate Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 15 18:27:18 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 1mQXkk-0001xL-Hr for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 18:27:18 +0200 Original-Received: from localhost ([::1]:54860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQXkh-00081W-6p for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 12:27:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58586) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQXkU-00080J-S8 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:27:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41494) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQXkU-0001Py-Kd for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQXkU-000340-Hc for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 12:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Sep 2021 16:27: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.163172321011757 (code B ref 50506); Wed, 15 Sep 2021 16:27:02 +0000 Original-Received: (at 50506) by debbugs.gnu.org; 15 Sep 2021 16:26:50 +0000 Original-Received: from localhost ([127.0.0.1]:53040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQXkI-00033Z-4r for submit@debbugs.gnu.org; Wed, 15 Sep 2021 12:26:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQXkG-00033K-KD for 50506@debbugs.gnu.org; Wed, 15 Sep 2021 12:26:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42326) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQXkB-000187-4q; Wed, 15 Sep 2021 12:26:43 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4010 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQXkA-0008LA-0k; Wed, 15 Sep 2021 12:26:42 -0400 In-Reply-To: (message from Michael Gallagher - NOAA Affiliate on Wed, 15 Sep 2021 10:08:49 -0600) 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:214412 Archived-At: > 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.