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: Future of display engine and lines Date: Wed, 20 Oct 2021 15:27:19 +0200 Message-ID: <2108181.AU8Z245p1N@galex-713.eu> 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="8570"; mail-complaints-to="usenet@ciao.gmane.io" To: Emacs Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 20 15:28:48 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 1mdBeB-00024V-8E for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Oct 2021 15:28:47 +0200 Original-Received: from localhost ([::1]:47518 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mdBeA-0008S3-7X for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Oct 2021 09:28:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34450) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mdBcs-0007YV-J7 for emacs-devel@gnu.org; Wed, 20 Oct 2021 09:27:26 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:57154 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 1mdBcq-0005LY-TE for emacs-devel@gnu.org; Wed, 20 Oct 2021 09:27:26 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1mdBcm-00079W-1O for emacs-devel@gnu.org; Wed, 20 Oct 2021 15:27:20 +0200 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:277446 Archived-At: I=E2=80=99ve a question. Given these time I see some discussions about the display engine (notably=20 faces, svg, pointer drawing, and more in-emacs GUI discussion, etc.), and=20 I=E2=80=99ve already seen ---without prior work--- ambitious suggestions se= riously=20 made here before (like to make emacs a text processor on par with=20 LibreOffice (or, who knows, GNU TeXmacs ;))), as well as ---without=20 ambitious suggestion--- ambitious work seriously made such as integrating=20 gtk widgets=E2=80=A6 Given eww is pretty advanced for what it is (an one-man browser made as an= =20 extension (instead of the opposite) and likely one of the most advanced=20 textual www browsers out there)=E2=80=A6 How difficult would it be for emacs to support in-buffer multiple columns?= =20 such as LibreOffice would be able to. Such as it is necessary for a more=20 readable and usable web browser (eww actually supports columns but the=20 same line of two different columns is on the same line of the buffer, so yo= u=20 cannot move linearly with text nor select consistently linear text (like=20 on some broken pdf viewers)). Such as it would make waaay more usable=20 multiple-lines row in the org-mode tables. Such as it would make reading=20 on emacs, without having to use several windows, way more efficient compare= d=20 with the useful usage ratio of the screen surface (given an optimal line=20 is 66 chars or (unless reading boustrophedonly) moving eyes at each time=20 because more tiring and make more time lost)? Would it even be relevant? or would something such as =E2=80=9Cdisplaying o= ne=20 window/buffer inside another buffer/window=E2=80=9D be more useful? And how would it be to support multiple-lines inside one line, such as=20 with fractions? The concept looks similar to me: you need to cut a=20 graphical line in the first case, and a logical one in the later. I don=E2= =80=99t=20 know how the line/column/point-pos would be calculated in such a=20 situation. What I=E2=80=99d like is the ability to see a well-layouted fra= ction=20 and at the same time moving the cursor inside it and editing/selecting=20 parts of the text at the numerator or denominator, such as on scientifical= =20 calculators. Currently that=E2=80=99s not possible even with org-mode late= x- fragments previews. I have really hardly an idea of how would such a thing look, so I=E2=80=99m= very=20 curious about what more experienced and aknowledged-about-emacs-core=20 people would think about it=E2=80=A6