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: Sat, 23 Oct 2021 12:32:01 +0200 Message-ID: <6243432.lqgiAO5IsD@galex-713.eu> References: <2108181.AU8Z245p1N@galex-713.eu> <871r4fhxtd.fsf@gnus.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="35526"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 23 12:33:14 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 1meEKw-00094J-G7 for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 12:33:14 +0200 Original-Received: from localhost ([::1]:56904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meEKv-0005Fc-0w for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Oct 2021 06:33:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meEJv-0004ZM-LC for emacs-devel@gnu.org; Sat, 23 Oct 2021 06:32:11 -0400 Original-Received: from portable.galex-713.eu ([2a00:5884:8305::1]:55672 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 1meEJs-0007kT-TH for emacs-devel@gnu.org; Sat, 23 Oct 2021 06:32:11 -0400 Original-Received: from gal by galex-713.eu with local (Exim 4.92) (envelope-from ) id 1meEJo-000527-1e; Sat, 23 Oct 2021 12:32:04 +0200 In-Reply-To: <871r4fhxtd.fsf@gnus.org> 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:277610 Archived-At: Le jeudi 21 octobre 2021, 05:16:30 CEST Lars Ingebrigtsen a =C3=A9crit : > Alexandre Garreau writes: > > How difficult would it be for emacs to support in-buffer multiple > > columns? > Having support for multiple columns in Emacs would be cool, but it would > be a major undertaking -- it's hard to see how it'd work sensibly > without basically making each buffer somehow consist of many smaller > buffers that are then somehow arranged to be displayed as one window. Oh that=E2=80=99s exactly what I thought initially! But somehow, when I try to explain what I imagine to be necessary, I have=20 a hard time justifying subbuffers like this. Like it=E2=80=99s more a ques= tion of=20 subwindows than subbuffers=E2=80=A6 columns are a purely graphical feature,= while=20 buffers are a semantical one=E2=80=A6 of course the somewhat semantic quest= ion of=20 line/column related to point would have to be questioned in that graphical= =20 disruption, and until now it has been linearly (and modularly,=20 respectively) related to point=E2=80=99s position as a number=E2=80=A6 but = we can still=20 consider that, in the special specific respect of columns (such as css=20 columns), the line/column is a purely graphical feature as well. But a buffer displayed inside another buffer is something I have long- desired as well for different semantic reasons=E2=80=A6 namely: more ergono= mic org=20 source-edit mode, and cleaner implementation of multimodes=E2=80=A6 such as= needed=20 in polyglot files such as php=E2=80=A6 that could *as well* be useful as we= ll for=20 displaying mime parts in gnus/rmail and displaying web pages in eww, where= =20 columns were historically often implemented with frames (for instance our=20 chief gnuisance=E2=80=99s one, well THAT would ideally use a subbuffer), he= nce the=20 confusion maybe=E2=80=A6 unless there is another true reason to reason recu= rsively=20 about buffers? I mean, the change we are talking about is not purely columns, we should=20 be more ambitious and if we gravitate toward something less linear, we=20 could just as well provide the basis for any layout engine in lisp. I mean=E2=80=A6 we=E2=80=99re not gonna allow only one set of columns per b= uffer right?=20 that=E2=80=99d already be totally doable with a special set of windows spli= tting +=20 follow-mode and some meta-mode modifying and keeping track of the frame=E2= =80=99s=20 windows set (I=E2=80=99m sure a dominant such mode already exists)=E2=80=A6= but that=E2=80=99d be=20 semantically ugly because that=E2=80=99s a workaround involving many modeli= nes=E2=80=A6=20 even removing (as already possible) scrollbars, hinges, and reducing the=20 font-size and spacing, I guess that would not be an acceptable way of=20 layoutting a workflow todays (or it would already be done=E2=80=A6 right? h= as it? =E2=80=A6 maybe?) So we=E2=80=99re gonna want to be able to have a set of columns inside a bu= ffer,=20 and another subset of columns inside another column, with several=20 divisions per part of the buffer, and some columns in different font-size=20 than others, hence the line-count in one column wouldn=E2=80=99t match the = one in=20 other ones, and then we would also want to be able to do vertical=20 centering=E2=80=A6 that=E2=80=99s a pretty big overthrow, and not just a ma= tter of greatly=20 complexifying the current display engine just to allow eww to display,=20 select, copy and treat several columns nicely in the simplest setting=E2=80= =A6=20 right?