From: Rudolf Schlatte <rudi@constantly.at>
To: 61093@debbugs.gnu.org
Subject: bug#61093: Indented file names confuse compilation buffer
Date: Fri, 27 Jan 2023 17:23:52 +0100 [thread overview]
Message-ID: <m2mt643q07.fsf@eduroam-193-157-202-51.wlan.uio.no> (raw)
In-Reply-To: <CAGUt3y6CYwNMP0YAZiZSNkDXWpXYr44tFjjZp5ki-ZhtUgmuSw@mail.gmail.com>
Mattias Engdegård <mattias.engdegard@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.
next prev parent reply other threads:[~2023-01-27 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-27 11:11 bug#61093: Indented file names confuse compilation buffer Sascha Ziemann
2023-01-27 14:34 ` Mattias Engdegård
2023-01-27 16:23 ` Rudolf Schlatte [this message]
2023-01-27 21:00 ` Rudolf Adamkovič via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2mt643q07.fsf@eduroam-193-157-202-51.wlan.uio.no \
--to=rudi@constantly.at \
--cc=61093@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).