[Top][All Lists]

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

Re: redisplay - very long lines

From: grischka
Subject: Re: redisplay - very long lines
Date: Wed, 18 Feb 2009 21:41:32 +0100
User-agent: Thunderbird (Windows/20070221)

Eli Zaretskii wrote:
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.

The buffer text itself is not the only data to control the display, there
are also properties that refer to regions of that text, and in fact that
is the part that matters here.  It is certainly possible to check for at
least the presence of extra properties in a line without walking each
character one by one.

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]