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

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 15841@debbugs.gnu.org
> Date: Tue, 12 Nov 2013 11:03:47 +0100
> 
> > I tracked the problematic fontification and motion behavior to
> > insert-directory in files.el: it happens during the loop when
> > decode-coding-region is called on the file names of the subdirectory
> > entries.  I stepped through the code with Edebug but could not tell why
> > it goes wrong here, and I'm too tired to pursue it further now.  Also,
> > when I step through this code, the "available" information is added at
> > the end of the entire subdirectory listing, unlike what I observed above
> > when just invoking `i' and then `C-g'.  I guess this is due to the
> > interaction of redisplay with stepping through the code; it's still
> > clear that the subdirectory listing is being treated as part of the line
> > containing the `..' entry.
> 
> I set a breakpoint on decode_coding_object and stepped through it after
> invoking `i', but the Dired display changed to show the problematic
> fontification only upon exiting decode_coding_object.  I don't know how
> to find out when cache_long_scans is checked other than manually tracing
> the call chains of each subroutine of decode_coding_object, which is too
> laborious.

There's no need: 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.

> 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...

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.