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.devel Subject: Re: Future of display engine and lines Date: Mon, 25 Oct 2021 15:05:29 +0300 Message-ID: <834k952tti.fsf@gnu.org> References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.org> <83r1cc5i8p.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34560"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 25 14:19:39 2021 Return-path: Envelope-to: ged-emacs-devel@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 1meyx1-0008lH-DY for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 14:19:39 +0200 Original-Received: from localhost ([::1]:60672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meywz-0003Jp-5o for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 08:19:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meyjg-0008A6-5h for emacs-devel@gnu.org; Mon, 25 Oct 2021 08:05:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38842) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meyjf-0003bz-B4; Mon, 25 Oct 2021 08:05:51 -0400 Original-Received: from [87.69.77.57] (port=3675 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 1meyjQ-0002vW-8F; Mon, 25 Oct 2021 08:05:44 -0400 In-Reply-To: (message from Richard Stallman on Sun, 24 Oct 2021 22:18:40 -0400) 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:277732 Archived-At: > From: Richard Stallman > Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org > Date: Sun, 24 Oct 2021 22:18:40 -0400 > > > aaaaaaaaaaaa bbbbbbbb ccccccc xxx xxxxxxxx xxxxxxxxxxxx > > dddddddd eeeeeeee fffffff ggg yyyyyy yyyyyyyyy yyyyyyyy > > hhhhhhhh iiiiiiiiii jjjj kkkk zzzzzzzzz zzzzzzzzzz zzzz > > > where buffer position of the first "xxx" follows the buffer position > > of the last "kkkk"? > > That's exactly what I had in mind. But we should not assume that xxx > are consecutive with kkkk. We could be looking at the middle, vertically, > of the two columns; their top and bottom could be off-screen. Why would that make sense? You will be unable to read the text without scrolling the window. > > If so, where in the above picture are your points > > A and B? > > IF xxx immediately follows kkkk, then point A is at the start of aaaaaaaaaaaa > and point B is at the start of xxx. But then what did you mean by this: > > It could have multiple segments for each display line, and fill up > > one series of segments going vertically down from point A, > > then the next series of segments going vertically down from point B, > > and so on. The "going vertically from A, then vertically from B" is the part I don't understand: what did you mean by "fill up segments by going vertically" here? > > Actually, I believe that any significant improvement in the Emacs > > display engine would almost certainly need a redesign of the buffer > > text data structure, because most current limitations of redisplay > > basically follow from the fact that buffer text is a single > > unstructured stream of bytes > > I can't prove we don't need to do that, but I really hope so. > Changing the display structure would be a rather local change, > while changing the buffer format would be enormous. Why enormous? The internals of buffer text are known to relatively small number of low-level primitives. Making buffer text smarter than a linear byte stream could allow us to know where to jump if the user moves point from "kkk" to the right, with the intent of going to "zzzzzzzzzz", without costly scanning of the buffer while simulating display. IOW, I believe that leaving the buffer text design intact will make redisplay that is already relatively slow in complex situations even slower. That is no way to move Emacs into the future. > I have hope it will be possible to do this without changing the buffer > format, so I suggest trying that first. Well, for starters, how would you record the starting point of the visible portion of each column? wouldn't that already need some change in the window object, if not in the buffer text?