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

[Dmitrii Korobeinikov <dim1212k@gmail.com>]

> > 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'm not sure why you came to that conclusion.  Emacs's internals
> access buffer text directly when needed, for speed.  Interfaces like
> BEG_UNCHANGED/END_UNCHANGED, BYTE_POS_ADDR, GPT, and others are no
> less "core interfaces" for accessing buffer text than functions in
> insdel.c.  I would even consider insdel.c as a layer _above_ the
> low-level interfaces such as BYTE_POS_ADDR.

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, in which case
modifications could've been simpler. I am not saying that's what it
should have been or even could have been, just stating the fact that a
different approach is used.

> Emacs's internals
> access buffer text directly when needed, for speed.

That's exactly the point I was making.

> > 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.

BTW What I am not sure about is if "different lines" enforcement would
make for a noticeably easier implementation, now I am thinking, it
probably wouldn't matter that much.

сб, 11 апр. 2020 г. в 13:30, Eli Zaretskii <eliz@gnu.org>:
>
> > From: Dmitrii Korobeinikov <dim1212k@gmail.com>
> > Date: Sat, 11 Apr 2020 01:09:08 +0600
> > Cc: Yuan Fu <casouri@gmail.com>, adam@alphapapa.net, Eli Zaretskii <eliz@gnu.org>,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> > >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'm not sure why you came to that conclusion.  Emacs's internals
> access buffer text directly when needed, for speed.  Interfaces like
> BEG_UNCHANGED/END_UNCHANGED, BYTE_POS_ADDR, GPT, and others are no
> less "core interfaces" for accessing buffer text than functions in
> insdel.c.  I would even consider insdel.c as a layer _above_ the
> low-level interfaces such as BYTE_POS_ADDR.
>
> And looking_at_1 does what it does because it needs to pass buffer
> text as 2 C 'char' arrays to regex routines, so I don't think it's any
> evidence to anything.  It's just a trick to pass non-contiguous text
> to a function that needs contiguous text.
>
> > 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.