GNU bug report logs - #15841
Display bugs with cache-long-lines non-nil

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15841 <at> debbugs.gnu.org
Subject: bug#15841: Display bugs with cache-long-lines non-nil
Date: Tue, 12 Nov 2013 22:34:43 +0100

On Tue, 12 Nov 2013 18:31:32 +0200 Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.