GNU bug report logs - #44983
Truncate long lines of grep output

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Tue, 1 Dec 2020 08:56:01 UTC

Severity: normal

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #158 received at 44983 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: dgutov <at> yandex.ru, 44983 <at> debbugs.gnu.org, juri <at> linkov.net
Subject: Re: bug#44983: Truncate long lines of grep output
Date: Sat, 30 Apr 2022 13:15:07 +0300
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: juri <at> linkov.net,  44983 <at> debbugs.gnu.org,  dgutov <at> yandex.ru
> Date: Sat, 30 Apr 2022 11:36:37 +0200
> 
> But before I start trying to debug that, I'm wondering: Why is
> `jit-lock-fontify-now' called at all here?  There have been no display
> changes -- the text was inserted, but as invisible text, so no font
> locking should be necessary.

Are you saying that buffer position 392 was in invisible text?  If so,
jit-lock-fontify-now should not have been called.  But if position 392
is visible, then what you see is expected: the buffer text has
changed, and therefore redisplay will arrange to redisplay the buffer.
Part of redisplaying the buffer is making sure the text that might
wind up on display is fontified.  Which part will actually be on
display can only be known _after_ the text is fontified (because
fontification can change faces, and thus affect what's visible in the
window).  So we always fontify the 500-character chunk, per
jit-lock.el's defaults.

Did I answer your question?




This bug report was last modified 3 years and 19 days ago.

Previous Next


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