bug#15841: Display bugs with cache-long-lines non-nil

[Stephen Berman]

On Tue, 12 Nov 2013 18:31:32 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

> I already established that, as you point out, the
> changes to the buffer that cause the problem are indeed made by
> decode-coding-region.  The problem becomes visible when redisplay,
> entered after decode-coding-region finishes its job, re-fontifies
> portions of the buffer that were affected by the changes.  The way
> this affects redisplay is through forward-line and
> line-beginning-position, of which JIT Font Lock is a heavy user.
> That's why you only see the effect after decode-coding-region returns.

Thanks for the explanation.

>> Is it possible to have execution halt when cache_long_scans is
>> checked, and if so, how?
>
> Watchpoints are the answer.  But in this case, there's only one place
> in the whole Emacs where this variable is consulted: in search.c,
> around line 610, so you could just put a breakpoint there.
>
> In any case, I already traced through the code that is involved, and
> the immediate reason for the assertion violation is that the cache
> isn't being updated wrt changes in buffer size (which are caused by
> decoding the stuff brought in by 'ls').  However, a naive attempt to
> force such updates didn't solve the whole problem: the aborts are
> gone, but the infloop is still there, and also other minor display
> issues.  So I guess there's another factor at work there...

Fascinating, what unsuspected and apparently unrelated effects can be
brought to the surface by toggling the value of a variable!

> I also need to figure out how to keep the cache up to date without
> penalizing performance, which would render the cache worthless.
>
>> Or is there a better way to try to track down this bug?
>
> The cache has only 3 public interfaces (see region-cache.c), so it is
> easy to put breakpoints in all of them and see what happens.  That's
> what I did.

Thanks for the advice and for working on this bug.

Steve Berman