bug#33618: 27.0.50; ada-mode breaks M-x grep

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> 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.
>
> So how did we survive with this design problem until now?

I don't know.  I think by and large no package/user used it (After all,
in most cases compiler messages include the absolute file name IME), or
they used it only in Emacs sessions that are used for a single project.

>> 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).
> What will that do if I invoke, e.g., "M-x recompile" from a source
> buffer other than the one from which I invoked the previous "M-x compile"?

Good question.  I guess M-x recompile should first switch to the
compilation buffer and then cause the recompile from there (hence
reusing the value that was stashed into the compilation buffer).
[ Note: I haven't checked to see if my patch does that or not.  ]

> And what if we have multiple compilation buffers?

Not sure why that would make a difference.

> And, btw, isn't it wrong for a mode to set the value of a defcustom?

Yes.

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

Sounds like a good idea, tho we'd have to figure out how to combine the
two variable's values.


        Stefan