[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50207: 28.0.50; ansi-color-compilation-filter and rgrep
From: |
Augusto Stoffel |
Subject: |
bug#50207: 28.0.50; ansi-color-compilation-filter and rgrep |
Date: |
Thu, 08 Dec 2022 23:34:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
On Fri, 27 Aug 2021 at 09:06, Juri Linkov wrote:
>>> - (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.
Or at least I was having this kind of issue in the `grep-heading-mode'
suggested in a recent ticket. :-)