unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
To: 33618@debbugs.gnu.org
Cc: monnier@IRO.UMontreal.CA
Subject: bug#33618: emacs ada-mode bug 33618
Date: Thu, 20 Dec 2018 12:17:26 -0800	[thread overview]
Message-ID: <86bm5g3qcp.fsf@stephe-leake.org> (raw)
In-Reply-To: <jwvbm60n9cg.fsf@iro.umontreal.ca>

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-<something> 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





  parent reply	other threads:[~2018-12-20 20:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-04 23:46 bug#33618: 27.0.50; ada-mode breaks M-x grep Stefan Monnier
2018-12-05  0:02 ` Stefan Monnier
2018-12-05  6:41   ` Eli Zaretskii
2018-12-05 14:26     ` Stefan Monnier
2018-12-05 14:37       ` Eli Zaretskii
2018-12-05 14:41         ` Eli Zaretskii
2018-12-05 16:10         ` Stefan Monnier
2018-12-20 20:17 ` Stephen Leake [this message]
2018-12-21  0:08   ` bug#33618: emacs ada-mode bug 33618 Dmitry Gutov
2018-12-21 23:19 ` bug#33618: update Stephen Leake
2019-01-04 17:27 ` bug#33618: 27.0.50; ada-mode breaks M-x grep Ludovic Brenta
2019-04-20 16:47 ` bug#33618: better fix Stephen Leake
2019-04-20 17:24   ` Eli Zaretskii
2019-04-25 22:52 ` bug#33618: fixed in commit 1486eadf7c9469f873fcd04beafd03f21564d580 Stephen Leake

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=86bm5g3qcp.fsf@stephe-leake.org \
    --to=stephen_leake@stephe-leake.org \
    --cc=33618@debbugs.gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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).