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

[Dmitrii Korobeinikov]

> Why does it matter how many times BYTE_POS_ADDR is used?  If you
> change the implementation of BYTE_POS_ADDR, the replacement is a
> mechanical job, no matter if there are 8 places or 800 to make the
> change.

True, but BYTE_POS_ADDR turns out to be a bad example and not a good
estimator of the needed changes at all, since it's a part of the
interface. I only now looked and saw it was a function and not a
field.

But, for instance, GPT is, because extra logic needs to be written to
accomodate multiple GPTs (one for the buffer, and one for each of the
referenced buffers recursively).

To give an example, search.c has this lines:

> p1 = BEGV_ADDR;
> s1 = GPT_BYTE - BEGV_BYTE;
> p2 = GAP_END_ADDR;
> s2 = ZV_BYTE - GPT_BYTE;

This would need to turn into an array of n boundaries, instead of 2.
And re_match_2 would need to become a re_match_n.

Next, indent.c L362:

>  else if (PT <= GPT || BEGV > GPT)

But there isn't just one GPT now, so, expect changes around this place as well.

I didn't look at the code very thoroughly, but I am pretty sure other
places aren't too different. Besides GPT, obviously, boundaries of the
referenced buffers now have to be accounted for, with their contents.
A supposedly ordinary loop job, but still. All of these changes are
conceptually simple, but do involve a bunch of legwork.

There are some exceptions of course. Like "where to insert a character
at the boundary", mentioned above. One natural solution for this, by
the way, could be to simply look at the previous position of the
point, i.e. if the boundary was approached from the right, insert to
the rightmost buffer.

сб, 11 апр. 2020 г. в 14:26, Eli Zaretskii <address@hidden>:
>
> > From: Dmitrii Korobeinikov <address@hidden>
> > Date: Sat, 11 Apr 2020 13:56:07 +0600
> > Cc: Ihor Radchenko <address@hidden>, Yuan Fu <address@hidden>, 
> > address@hidden,
> >       emacs-devel <address@hidden>
> >
> > By "unified core interface", I meant something like an OOP-style
> > public interface done in a way so the users don't have to know about
> > the implementation and underlying data structures
>
> You will find that in buffer.h.  Modify those interfaces, and you are
> done.
>
> > > > 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.
> > >
> > > How so?  The display code accesses the buffer text directly, using
> > > BYTE_POS_ADDR.
> >
> > I didn't say it wouldn't have to be touched at all : ) xdisp.c has
> > only 8 occurences of BYTE_POS_ADDR, that doesn't appear too bad.
>
> Why does it matter how many times BYTE_POS_ADDR is used?  If you
> change the implementation of BYTE_POS_ADDR, the replacement is a
> mechanical job, no matter if there are 8 places or 800 to make the
> change.