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

[Eli Zaretskii]

> From: chad <address@hidden>
> Date: Fri, 10 Apr 2020 17:05:00 -0700
> Cc: Ihor Radchenko <address@hidden>, Adam Porter <address@hidden>, Yuan Fu 
> <address@hidden>, 
>       Eli Zaretskii <address@hidden>, emacs-devel <address@hidden>
> 
> In particular, the way the found and added caching of line starts seemed like
> something that could help emacs' problems with very long lines, and perhaps 
> also the concerns with parsing
> large files for highlighting and indenting.

I don't think so, because finding the next newline is not the
expensive part of the Emacs redisplay when lines are very long.  In
fact, we look for newlines by calling the memchr library function, and
the result is lightning-fast, because Emacs represents buffer text as
linear array of bytes, and memchr expands to a small number of machine
instructions in an optimized build.  With today's fast CPU clocks,
searching for the next newline in even a very large buffer is a
non-issue.

The expensive part of redisplay is finding the correspondence between
buffer positions and screen coordinates.  Every display update needs
some operation which has to find such correspondence.  For example,
take the simple C-n key, which by default moves to the next visual
line.  Long lines are normally wrapped on display, so the character
below the current one on the next visual line is likely to be some
place in the same physical line, but where exactly is that?  What
Emacs does internally is traverse all the characters after the current
one, calculating their metrics and making pixel-level layout
decisions, including the line wrapping, until it gets to the character
whose screen coordinates indicate it is directly below the current
cursor position.  Then Emacs puts point at that place.  C-p is
similar, but more expensive, because moving back requires to start
from the beginning of a physical line (which might be far away).  C-v
and M-v are also similar, because they need to calculate where to put
the window-start to display the next screen-full of text with some
overlap with what is currently shown.  Etc. etc. -- it is this task of
finding what buffer position corresponds to certain screen coordinates
is what makes redisplay painfully slow when there are very long lines.
Emacs before v21 supported only fixed-pitch fonts, where such
calculations were much easier, but we nowadays support variables fonts
in the same buffer.