[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33618: 27.0.50; ada-mode breaks M-x grep
From: |
Stefan Monnier |
Subject: |
bug#33618: 27.0.50; ada-mode breaks M-x grep |
Date: |
Wed, 05 Dec 2018 11:10:21 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> 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
bug#33618: emacs ada-mode bug 33618, Stephen Leake, 2018/12/20
bug#33618: update, Stephen Leake, 2018/12/21