From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Native line numbers landed on master Date: Tue, 01 Oct 2019 10:05:06 +0300 Message-ID: <837e5paqu5.fsf@gnu.org> References: <83k23jl5ra.fsf@gnu.org> <87bmolqryw.fsf@wavexx.thregr.org> <83blz5bh2m.fsf@gnu.org> <87h88x4fqw.fsf@wavexx.thregr.org> <834l4xbfmp.fsf@gnu.org> <87ef414dfn.fsf@wavexx.thregr.org> <83o9359w3l.fsf@gnu.org> <83eezycce5.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3710"; mail-complaints-to="usenet@blaine.gmane.org" Cc: wavexx@thregr.org, emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 01 09:06:15 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iFCEg-0000kp-D0 for ged-emacs-devel@m.gmane.org; Tue, 01 Oct 2019 09:06:14 +0200 Original-Received: from localhost ([::1]:59400 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFCEe-0003ZA-Iw for ged-emacs-devel@m.gmane.org; Tue, 01 Oct 2019 03:06:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47970) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iFCDr-0003Z0-60 for emacs-devel@gnu.org; Tue, 01 Oct 2019 03:05:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55661) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iFCDq-00038u-K6; Tue, 01 Oct 2019 03:05:22 -0400 Original-Received: from [176.228.60.248] (port=3708 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iFCDc-0001Xe-V9; Tue, 01 Oct 2019 03:05:19 -0400 In-reply-to: (message from Juanma Barranquero on Tue, 1 Oct 2019 07:44:47 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:240418 Archived-At: > From: Juanma Barranquero > Date: Tue, 1 Oct 2019 07:44:47 +0200 > Cc: wavexx@thregr.org, Emacs developers > > > Patches welcome. > > To quote Barney Stinson, "Challenge accepted!" Thanks. > > I don't think it should be too hard to write that. > > Didn't know you were an optimist. I am not. > Ok. The following extremely simple patch (with no documentation, etc, and > horrible, *horrible* face names because I couldn't think of anything > better) seems to work in the various tests I've done in absolute, visual > and relative modes. Ideas for better face names are welcome. I can suggest: line-number-tenth-line line-number-fifth-line (the latter is inaccurate, but a doc string can explain the subtlety). > Now, I'm not sure about code (try_cursor_movement and try_window_id) that > compare the line-number and line-number-current-line faces for > optimization. Performance seems to be fine, and I haven't seen any obvious > visual glitch. > > Also, this in maybe_produce_line_number: > > /* Compute point's line number if needed. */ > if ((EQ (Vdisplay_line_numbers, Qrelative) > || EQ (Vdisplay_line_numbers, Qvisual) > || lnum_face_id != current_lnum_face_id) > && !it->pt_lnum) > > should perhaps compare curremt_lnum_face_id also with the face_ids of the > two new faces. ? I don't think so. Both the issue with disabling try_cursor_movement and try_window_id, and the issue with the above 'if' clause are because the line-number-current-line face is used for the _current_ line, whose position is not fixed wrt to the rest of the lines, but changes due to moving point. For that reason, any point movement means the new and the old "current" lines need to be redrawn, even though neither their text nor their line numbers have changed. By contrast, the 5th and 10th lines' positions wrt to the rest of the lines are fixed, so point movement doesn't require to redraw these lines. The above is the theory, but I understand you didn't see any redisplay problems without those changes? If so, the theory is correct. I suggest to wait for a week or so, to let people try the patch and suggest better names for the faces, then push this.