bug#33618: update

[Stephen Leake]

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