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 21:10:39 +0300 Message-ID: <837dfhbtgg.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> <83ee9pby9t.fsf@gnu.org> <83a6kdbx11.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24391"; 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 20:30:09 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 1mQZfc-00067C-Rd for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 20:30:08 +0200 Original-Received: from localhost ([::1]:50166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQZfY-0000k8-Rh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 14:30:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56822) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQZN8-0006dk-C9 for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 14:11:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41646) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQZN8-0003VZ-2I for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 14:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQZN7-00061m-Se for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 14:11:01 -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 18:11:01 +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.163172945223152 (code B ref 50506); Wed, 15 Sep 2021 18:11:01 +0000 Original-Received: (at 50506) by debbugs.gnu.org; 15 Sep 2021 18:10:52 +0000 Original-Received: from localhost ([127.0.0.1]:53192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQZMy-00061J-1K for submit@debbugs.gnu.org; Wed, 15 Sep 2021 14:10:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQZMv-000615-0X for 50506@debbugs.gnu.org; Wed, 15 Sep 2021 14:10:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46688) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQZMp-0003Ez-HN; Wed, 15 Sep 2021 14:10:43 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2421 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 1mQZMp-0004a6-1n; Wed, 15 Sep 2021 14:10:43 -0400 In-Reply-To: (message from Michael Gallagher - NOAA Affiliate on Wed, 15 Sep 2021 11:32:17 -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:214423 Archived-At: > From: Michael Gallagher - NOAA Affiliate > Date: Wed, 15 Sep 2021 11:32:17 -0600 > Cc: Lars Ingebrigtsen , 50506@debbugs.gnu.org > > 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. move_it_by_lines is not relevant here. The code to look at is display_line and the few of the functions it calls. display_line is where the display engine generates screen lines, called "glyph rows". A glyph row is just an array of 'struct glyph', or "glyphs" for short. Each one of these glyphs describes a single "display element": a character, an image, a stretch of whitespace, etc. We are interested in character glyphs here. > 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? PRODUCE_GLYPHS is a macro that (on GUI frames) calls gui_produce_glyphs. It generates one glyph and adds it to the array of glyphs of the glyph row. At any point during the time display_line works on a single glyph row (a.k.a. "screen line"), you can reach all the glyphs produced upto that point by looking at the glyphs in the it->glyph_row array indexed by their horizontal position. A glyph row has 3 areas: 2 areas for the left and right margins, and one area called TEXT_AREA, which is where the line numbers and the text of the line are laid out. So the i-th glyph in the text area of the glyph row is it->glyph_row->glyphs[TEXT_AREA][i-1], and the last glyph produced so far has its index in it->glyph_row->used[TEXT_AREA]-1. > 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. When gui_produce_glyphs and its subroutines realize that the glyph row has its reversed_p flag set, they start pushing (prepending) glyphs to the glyphs already there, instead of appending them. That's how the line number winds up at the right edge of the screen line: it is pushed there by the following glyphs when those are prepended. Look in append_glyph to see how this is done. If what I told above and the code I pointed to leave something unclear, please ask specific questions.