From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.bugs Subject: bug#33618: update Date: Fri, 21 Dec 2018 15:19:35 -0800 Message-ID: <865zvm4ge0.fsf@stephe-leake.org> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1545434285 30251 195.159.176.226 (21 Dec 2018 23:18:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 21 Dec 2018 23:18:05 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (windows-nt) To: 33618@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 22 00:18:01 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaU3N-0007kc-7u for geb-bug-gnu-emacs@m.gmane.org; Sat, 22 Dec 2018 00:18:01 +0100 Original-Received: from localhost ([::1]:48574 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaU5U-0007iZ-2p for geb-bug-gnu-emacs@m.gmane.org; Fri, 21 Dec 2018 18:20:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38973) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gaU5N-0007iE-Ie for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 18:20:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gaU5K-0005pU-Dy for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 18:20:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54722) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gaU5K-0005p9-AW for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 18:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gaU5K-0005VL-29 for bug-gnu-emacs@gnu.org; Fri, 21 Dec 2018 18:20:02 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Stephen Leake Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 21 Dec 2018 23:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33618 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33618-submit@debbugs.gnu.org id=B33618.154543438621130 (code B ref 33618); Fri, 21 Dec 2018 23:20:02 +0000 Original-Received: (at 33618) by debbugs.gnu.org; 21 Dec 2018 23:19:46 +0000 Original-Received: from localhost ([127.0.0.1]:58980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaU53-0005Uk-N0 for submit@debbugs.gnu.org; Fri, 21 Dec 2018 18:19:45 -0500 Original-Received: from smtp103.ord1d.emailsrvr.com ([184.106.54.103]:57238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gaU51-0005UZ-Ol for 33618@debbugs.gnu.org; Fri, 21 Dec 2018 18:19:44 -0500 Original-Received: from smtp13.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 88E91C01DA for <33618@debbugs.gnu.org>; Fri, 21 Dec 2018 18:19:38 -0500 (EST) X-Auth-ID: board-president@tomahawk-creek-hoa.com Original-Received: by smtp13.relay.ord1d.emailsrvr.com (Authenticated sender: board-president-AT-tomahawk-creek-hoa.com) with ESMTPSA id 353BCC016A for <33618@debbugs.gnu.org>; Fri, 21 Dec 2018 18:19:38 -0500 (EST) X-Sender-Id: board-president@tomahawk-creek-hoa.com Original-Received: from Takver4 ([UNAVAILABLE]. [76.77.182.20]) (using TLSv1.2 with cipher AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 21 Dec 2018 18:19:38 -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" Xref: news.gmane.org gmane.emacs.bugs:153706 Archived-At: I did not see this bug until now; apparently my fsf email forwarding is not working (I'm looking into that). Stefan writes: > Opening a file in ada-mode using the new ada-mode from GNU ELPA globally > sets compilation-search-path (for me, it got set to `("~/tmp")` > probably because the Ada file was in ~/tmp), which in > turn breaks M-x grep in the sense that clicking on a match doesn't jump > to the file but prompts you to find the file (unless you happened to > grep from one of the directories mentioned in the > compilation-search-path, of course). Yes; 'compilation-search-path' is an attribute of a "project" (a very poorly defined concept in Emacs, unfortunately). Opening an ada-mode file defines a default project, which has the current directory as the value for 'compilation-search-path'. > Because I think the problem in ada-mode is linked to a design problem > with that variable: it is defined to be a global variable, and > compile.el looks it up from inside the compilation buffer, so there's no > convenient way for a major mode like ada-mode to tell compile.el which > search-path to use for which file/project: all they can do is change the > global value. Yes. > The patch I use changes compile.el so the var is looked up from the > buffer from which the compilation is launched (e.g. an ada-mode buffer) > and then stashed into the compilation buffer (for later use). This is one approach. I'll install it in my working emacs and see if it causes me any problems. I suspect it will break my project code, which assumes the global value of 'compilation-search-path' is used. Another approach would be to use the 'project' package; if (current-project) returns non-nil, use (project-path (current-project)). But there is no 'project-path' (despite my efforts to define one), so that doesn't work. There is only 'project-roots' and 'project-library-roots', which return values not suitable for 'compilation-search-path'. Perhaps this bug provides a context to reopen that discussion. ada-mode does provide an explicit notion of projects, which include the list of source directories, which is used to set compilation-search-path. When the user has specified such a project, it would be surprising to see some other value of compilation-search-path be used, based on what buffer happens to be current; I view the choice of 'project' as global, affecting all files/buffers, because a real-world project involves many kinds of files, not just Ada ones. It would make sense to factor out the project-related code in ada-mode, and turn it into a project- package. The original problem in this bug was caused by ada-mode providing a default project when you had not specified one. The goal there is to make it easy for Emacs/ada-mode newbies to invoke the various ada-related tools (mainly the compiler), before learning about ada-mode projects. Perhaps that design choice should be reconsidered. Eli writes: > And, btw, isn't it wrong for a mode to set the value of a defcustom? Good point. > Maybe we should have a separate variable for this purpose, one that > isn't a defcustom. A buffer-local value of a defcustom is going to > surprise users, I think. Yes. (project-source-path (project-current)) seems to be the right choice here, if we can define that in a reasonable way. I didn't use that in ada-mode before, because I was trying to maintain compatibility with Emacs 24. Now that I've given up on that, ada-mode can integrate with project.el Stefan writes: > I think by and large no package/user used it (After all, > in most cases compiler messages include the absolute file name IME), The GNAT Ada compiler options can be set to provide the full path, but I prefer not to waste that screen space, since Emacs is perfectly capable of finding the right file. > or they used it only in Emacs sessions that are used for a single > project. Yes, there seems to be a strong preference (bias?) towards only allowing a single project per Emacs process. Which means you have to exit Emacs to change projects. I've never liked that behaviour in other IDEs, and I've been using multiple projects in Emacs for years. -- -- Stephe