[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33618: 27.0.50; ada-mode breaks M-x grep
From: |
Eli Zaretskii |
Subject: |
bug#33618: 27.0.50; ada-mode breaks M-x grep |
Date: |
Wed, 05 Dec 2018 16:37:28 +0200 |
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: 33618@debbugs.gnu.org, stephen_leake@member.fsf.org
> Date: Wed, 05 Dec 2018 09:26:45 -0500
>
> > Why do we need to change our code to cater to problems in packages,
> > even if those packages are on ELPA? It sounds wrong to me, FWIW.
>
> 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?
> 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"?
And what if we have multiple compilation buffers?
bug#33618: emacs ada-mode bug 33618, Stephen Leake, 2018/12/20
bug#33618: update, Stephen Leake, 2018/12/21