From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: relative line numbers and folding: how to make they play along? Date: Fri, 15 Jul 2016 09:53:44 -0400 Message-ID: References: <8360sbcvbz.fsf@gnu.org> <83lh158eza.fsf@gnu.org> <83bn208djh.fsf@gnu.org> <83mvlj7513.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468591011 19710 80.91.229.3 (15 Jul 2016 13:56:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 13:56:51 +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 15:56:43 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 1bO3bd-0006iy-5G for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Jul 2016 15:56:41 +0200 Original-Received: from localhost ([::1]:60930 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO3bc-0006tW-Cq for geh-help-gnu-emacs@m.gmane.org; Fri, 15 Jul 2016 09:56:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO3ZE-0004Zt-ON for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 09:54:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bO3ZA-0006mL-Iy for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 09:54:11 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:37872) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bO3ZA-0006m8-Bj for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 09:54:08 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bO3Yx-0004g3-VY for help-gnu-emacs@gnu.org; Fri, 15 Jul 2016 15:53:55 +0200 Original-Received: from 69-165-156-121.dsl.teksavvy.com ([69.165.156.121]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2016 15:53:55 +0200 Original-Received: from monnier by 69-165-156-121.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2016 15:53:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-165-156-121.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:LlEakgTUVtnQ17cNo2GG5Rotft8= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:110865 Archived-At: >> >> Actually, I don't think there needs to be flickering if the first step >> >> ("perform redisplay of window") just computes the new matrices without >> >> performing any drawing. >> > Since the display engine computes the number of each screen line as it >> > lays them out, I don't understand why would 2 phases be needed. I'm >> > probably missing something. >> If we bake it into the redisplay code, we can indeed do it "on the fly", >> but if we want this feature to be implemented in Elisp it seems a lot >> more tricky to avoid the 2 passes. > But this sub-thread started with you talking about baking it into > redisplay: By "help from the display engine" I meant that we'd need to make changes to the C code, but I didn't mean to bake it in. > These two passes are described in terms of what redisplay does, they > are not visible to Lisp: we don't return to the command loop after > each window's redisplay, and the glyph matrices are not exposed to > Lisp, either. I didn't mean to return to the command-loop in-between. I was more thinking of the situation I mentioned in some other discussion: rewrite the top-level of the redisplay code in Elisp, 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. Stefan