Re: Request for pointers and advice: displaying several buffers inside a single window

[Dmitrii Korobeinikov]

> Following mode plus atomic windows seems doable. But it wouldn’t be
> transparent, AFAIK follow-mode needs to add special handlers for
> things like isearch and query-replace. OTOH, it would be much more
> difficult to implement in xdisp.c. I wonder if there is an
> intermediate layer that’s higher level than redisplay (in lisp, or at
> least not in redisplay) but still more or less transparent.

I have come to the conclusion that extending the underlying data
structure for the storage is unavoidable and, really, the simplest +
most efficient method to achieve transclusion / islands / seamless
mode regions / buffer lenses / whatever, and to avoid having to deal
with a whole lotta bugs, corner cases and synchronization trickery.

Emacs uses gap buffer for storing text (a c array with some semantics,
basically). What I have in mind is to keep it that way, but to have a
list of references to other buffers along with their intended
positions.

>From what I saw, there's not a unified core interface on top of that c
array. So, would need to modify each place that makes a use of it.
(for a couple of examples, see text_outside_line_unchanged_p in
xdisp.c, looking_at_1 in search.c)

I tried to eyeball the effected landscape by looking at where GPT
(position of the gap) is referenced. There are 287 occurences of GPT
in the src directory, most of them are in buffer.c, buffer.h,
insdel.c. The distribution is: coding.c(24), syntax.c(10),
changelog(17), xdisp(8), insdel(131), buffer(35),
editfns/fns/w32xfns(11), search(7), marker(6), xml(1), charset(3),
composite(3), decompress(1), pdumper(1), process(1), character(3),
json(1), fileio(11), indent(3), sysdep(2).

The good news is: I believe xdisp.c wouldn't have to be modified all
that much if the regions are enforced to start on different lines.

This whole ordeal could easily take a few months. I, unfortunately, am
unlikely to find the time to do it this year.

PS A possibly useful outcome of this is the possibility to mitigate
extremely long gap motions by breaking up a big buffer into several
smaller ones.

пт, 10 апр. 2020 г. в 21:38, Ihor Radchenko <address@hidden>:
>
> > Following mode plus atomic windows seems doable. But it wouldn’t be
> > transparent, AFAIK follow-mode needs to add special handlers for
> > things like isearch and query-replace. OTOH, it would be much more
> > difficult to implement in xdisp.c. I wonder if there is an
> > intermediate layer that’s higher level than redisplay (in lisp, or at
> > least not in redisplay) but still more or less transparent.
>
> What about extending the idea of indirect buffers? In indirect buffers,
> the buffer strings are associated with the same memory address storing
> the text (if I understand correctly). Similar thing (theoretically) can
> be done for individual segments of text. Indeed, there will still be a
> question on how the fontification is done, if the overlays should be
> shared, and how the key bindings should behave on such segments, but the
> basic functionality of automatically sharing text segments between
> buffers may be a good framework to start considering more complicated
> cases.
>
> Best,
> Ihor
>
> Yuan Fu <address@hidden> writes:
>
> > Following mode plus atomic windows seems doable. But it wouldn’t be 
> > transparent, AFAIK follow-mode needs to add special handlers for things 
> > like isearch and query-replace. OTOH, it would be much more difficult to 
> > implement in xdisp.c. I wonder if there is an intermediate layer that’s 
> > higher level than redisplay (in lisp, or at least not in redisplay) but 
> > still more or less transparent.
> >
> > Yuan
>
> --
> Ihor Radchenko,
> PhD,
> Center for Advancing Materials Performance from the Nanoscale (CAMP-nano)
> State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong 
> University, Xi'an, China
> Email: address@hidden, address@hidden