From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native display of line numbers Date: Sat, 24 Jun 2017 10:18:49 +0300 Message-ID: <83y3shua3q.fsf@gnu.org> References: <83lgoqzm0v.fsf@gnu.org> <83injouj5v.fsf@gnu.org> <8360fmv2j0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1498288766 25800 195.159.176.226 (24 Jun 2017 07:19:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Jun 2017 07:19:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 24 09:19:23 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dOfLk-0006Q3-Cu for ged-emacs-devel@m.gmane.org; Sat, 24 Jun 2017 09:19:20 +0200 Original-Received: from localhost ([::1]:38417 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOfLp-0000Hw-MJ for ged-emacs-devel@m.gmane.org; Sat, 24 Jun 2017 03:19:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOfLa-0000GD-NA for emacs-devel@gnu.org; Sat, 24 Jun 2017 03:19:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dOfLW-0000vm-PR for emacs-devel@gnu.org; Sat, 24 Jun 2017 03:19:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dOfLW-0000vi-MD; Sat, 24 Jun 2017 03:19:06 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1531 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dOfLV-0006Bd-R7; Sat, 24 Jun 2017 03:19:06 -0400 In-reply-to: (message from Stefan Monnier on Fri, 23 Jun 2017 17:24:45 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:215926 Archived-At: > From: Stefan Monnier > Date: Fri, 23 Jun 2017 17:24:45 -0400 > > >> Indeed, to make it fast enough it probably needs to count lines using > >> the matrices rather than the buffer. > > No, I cannot use the glyph matrices, because the line numbers are > > generated when the glyph matrix is created, and because the previous > > matrix cannot be trusted in general. > > Can't you fill the glyph matrix with some filler while building the > matrix and at the end go back to put the line numbers? That'd be problematic, because the only interpretation of "at the end" I can come up with is "just before calling update_frame", since there are a lot of shortcuts in the display engine which all lead to that point. Doing this at that point would mean potentially invalidating the decisions already made by the display engine during its traversal of the window tree. E.g., screen lines that seemed to be unchanged will now become changed due to changes in line numbers. So this would require an immediate second redisplay cycle, which runs afoul of my attempt to speed up redisplay with line numbers. > > I need to use the move_it_in_display_line_to and its ilk instead. > > That will make it costly, indeed. We shall see. Every "normal" redisplay already calls these functions for movement within the window limits, so it cannot be too slow.