From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: relative line numbers and folding: how to make they play along? Date: Fri, 15 Jul 2016 17:22:07 +0300 Message-ID: <83d1mf6kxc.fsf@gnu.org> References: <8360sbcvbz.fsf@gnu.org> <83lh158eza.fsf@gnu.org> <83bn208djh.fsf@gnu.org> <83mvlj7513.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1468592609 13558 80.91.229.3 (15 Jul 2016 14:23:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 14:23:29 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jul 15 16:23:29 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bO41T-00018o-Jr for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Jul 2016 16:23:23 +0200 Original-Received: from localhost ([::1]:32843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO41S-0004w7-SV for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Jul 2016 10:23:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO40p-0004Oy-BG for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 10:22:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO40j-0004s5-93 for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 10:22:42 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO40j-0004s0-5h for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 10:22:37 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3693 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bO40f-0000Yu-RG for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 10:22:36 -0400 In-reply-to: (message from Stefan Monnier on Fri, 15 Jul 2016 09:53:44 -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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:110867 Archived-At: > From: Stefan Monnier > Date: Fri, 15 Jul 2016 09:53:44 -0400 > > I was more thinking of the situation I mentioned in some other > discussion: rewrite the top-level of the redisplay code in Elisp, Conditioning the minor feature discussed in this thread on such a thorough rewrite of the display code sounds like overkill to me. > basically a function which: > - asks the C code which windows need to be redisplayed. > - call a C function on each of those windows to recompute the matrices. > - detect the case where point is out of the window, and either move > point and call the recompute-matrices function, or call another > C function to do the scrolling. > - then call a C function on each window/frame to update the display. > > >From there we can hope to provide a more efficient/robust follow-mode > (while still implementing it in Elisp). And in that context, we should > also be able to provide a more efficient relative-visual-linum-mode, tho > it might require yet more access, such as subrs to scan/read the > matrices, and maybe other subrs to modify the matrices (to update the > margin). > > Some of those primitives would probably also be useful in order to write > tests of the redisplay code. > > I think such a change should be doable without a complete rewrite of > the redisplay. But it would undoubtedly take a fair bit of work. Frankly, I don't see any significant gains in your suggestion. Basically, you suggest to leave the bulk of the display code unchanged, and introduce a Lisp-level driver that calls its parts one after the other. Moreover, that Lisp will be called from C, since that's where we currently invoke redisplay. I don't see why we would want that, and disagree with you that this will make the job of follow-mode easier (because what follow-mode wants is intervene in the middle of some of those parts you want to leave in C). I think a much better plan is to expose some of the C data structures to Lisp, and provide focused hooks at strategic places for Lisp to be able to affect what redisplay does, by accessing those data structures and making decisions based on that.