GNU bug report logs - #61093
Indented file names confuse compilation buffer

Previous Next

To reply to this bug, email your comments to 61093 AT debbugs.gnu.org.

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

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

From: Sascha Ziemann <ceving <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Indented file names confuse compilation buffer
Date: Fri, 27 Jan 2023 12:11:14 +0100

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

The Go compiler indents sometimes filenames. I have attached a
htmlfontified compilation buffer showing this. It also shows that the
parser of the compilation buffer gets confused by this. The
problematic line is:

"    ./config.go:10:5: other declaration of config_file"

Some code thinks the whole line is a file name, because the whole line
is a hyperlink (underlined).

Some other code thinks only the beginning of the line is a file name
(red). But this part also thinks the line number is part of the file
name and marks the column number as line number (purple).

I think it might be ok to ignore leading whitespace, because file
names do not start very often with whitespace.

[compilation.html (text/html, attachment)]

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: 61093 <at> debbugs.gnu.org
Cc: Sascha Ziemann <ceving <at> gmail.com>
Subject: bug#61093: Indented file names confuse compilation buffer
Date: Fri, 27 Jan 2023 15:34:44 +0100

> I think it might be ok to ignore leading whitespace, because file
> names do not start very often with whitespace.

The story goes like this: a tool uses a modification of the GNU message format and its users then expect Emacs to conform to that variant.

The problem with doing that is that each little tweak makes the compilation message rules less robust and more likely to collide with one another and become slower. There are about 60 regexps now, most of which are used by very few people, and we keep adding. Build logs can become quite long so performance is not unimportant.

Maybe it's safe to accept and ignore not arbitrary leading whitespace but a single tab, which your tool seems to emit. Or you could ask those making it to cease emitting the tab.

You could also put your own rule in compilation-regexp-alist. It might look like this:

;; Message pattern for ancillary locations (notes) from the Go compiler
(let ((rule
       `(go-note
         ,(rx bol "\t"
              (group                    ; 1: hyperlink
               (group                    ; 2: file
                (not (in " \t\n:"))
                (* (not (in "\t\n"))))
               ":"
               (group (+ digit))         ; 3: line
               ":"
               (group (+ digit))         ; 4: column
               ":")
              " "
              (+ nonl))                ; message
          2 3 4 0 1)))
  (setq compilation-error-regexp-alist-alist
        (remq (assq 'go-note compilation-error-regexp-alist-alist)
              compilation-error-regexp-alist-alist))
  (push rule compilation-error-regexp-alist-alist)
  (setq compilation-error-regexp-alist
        (remq 'go-note compilation-error-regexp-alist))
  (push 'go-note compilation-error-regexp-alist))

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

From: Rudolf Schlatte <rudi <at> constantly.at>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#61093: Indented file names confuse compilation buffer
Date: Fri, 27 Jan 2023 17:23:52 +0100

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

>> I think it might be ok to ignore leading whitespace, because file
>> names do not start very often with whitespace.
>
> The story goes like this: a tool uses a modification of the GNU message format and its users then expect Emacs to conform to that variant.
>
> The problem with doing that is that each little tweak makes the compilation message rules less robust and more likely to collide with one another and become slower. There are about 60 regexps now, most of which are used by very few people, and we keep adding. Build logs can become quite long so performance is not unimportant.
>
> Maybe it's safe to accept and ignore not arbitrary leading whitespace but a single tab, which your tool seems to emit. Or you could ask those making it to cease emitting the tab.
>
> You could also put your own rule in compilation-regexp-alist. It might look like this:
>
> ;; Message pattern for ancillary locations (notes) from the Go compiler
> (let ((rule
>        `(go-note
>          ,(rx bol "\t"
>               (group                    ; 1: hyperlink
>                (group                    ; 2: file
>                 (not (in " \t\n:"))
>                 (* (not (in "\t\n"))))
>                ":"
>                (group (+ digit))         ; 3: line
>                ":"
>                (group (+ digit))         ; 4: column
>                ":")
>               " "
>               (+ nonl))                ; message
>           2 3 4 0 1)))
>   (setq compilation-error-regexp-alist-alist
>         (remq (assq 'go-note compilation-error-regexp-alist-alist)
>               compilation-error-regexp-alist-alist))
>   (push rule compilation-error-regexp-alist-alist)
>   (setq compilation-error-regexp-alist
>         (remq 'go-note compilation-error-regexp-alist))
>   (push 'go-note compilation-error-regexp-alist))

Is there a way for an emacs mode to add mode-specific values to
compilation-error-regexp-alist(-alist)?  If a major mode starts
compilation, presumably it knows the error message format and could set
up that one compilation buffer accordingly without having to add to
global error message parsing.

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

From: Rudolf Adamkovič <salutis <at> me.com>
To: Sascha Ziemann <ceving <at> gmail.com>, 61093 <at> debbugs.gnu.org
Subject: Re: bug#61093: Indented file names confuse compilation buffer
Date: Fri, 27 Jan 2023 22:00:23 +0100

Sascha Ziemann <ceving <at> gmail.com> writes:

> I think it might be ok to ignore leading whitespace, because file
> names do not start very often with whitespace.

Would that perhaps fix Lua errors too, which are also indented?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60830

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place."
-- Immanuel Kant, 1785

Rudolf Adamkovič <salutis <at> me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Previous Next

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