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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43651 in the body.
You can then email your comments to 43651 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: David Landell <david.landell <at> sunnyhill.email>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; compile.el should not parse its own header for errors
Date: Sun, 27 Sep 2020 12:45:24 +0200

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

Hi,

I noticed that compilation-mode parses and successfully detect errors
according to set regexp int the compilation buffer header, iow in text
inserted by the mode itself. This is weird since there isn't any error
there to visit.

Reproduce: emacs -Q -l reproduce.el

Expected output:
No error fontification of header line: Compilation started at Sun Sep 27 11:48:24

Actual output:
Error fontified line: Compilation started at Sun Sep 27 11:48:24

I noticed this in my own package rg.el which is similar to grep.el in
that it reuses compilation mode and has similar regexps for parsing
file name and line number that happens to match the "$CMD started at..."
line. The attached test case somewhat emulates what happens in those
packages. The command output is unrelated though.

Looking at the code in compile.el, my impression is that this would be
taken care of by compilation-filter but for some reason that doesn't happen.

Best regards,
David Landell

[reproduce.el (application/emacs-lisp, attachment)]

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

In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10)
 of 2020-09-19 built on lgw01-amd64-054
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Compilation finished
Making completion list... [2 times]

Configured using:
 'configure --build=x86_64-linux-gnu --prefix=/usr
 '--includedir=${prefix}/include' '--mandir=${prefix}/share/man'
 '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var
 --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu'
 '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode
 --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --program-suffix=27 --with-modules --with-file-notification=inotify
 --with-mailutils --with-harfbuzz --with-json --with-x=yes
 --with-x-toolkit=gtk3 --with-lcms2 --with-cairo --with-xpm=yes
 --with-gif=yes --with-gnutls=yes --with-jpeg=yes --with-png=yes
 --with-tiff=yes --with-xwidgets 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs27-YwD3ZV/emacs27-27.1~1.git86d8d76aa3=. -fstack-protector-strong
 -Wformat -Werror=format-security -no-pie' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro
 -no-pie''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_MONETARY: sv_SE.UTF-8
  value of $LC_NUMERIC: sv_SE.UTF-8
  value of $LC_TIME: sv_SE.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
compile comint ansi-color ring tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 49811 10033)
 (symbols 48 6530 1)
 (strings 32 16934 2193)
 (string-bytes 1 560626)
 (vectors 16 10055)
 (vector-slots 8 133282 9060)
 (floats 8 23 180)
 (intervals 56 311 4)
 (buffers 1000 13))

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

From: David Landell <david.landell <at> sunnyhill.email>
To: 43651 <at> debbugs.gnu.org
Subject: Re: bug#43651: Acknowledgement (27.1; compile.el should not parse
 its own header for errors)
Date: Sun, 27 Sep 2020 18:56:10 +0200

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

Sorry, the test case regexp was not crafted for reproducibility so
attaching a new that should be independent of the current time.

[reproduce.el (application/emacs-lisp, attachment)]

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

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

David Landell <david.landell <at> sunnyhill.email> writes:

> Expected output:
> No error fontification of header line: Compilation started at Sun Sep
> 27 11:48:24
>
> Actual output:
> Error fontified line: Compilation started at Sun Sep 27 11:48:24

I can reproduce this in Emacs 28, too, and I'm not sure how to fix it.
You'd think there'd be a way to tell the font-locking mechanism (which I
assume is used here?) to stay away from certain regions of the buffer,
but reading the documentation, I couldn't find anything.

But there surely must be.  Anybody know?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: David Landell <david.landell <at> sunnyhill.email>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43651 <at> debbugs.gnu.org
Subject: Re: 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)]

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

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

David Landell <david.landell <at> sunnyhill.email> writes:

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

Thanks for the analysis -- your patch was basically correct, I think,
but a bit brittle.  Instead of doing the marking with a variable, I've
now made compile mark the end of the header with a text property, and
that's then used to find the end of the header when pasing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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