From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Filipp Gunbin Newsgroups: gmane.emacs.bugs Subject: bug#18109: 24.4.50; `compilation-error-regexp-alist-alist': wrong regexp for Maven Date: Mon, 07 Dec 2020 23:07:44 +0300 Message-ID: References: <5FFB3461-E756-4C09-9BFE-E0F9C840E533@acm.org> <133EE4BE-AD7E-4197-9888-1E4CCC47BB90@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5465"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin) Cc: Lars Ingebrigtsen , 18109@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 07 21:08:47 2020 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 1kmMoN-0001GJ-QL for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Dec 2020 21:08:45 +0100 Original-Received: from localhost ([::1]:57274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmMoM-00048q-RM for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 07 Dec 2020 15:08:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59644) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmMni-00047K-Fi for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2020 15:08:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44048) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kmMni-0007zt-7S for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2020 15:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kmMni-0006wY-2K for bug-gnu-emacs@gnu.org; Mon, 07 Dec 2020 15:08:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Filipp Gunbin Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Dec 2020 20:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18109 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 18109-submit@debbugs.gnu.org id=B18109.160737167426675 (code B ref 18109); Mon, 07 Dec 2020 20:08:02 +0000 Original-Received: (at 18109) by debbugs.gnu.org; 7 Dec 2020 20:07:54 +0000 Original-Received: from localhost ([127.0.0.1]:55594 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmMna-0006wB-96 for submit@debbugs.gnu.org; Mon, 07 Dec 2020 15:07:54 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:36995) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kmMnY-0006w0-Kg for 18109@debbugs.gnu.org; Mon, 07 Dec 2020 15:07:53 -0500 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5F1ED5C01EA; Mon, 7 Dec 2020 15:07:47 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 07 Dec 2020 15:07:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type:content-transfer-encoding; s=fm1; bh= Mn0WYWKTQRhw614iLKEJQAj1+sSsd8ucJBtO8ntMNUU=; b=ZMtD83IxFhcd3Ie/ 84wQ1pn0ObIvxQakeMZ0JiAaGKBX1cnp8pNURc0Nci6moPNBkle0sPeee1cw/JCH 7xiOY3DJ0P2DBk0u3LkmbdRpbkoDbJlyPp2BMMsO+EfvDsEi8I2gAjJEzPujEo6a bWZ1Gtksg2WdN2u0hXsaPOegcR3EBOmOu/QWAGPgo/h/TR64Z/yLc052fb3VqRjj 5dKFK4D19iZYcqybatD/ZvCFqhfrEjRp4ZQ3+WgoVgIU/ZuENmIkQQ+eqOVD7b1A mD7io+pFfcUnHNGW5Ec6rlnUEeS55f/TucdSTJMhuDyED6r2Siq7TZX8j1Le4yHV 59losw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=Mn0WYWKTQRhw614iLKEJQAj1+sSsd8ucJBtO8ntMN UU=; b=EEV63lsLWuw46stQrGEhtrVP2reaHqHV7JKs932RRTBJxJxKX1QM9UR2M rm1rTIr+oNgNoHUEakKflK/A1o2cUHDs94YkOqC15L3Fkstm+mD+i4TFbLHfGIGM 6gw/oW0m1Wd/Oa+QocD04ZenfaDMsGFEk1Ftd6Ilj3IPjNQQDvQS/8TGdr1Zn9Dn Qca/Ttj1FRQwj7gDiilSqZhLe+5hpFegKILXHAotiiAKdNmhDCGMa1/t6JCHCDum AS6F46ulDf7G1dXY6vhZk5Jl9zFicOZ1hTNbxN9Iv/j1XtulmhiTLSARUrkKgIQr fZfR0QajlXix7xFB5gvpCVr0rznyw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgudeffecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffujghffgffkfggtgfgsehtqhertddtreejnecuhfhrohhmpefhihhl ihhpphcuifhunhgsihhnuceofhhguhhnsghinhesfhgrshhtmhgrihhlrdhfmheqnecugg ftrfgrthhtvghrnhepkedvkeduledvtddvleevjeegtedugfdvlefgfeetgfekjeehheev hffgteffiefgnecukfhppeekgedrvddtgedrudelfedruddtieenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehfghhunhgsihhnsehfrghsthhm rghilhdrfhhm X-ME-Proxy: Original-Received: from fgunbin.local (unknown [84.204.193.106]) by mail.messagingengine.com (Postfix) with ESMTPA id 6EDCB1080066; Mon, 7 Dec 2020 15:07:46 -0500 (EST) In-Reply-To: <133EE4BE-AD7E-4197-9888-1E4CCC47BB90@acm.org> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Mon, 7 Dec 2020 14:49:40 +0100") 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" Xref: news.gmane.io gmane.emacs.bugs:195284 Archived-At: On 07/12/2020 14:49 +0100, Mattias Engdeg=C3=A5rd wrote: > However, experience tells us that this intuition is wrong. Output > formats do in fact tend to remain unchanged: Emacs and other editors, > IDEs and other code are parsing them, and they are not all equally > tolerant or in the same way. There is thus a self-reinforcing effect: > the tool keeps output stable because we expect it to. (When output > formats do change, it tends to be for good reasons and regexp > tolerance is then rarely useful.) I would be very much happy if this was true (I don't say it's the opposite, but I have a feeling that few in Java world care about how the error parses in Emacs). >> But, we just need to be aware that Java tools usually don't expect the >> output to be parsed. > > Yes they do! The very composition of something like the gradle-kotlin out= put > > e: FILENAME: (LINE, COL): MESSAGE > > is so strict and formalised that it was definitely made with > machine-readability in mind. I doubt that any modern-or-so Java IDE will parse any error messages, given that build tools and compilers have APIs. At the level of build tools, I can tell only for Gradle, and (to the best of my knowledge) it doesn't - when invoking either compilers or other tools, like checkstyle plugins. >> That is why I'm more inclined to >> making regexps more _lax_, not the other way around (and fix the >> problems with them once they appear). > > As we have found out the hard way, the cost of lax patterns is > insidious and diffuse until the mess really has to be sorted out -- > and by then it's hard to get hold of the various people involved who > have since long disappeared or forgot all about what they wrote years > ago. Patterns are added independently of one another but interact in > unexpected ways. > > Thus, better to keep patterns strict, and only alter them when and if > tool output changes; it is then clear exactly what needs to be done > and why. For most rules this never becomes necessary. Just wondering - did we have really that much problems caused by bad performance of compilation regexps? Because if we did, then maybe we should look at other approaches, like trying to detect the compiler used, and narrow the set of regexps based on it. It's natural to expect that many different people would edit these regexps when something doesn't work for them, and expecting that you will always come and fix the things up would not be very fair to you :-) Filipp