[Top][All Lists]

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

Re: redisplay - very long lines

From: Eli Zaretskii
Subject: Re: redisplay - very long lines
Date: Tue, 17 Feb 2009 21:37:10 +0200

> Date: Tue, 17 Feb 2009 18:16:10 +0100
> From: grischka <address@hidden>
> CC:  address@hidden
> > If we can tolerate an incorrect display, maybe.  The invisible part of
> > the line could in principle include characters and faces whose
> > presence may have global effects on the rest of the displayed portion,
> > such as faces that use larger fonts, to say nothing of inline images.
> That is not a necessary consequence at all.
> After all faces and images don't come fallen from outer space into
> the text but if they exist then it was the emacs program itself that
> has put them there.  So instead of scanning lines each time it could
> as well just remember where and how big they are.

AFAIU, you are talking about a complete redesign and rewrite not only
of the Emacs display engine, but also of one of the most important
parts of its top-level design, because in the current design code that
modifies buffers and code that displays them are almost completely
decoupled, i.e. there's almost no control flow between them, and the
only data flow is thru the buffer text itself.

IOW, under the current design, Lisp application code modifies buffers,
and then, when Emacs is idle, redisplay kicks in, walks the buffers,
decides which parts need to be redisplayed (by comparing the current
and the new display contents), and finally redraws those parts.  This
way, the code that works with buffer text knows (almost) nothing about
display, and the code that displays knows (almost) nothing about

reply via email to

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