From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Gary Oberbrunner Newsgroups: gmane.emacs.bugs Subject: bug#3418: Issue with compile.el and compilation-parse-errors-filename-function Date: Tue, 26 Jan 2016 10:15:27 -0500 (EST) Message-ID: <799658909.580977.1453821327904.JavaMail.zimbra@genarts.com> References: <4A1FF55B.4040202@genarts.com> <83vb6g1jwt.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453825880 10843 80.91.229.3 (26 Jan 2016 16:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 16:31:20 +0000 (UTC) Cc: Andrew Hyatt , 3418@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 26 17:31:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aO6WM-0000EQ-5I for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jan 2016 17:31:10 +0100 Original-Received: from localhost ([::1]:44982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO6WL-00029y-BV for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jan 2016 11:31:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39602) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO6WH-00029a-6F for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 11:31:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aO6WE-000216-Ds for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 11:31:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49617) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aO6WE-00020w-Ak for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 11:31:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aO6WE-0002WS-45 for bug-gnu-emacs@gnu.org; Tue, 26 Jan 2016 11:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gary Oberbrunner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Jan 2016 16:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 3418 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 3418-submit@debbugs.gnu.org id=B3418.14538258479667 (code B ref 3418); Tue, 26 Jan 2016 16:31:02 +0000 Original-Received: (at 3418) by debbugs.gnu.org; 26 Jan 2016 16:30:47 +0000 Original-Received: from localhost ([127.0.0.1]:37835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aO6Vz-0002Vq-0J for submit@debbugs.gnu.org; Tue, 26 Jan 2016 11:30:47 -0500 Original-Received: from hq.genarts.com ([173.9.65.1]:35118 helo=mail.hq.genarts.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aO5LB-0000g1-Bd for 3418@debbugs.gnu.org; Tue, 26 Jan 2016 10:15:33 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hq.genarts.com (Postfix) with ESMTP id 2151EBE03E2; Tue, 26 Jan 2016 10:15:33 -0500 (EST) Original-Received: from mail.hq.genarts.com ([127.0.0.1]) by localhost (mail.hq.genarts.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JOqAqCUwHH1m; Tue, 26 Jan 2016 10:15:28 -0500 (EST) Original-Received: from localhost (localhost [127.0.0.1]) by mail.hq.genarts.com (Postfix) with ESMTP id 48F59BE0C6C; Tue, 26 Jan 2016 10:15:28 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.hq.genarts.com Original-Received: from mail.hq.genarts.com ([127.0.0.1]) by localhost (mail.hq.genarts.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6ehzH3rI2yc0; Tue, 26 Jan 2016 10:15:28 -0500 (EST) Original-Received: from mail.hq.genarts.com (localhost [127.0.0.1]) by mail.hq.genarts.com (Postfix) with ESMTP id 1A3ABBE03E2; Tue, 26 Jan 2016 10:15:28 -0500 (EST) In-Reply-To: <83vb6g1jwt.fsf@gnu.org> X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - GC47 (Win)/8.6.0_GA_1182) Thread-Topic: bug#3418: Issue with compile.el and compilation-parse-errors-filename-function Thread-Index: dW+0q8UHvR3Odqxg0txhf8l/h6VQfg== X-Mailman-Approved-At: Tue, 26 Jan 2016 11:30:45 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112000 Archived-At: Wow, a blast from the past! I am totally happy with soln 1. For all I know, since I added that hook I might be the only one using it. :-) But I'm also usually a stickler for backward compatibility, so that's why I brought it up. As for how to make it happen, I'm not sure what triggers the absolute vs. relative names getting passed around in compilation-parse-errors; it probably depends on what it finds in the *compilation* buffer. But Andrew, in order for this to matter at all, the emacs user has to have added their own compilation-parse-errors-filename-function, so "normal" users wouldn't be affected by this at all. The use case is a build system that copies/symlinks the sources to a build dir and compiles them there rather than in their original location. Compilation errors will be given relative to that build dir, not the original source. A user with such a build system would make a compilation-parse-errors-filename-function that would string-replace the build dir to the source dir, so next-error would jump to the proper source file (not the build dir copy). ----- Original Message ----- > From: "Eli Zaretskii" > To: "Andrew Hyatt" > Cc: "Gary Oberbrunner" , 3418@debbugs.gnu.org > Sent: Tuesday, January 26, 2016 9:42:58 AM > Subject: Re: bug#3418: Issue with compile.el and compilation-parse-errors-filename-function >> From: Andrew Hyatt >> Date: Tue, 26 Jan 2016 00:21:51 -0500 >> Cc: 3418@debbugs.gnu.org >> >> Gary Oberbrunner writes: >> >> > Hi emacs folks. I submitted a patch to compilation-get-file-structure in >> > compile.el in 2001, introducing this stanza: >> > >> > ;; If compilation-parse-errors-filename-function is >> > ;; defined, use it to process the filename. >> > (when compilation-parse-errors-filename-function >> > (setq filename >> > (funcall >> > filename))) >> > >> > At some point since then, the filename was changed to not always be absolute; >> > there's now a variable spec-directory in that function. This means that >> > implementations of compilation-parse-errors-filename-function can't always work >> > correctly since it doesn't know the full path of the file. >> > >> > I'm happy to work on a fix, but I see a few issues. >> > >> > Solution 1: add 2nd arg SPEC-DIRECTORY to >> > compilation-parse-errors-filename-function. >> > Problem: existing implementations will get an incorrect number of args error and >> > will have to change. >> > >> > Solution 2: make filename absolute before passing to >> > compilation-parse-errors-filename-function. >> > Problem: the rest of the code is pretty careful not to absolutize the filename; >> > this would change the behavior in ways I don't completely understand. >> > >> > Of course I am personally happy with solution 1, but since it affects >> > compatibility I thought I should bring it up on this list. I am not on the >> > list, so please cc me with any replies, thanks! >> >> Sadly, this bug hasn't been responded to. Your description is pretty >> code-intensive, for those of us not familiar with the internals, can you >> give instructions on how to reproduce a user-visible issue? > > FWIW, I don't see why not adopt Soution 1, just make the second > argument optional. That would be backward-compatible, IIUC. -- Gary Oberbrunner