emacs-devel
[Top][All Lists]
Advanced

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

Re: Inefficient redisplay


From: Stefan Monnier
Subject: Re: Inefficient redisplay
Date: Thu, 15 Apr 2010 13:34:35 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

> post-command-hook also invokes nhexl-jit, albeit with different
> arguments.  So you may end up doing double work.

That is true.  But I don't know how to avoid it, and I don't think this
redundancy is a big problem in practice.

> Is it really the case that modifying an overlay string does not
> trigger redisplay?  That'd be a bug.

If it works I don't know how it's implemented.  But I haven't actually
tried it anyway.

>> > If invoking nhexl-jit via fontification-functions is really needed,
>> > then where do you expect redisplay to invoke it?  IOW, if you make
>> > assumptions regarding the value of START and END arguments passed to
>> > nhexl-jit by redisplay, what are those assumptions?
>> 
>> I don't make any particular assumptions about start and end (at least
>> not consciously).

> But then you should be aware that there's nothing in
> fontification-functions or in the redisplay that makes sure they are
> only invoked on the displayed portion of the buffer.

Indeed, and the nhexl-jit part of the code itself doesn't make any such
assumption: it just fontifies whatever jit-lock deems useful/necessary.

The part where I make such an assumption (which turns out to be
unwarranted because of the bug we're tracking) is in
nhexl-flush-overlays where I assume that I can throw away the overlays
that are currently not displayed without causing them to be immediately
rebuilt by jit-lock.

> As your C-v experiment proves, it really happens that nhexl-jit is
> invoked on portions of the buffer that are outside the window.
> And since nhexl-jit does not validate its arguments against window's
> first and last line, it ends up doing unnecessary work.

When jit-lock asks for part of a buffer to be fontified, it would be
a bug for nhexl-jit (or font-lock-fontify-buffer for that matter) to not
fontify it (because the corresponding piece of text is then labeled as
`fontified' and if it gets displayed later on jit-lock won't be
triggered so nhexl-jit won't have a chance to change its mind and
fontify it after all).
So it's not up to nhexl-jit to decide whether it's necessary or not.


        Stefan




reply via email to

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