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: Thu, 28 Oct 2021 08:19:41 -0400 Message-ID: References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.org> <83r1cc5i8p.fsf@gnu.org> <834k952tti.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="16562"; 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 Thu Oct 28 14:21:47 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 1mg4Pi-00045X-PC for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 14:21:46 +0200 Original-Received: from localhost ([::1]:42344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mg4Ph-00033X-GL for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 08:21:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg4Nj-0000jL-Ta for emacs-devel@gnu.org; Thu, 28 Oct 2021 08:19:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46448) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg4Nj-0002HV-19; Thu, 28 Oct 2021 08:19:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=WO9ikx7oHPLjE/qreohU7jkI/AAtAVpxLINDMSF+ZCo=; b=HXv52q07rE+l xcf9hubocv7uvwLN+pMKgUidp74D8ZQpkYZJmABqgtXT7Naum7iH6tFN5aFGGTka6GRNVd8BFyC7s hq+3qh1To/BZdUzC7sr6ZUnZymXqdaTzLYhHZJN1/B8SU24ImJT7G+QUR29w3sDQ6aNHpzVmEJ8jg FAdajspWJlD3LNLvY56sM4RIXY0Ogz73hzDitI1zuy4EMLySCp1yZisUownWbZl7LZAWSVt5RIJNG JqV7gcSM+skIaJAm8ouqxerYs37qy17PkX0ByT3eV+HR62saDCNMq5iFGVBWE9kEg/S963R4LbiXF aCcp2skn7MvINOiWStO3Yw==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1mg4Nh-0000Dg-2T; Thu, 28 Oct 2021 08:19:41 -0400 In-Reply-To: <834k952tti.fsf@gnu.org> (message from Eli Zaretskii on Mon, 25 Oct 2021 15:05:29 +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:278089 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. > 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? I am struggling to find precise words about this abstract point. Imagine that one region of the buffer is displayed in two side-by-side columns. The top of the window is in that region. To redisplay it, display needs to know where in the buffer each column starts. For the second column, it also needs to know how many screen lines (or how much screen height) is off the top of the window. It can fill up the first column's rectangle by processing text linearly from the window start, line by line, and putting the result into the correct part of each screen line. It can fill up the second column's rectangle by processing text linearly from the proper place in the buffer (where the right column text should start), line by line, and putting the result into the correct part of each screen line. I am thinking about non-graphics terminals. For graphics terminals, the data structure will have to be different. (They already use a different data structure.) The point is, there is no need to change the representation of buffers. In principle there might be a more efficient representation of buffers. But I am skeptical about that. When I tried to look for a better representation that would allow for multiple gaps, I couldn't see a good answer about how to use them and gain any benefits. I am simply trying to argue that the buffer representation and the redisplay algorithm are modularly separate. We can keep the issues separate and this issue much simpler. -- 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)