bug#59868: 28.2.50; compilation-search-path incompatible with dir-locals

[Eli Zaretskii]

> From: Len Trigg <lenbok@gmail.com>
> Date: Sun, 11 Dec 2022 11:01:53 +1300
> Cc: 59868@debbugs.gnu.org
> 
>  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?

Something like that.  That's why I thought about project.el: it is
already sensitive to project changes.

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

I didn't mean global init, I meant the single .dir-locals.el file in
the top-level directory of all your R projects (which AFAIU share a
common parent directory).  Is having files named the same in different
sub-projects a real danger in that case?

But I agree this is not a comprehensive solution.  I still think the
comprehensive one should be provided by project.el, since it already
has infrastructure for these situations.  For example, you can
consider files under a certain directory to belong to a project.