GNU bug report logs - #43651
27.1; compile.el should not parse its own header for errors

Previous Next

Full log

View this message in rfc822 format

From: David Landell <david.landell <at> sunnyhill.email>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43651 <at> debbugs.gnu.org
Subject: bug#43651: 27.1; compile.el should not parse its own header for errors
Date: Mon, 28 Sep 2020 16:40:45 +0200

[Message part 1 (text/plain, inline)]

Hi,
This is actually not restricted to font locking as demonstrated by the
test case. My initial report was a bit unclear about that. It also
affects settings like:

(setq compilation-scroll-output 'first-error)

where the jump is done to the header instead of first error. My
impression from reading the code is that we would want to avoid running
(compilation--parse-region) on the header to avoid problems like this.
I am attaching a patch that superficially seems to fix these issues.
I have a hard time judging if this fix has any bad side effects or
similar though.

I am definitely missing a bit of context how the related functions are
invoked. In testing of my own package I have seen what seems to be
multiple rounds of font locking that erase previous rounds, probably
coming from buffer changes in my downstream filter-function. In that
setup, the jump to first error has been a more stable way of reproducing.

/David

[0001-Don-t-parse-compilation-buffer-header-for-errors.patch (text/x-diff, attachment)]

Previous Next

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