[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future of display engine and lines

From: Alexandre Garreau
Subject: Re: Future of display engine and lines
Date: Sat, 23 Oct 2021 12:32:01 +0200

Le jeudi 21 octobre 2021, 05:16:30 CEST Lars Ingebrigtsen a écrit :
> Alexandre Garreau <galex-713@galex-713.eu> 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’s exactly what I thought initially!

But somehow, when I try to explain what I imagine to be necessary, I have 
a hard time justifying subbuffers like this.  Like it’s more a question of 
subwindows than subbuffers… columns are a purely graphical feature, while 
buffers are a semantical one… of course the somewhat semantic question of 
line/column related to point would have to be questioned in that graphical 
disruption, and until now it has been linearly (and modularly, 
respectively) related to point’s position as a number… but we can still 
consider that, in the special specific respect of columns (such as css 
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… namely: more ergonomic org 
source-edit mode, and cleaner implementation of multimodes… such as needed 
in polyglot files such as php… that could *as well* be useful as well for 
displaying mime parts in gnus/rmail and displaying web pages in eww, where 
columns were historically often implemented with frames (for instance our 
chief gnuisance’s one, well THAT would ideally use a subbuffer), hence the 
confusion maybe… unless there is another true reason to reason recursively 
about buffers?

I mean, the change we are talking about is not purely columns, we should 
be more ambitious and if we gravitate toward something less linear, we 
could just as well provide the basis for any layout engine in lisp.

I mean… we’re not gonna allow only one set of columns per buffer right? 
that’d already be totally doable with a special set of windows splitting + 
follow-mode and some meta-mode modifying and keeping track of the frame’s 
windows set (I’m sure a dominant such mode already exists)… but that’d be 
semantically ugly because that’s a workaround involving many modelines… 
even removing (as already possible) scrollbars, hinges, and reducing the 
font-size and spacing, I guess that would not be an acceptable way of 
layoutting a workflow todays (or it would already be done… right? has it? …

So we’re gonna want to be able to have a set of columns inside a buffer, 
and another subset of columns inside another column, with several 
divisions per part of the buffer, and some columns in different font-size 
than others, hence the line-count in one column wouldn’t match the one in 
other ones, and then we would also want to be able to do vertical 
centering… that’s a pretty big overthrow, and not just a matter of greatly 
complexifying the current display engine just to allow eww to display, 
select, copy and treat several columns nicely in the simplest setting… 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]