[Top][All Lists]
[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
- Inefficient redisplay, Stefan Monnier, 2010/04/12
- Re: Inefficient redisplay, Eli Zaretskii, 2010/04/12
- Re: Inefficient redisplay, Stefan Monnier, 2010/04/12
- Re: Inefficient redisplay, Eli Zaretskii, 2010/04/12
- Re: Inefficient redisplay, Stefan Monnier, 2010/04/12
- Re: Inefficient redisplay, Eli Zaretskii, 2010/04/13
- Re: Inefficient redisplay, Eli Zaretskii, 2010/04/14
- Re: Inefficient redisplay, Stefan Monnier, 2010/04/15
- Re: Inefficient redisplay, Eli Zaretskii, 2010/04/15
- Re: Inefficient redisplay,
Stefan Monnier <=