GNU bug report logs - #50207
28.0.50; ansi-color-compilation-filter and rgrep

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Jim Porter <jporterbugs <at> gmail.com>, Manuel Uberti <manuel.uberti <at> inventati.org>, 50207 <at> debbugs.gnu.org
Subject: bug#50207: 28.0.50; ansi-color-compilation-filter and rgrep
Date: Fri, 09 Dec 2022 09:20:35 +0200

>>>> - (add-hook 'compilation-filter-hook #'ansi-color-compilation-filter)
>>>
>>> I encountered this a bit ago, and did a bit of diagnosis, but it ended up
>>> on my back-burner. I think the issue is due to how the
>>> compilation-filter-hooks for grep and ansi-color interact. `grep-filter' is
>>> fairly simple and wants to see both the start and end of an ANSI-colorized
>>> region, so it "rewinds" to the beginning of a line every time it's
>>> called. `ansi-color-compilation-filter', on the other hand, is smart enough
>>> to handle the case where it only sees the start of a colorized region in
>>> one call, and the end in the next call (see `ansi-color-context' for
>>> details).
>>
>> Would it be possible to solve the problem by adding a new buffer-local
>> variable (disabled by default) that will enable line mode for
>> `ansi-color-compilation-filter' so that it will handle only complete lines
>> like grep mode does?
>
> To complement this a bit, my hunch is that the problem is due to
> `compilation-filter-start' being a number and not a marker (bug?).  When
> `grep-filter' deletes some characters between `compilation-filter-start'
> and the beginning of its line, it causes `ansi-color-compilation-filter'
> to skip treating a portion of the buffer.

Have you tried to replace a number with a marker?  Does it help to fix
this bug?

Previous Next

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