From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rudolf Schlatte Newsgroups: gmane.emacs.bugs Subject: bug#61093: Indented file names confuse compilation buffer Date: Fri, 27 Jan 2023 17:23:52 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24636"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (darwin) To: 61093@debbugs.gnu.org Cancel-Lock: sha1:uLjt1Utg0eQg0ZtZ2Iz5eW/TlAg= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 27 17:25:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pLRXU-0006G3-LX for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 27 Jan 2023 17:25:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLRXE-0006Xh-Sd; Fri, 27 Jan 2023 11:25:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLRXC-0006XL-HG for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 11:25:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pLRXC-0007Ux-3Q for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 11:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pLRXB-00085u-VH for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 11:25:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Rudolf Schlatte Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Jan 2023 16:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61093 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.167483664831044 (code B ref -1); Fri, 27 Jan 2023 16:25:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 27 Jan 2023 16:24:08 +0000 Original-Received: from localhost ([127.0.0.1]:38319 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLRWK-00084d-1P for submit@debbugs.gnu.org; Fri, 27 Jan 2023 11:24:08 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:50482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pLRWH-00084T-7I for submit@debbugs.gnu.org; Fri, 27 Jan 2023 11:24:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLRWG-0006Rm-Np for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 11:24:04 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pLRWE-0007Od-SF for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 11:24:04 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1pLRW9-0004St-RG for bug-gnu-emacs@gnu.org; Fri, 27 Jan 2023 17:23:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geb-bug-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:254263 Archived-At: Mattias Engdegård 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.