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: Sat, 23 Oct 2021 10:10:30 +0300 Message-ID: <83r1cc5i8p.fsf@gnu.org> References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36515"; 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 Sat Oct 23 09:11:25 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 1meBBc-0009JC-6b for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 09:11:24 +0200 Original-Received: from localhost ([::1]:57214 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meBBa-00009x-5D for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 03:11:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40640) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meBB5-0007tc-HI for emacs-devel@gnu.org; Sat, 23 Oct 2021 03:10:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53232) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meBB4-0006Pv-Af; Sat, 23 Oct 2021 03:10:50 -0400 Original-Received: from [87.69.77.57] (port=4741 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 1meBAx-0007QK-IQ; Sat, 23 Oct 2021 03:10:44 -0400 In-Reply-To: (message from Richard Stallman on Fri, 22 Oct 2021 19:47:13 -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:277594 Archived-At: > From: Richard Stallman > Date: Fri, 22 Oct 2021 19:47:13 -0400 > Cc: galex-713@galex-713.eu, emacs-devel@gnu.org > > Buffer display currently works with a structure which is a series of > display lines. On a graphics display, each window has its own set of > display lines, Redisplay fills in the window's display lines top to > botton based on the text in the buffer. That's correct. > 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. Perhaps I misunderstand what "multiple columns" mean, then. Doesn't it mean that buffer text is displayed in separate rectangular portions, like this: 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"? If so, where in the above picture are your points A and B? > It would be considerable work, but it would not require much change > in the data structure of a buffer itself. 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 (forget about the gap, it's immaterial for this purpose). So if we are going to enhance the display engine, I'd be for redesigning the buffer text first and foremost, and in that redesign allow up front intrinsic support for some display features such as this one.