GNU bug report logs - #59868
28.2.50; compilation-search-path incompatible with dir-locals

Previous Next

Package: emacs;

Reported by: Len Trigg <lenbok <at> gmail.com>

Date: Wed, 7 Dec 2022 01:57:01 UTC

Severity: wishlist

Found in version 28.2.50

Full log


View this message in rfc822 format

From: Len Trigg <lenbok <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59868 <at> debbugs.gnu.org
Subject: bug#59868: 28.2.50; compilation-search-path incompatible with dir-locals
Date: Sun, 11 Dec 2022 11:01:53 +1300
[Message part 1 (text/plain, inline)]
On Sun, 11 Dec 2022 at 03:02, Eli Zaretskii <eliz <at> gnu.org> wrote:

> Because from the pattern we use the *compilation* buffer it is clear
> that it cannot be buffer-local.  The *compilation* buffer is reused by
> each new compilation, so local setting there makes no sense.
>

Ahhh, right, thanks. My current hack would not work as expected if I switch
to another project and compile that without first killing the previous
*compilation* buffer, since it would have the previous project settings. So
to be project aware I guess I would somehow need to set the
compilation-search-path from compilation-start-hook?


> Why cannot you have all the possible directories in the list?
>

Do you mean all directories for the current project, or all directories
across all projects? If the former, that's exactly what I want. If the
latter, that seems prone to incorrectly resolving the source file for a
message as coming from a project other than the current (particularly for
generic filenames like "utils.c") and additionally I try not to have
anything project specific in my global emacs init, they should live in the
project repo (and .dir-locals.el is the only mechanism I'm aware of for
that).

Cheers,
Len.
[Message part 2 (text/html, inline)]

This bug report was last modified 2 years and 189 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.