From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexandre Garreau Newsgroups: gmane.emacs.devel Subject: Re: Future of display engine and lines Date: Thu, 28 Oct 2021 17:03:37 +0200 Message-ID: <2364365.nKfNrZnynm@galex-713.eu> References: <2108181.AU8Z245p1N@galex-713.eu> <834k952tti.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23844"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 28 17:05:59 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 1mg6yd-000626-3c for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 17:05:59 +0200 Original-Received: from localhost ([::1]:55078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mg6yb-0006b5-8u for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Oct 2021 11:05:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg6wW-0005n7-HP for emacs-devel@gnu.org; Thu, 28 Oct 2021 11:03:48 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:48026 helo=galex-713.eu) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mg6wS-0006wB-2C; Thu, 28 Oct 2021 11:03:48 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mg6wL-0001o2-I4; Thu, 28 Oct 2021 17:03:37 +0200 In-Reply-To: Received-SPF: pass client-ip=2a00:5884:8305::1; envelope-from=galex-713@galex-713.eu; helo=galex-713.eu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:278118 Archived-At: Le jeudi 28 octobre 2021, 14:19:41 CEST Richard Stallman a =C3=A9crit : > [[[ 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. ]]] >=20 > > > > 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. > 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.) I think both need to use a tree, afaik even ncurses uses a tree for such=20 things. > The point is, there is no need to change the representation of buffers. >=20 >=20 > 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. The question is not to have multiple gaps (although that would actually be= =20 useful for some extensions like multiple-cursors (which btw is pretty nice= =20 and emacs is the only editor to support that)), but to fragment the buffer= =20 differently than as a stream. We=E2=80=99re talking about making it a tree. It does not have to be a bin= ary=20 tree of course (most graphical trees aren=E2=80=99t), and insertion as well= as=20 lookup should be as fast as possible, since it=E2=80=99s for editing, so a = gapped- array is still useful, what would be useful is instead to store chars in=20 that array, rather store some recursive datastructure that could be either= =20 again this gapped-array (possibly with metadata such as vertical/ horizontal direction), either something else (a character, an image, any=20 kind of weird-behaving space/glue, etc. like TeX, like TeXmacs, like any=20 web engine, like LibreOffice). So it would be recursive gapped-arrays, that=E2=80=99s different from a gap= ped- array of chars, but there still is one gap, and it works similarly, but=20 the functionality is different: it also stores some fragmentation of the=20 content (possibly none, in the case of plain text). > 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. Modularly in the sense our problem is solvable without having to change=20 the buffer datastructure. But that=E2=80=99s merely because the improvemen= t=20 proposed doesn=E2=80=99t change functionality but efficience, they would me= rely=20 provide a sort of =E2=80=9Ccache=E2=80=9D for certain functions. It would = theorically=20 possible to keep everything modular by =E2=80=9Cadvicing=E2=80=9D (not with= elisp advices,=20 sorry for the confusion, but the comparison comes to my mind) the C=20 datastructure of the buffer with some other separate (hence =E2=80=9Cmodula= r=E2=80=9D)=20 datastructure that=E2=80=99s only used by redisplay, and stores some comput= ation=20 whose value is strictly related to the buffer=E2=80=99s content and its sem= antic. But that=E2=80=99s rather hairy and academic to do. We could just as well= =20 complexify a little the buffer datastructure, or, like I proposed,=20 introduce some new datastructure *in addition* to the legacy buffer, that=20 could be used instead, and be more efficient for graphical redisplay,=20 notably for tree layouts (something non-linear and more complicated than a= =20 2D grid of columns =C3=97 line). And anyway we should store some semantical information (=3D functionality),= =20 somewhere=E2=80=A6 but where would you want to store that? within text prop= erties?=20 with markers (aren=E2=80=99t they slow?)? we=E2=80=99re not anymore talking= about=20 something that=E2=80=99s inconvenient splitting and then rejoining ambiguou= sly,=20 such as face, but a real tree (because we could have (that=E2=80=99s hairy = but=20 imaginable) a multicolumn at the middle of one column of a multicolumn),=20 here emacs need a tree, just as a DOM, just as with overlays, but efficient= ,=20 and very very important to redisplay.