From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Future of display engine and lines Date: Sun, 24 Oct 2021 22:18:40 -0400 Message-ID: References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.org> <83r1cc5i8p.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6935"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, galex-713@galex-713.eu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 25 04:20:53 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 1mepbX-0001en-UF for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Oct 2021 04:20:51 +0200 Original-Received: from localhost ([::1]:50808 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mepbW-0003W1-Ob for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Oct 2021 22:20:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57436) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mepZQ-0000yk-Sz for emacs-devel@gnu.org; Sun, 24 Oct 2021 22:18:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51492) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mepZQ-0001tb-Ju; Sun, 24 Oct 2021 22:18:40 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1mepZQ-0006gC-DT; Sun, 24 Oct 2021 22:18:40 -0400 In-Reply-To: <83r1cc5i8p.fsf@gnu.org> (message from Eli Zaretskii on Sat, 23 Oct 2021 10:10:30 +0300) 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:277698 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > 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"? 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. 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 suppose that these two columns actually start 5 libes above aaaaaaaaaaaa and xxx, and those lines are scrolled off the top of the window. This means that xxx does not follow kkkk in the buffer text. Rather, kkkk is followed by some more lines below (off the window below) and a few more lines that are above xxx... (off the window above). In that case point A is at the start of the five lines above aaaaaaaaaaaa, abd point B is at the start of the five lines above xxx. > 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. I have hope it will be possible to do this without changing the buffer format, so I suggest trying that first. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)