bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Len Trigg
Subject: bug#59868: 28.2.50; compilation-search-path incompatible with dir-locals
Date: Sat, 10 Dec 2022 08:11:10 +1300


On Fri, 9 Dec 2022 at 20:06, Eli Zaretskii <eliz@gnu.org> wrote:
You are ignoring the first sentence in my response, right?

 I don't think so - the purpose of my email was essentially to ask why you thought the variable shouldn't be buffer-local in *compilation* buffers. I'm hoping to see where my mental model of using .dir-locals.el and/or buffer-local variables is at odds with how emacs intends. The user manual for both of these make it seem like this would be a perfect fit.


The rest was a suggestion (and I do see a good reason why project.el
would like to provide this as a project-specific setting).

More generally, why would you want a directory-specific value for this
variable, if it isn't something the entire directory tree shares?

From my understanding, settings in .dir-locals.el *do* affect the whole directory tree under the directory containing the file (and I'm happy for that to be the case here). I think of .dir-locals.el in the project root as the preferred way of specifying project-wide settings, and of project.el/projectile.el as primarily providing meta functionality (e.g. cross projects, or multi-file within a project). (I would also perhaps naively expect that project.el would in turn get its project-wide settings via that .dir-locals.el, at least that is how I have done it for projects where I've needed to customize projectile settings (sorry, I haven't tried project.el yet)).


Maybe you should tell why you need to tell Emacs where to find the
sources?  Doesn't the tool you use to compile spell that out?

In my specific case the project is in R (which is a terrible language for software development) and we are using a single top level makefile in the project. It has a target to run linting, which (within each R linter invocation) lints from a subdirectory, and the filenames in each lint message are relative to those directories. There is not the hierarchy of makefiles that you would often see in say C projects, where compilation mode could parse make-issued messages about changing directories etc. It seemed a perfect fit for compilation-search-path. I am currently working around it with the following ugliness in my .dir-locals.el:

(
 (compilation-mode . ((eval . (progn
                                (setq-local compilation-search-path '(
                                              "~/sandboxes/myproject/R"
                                              "~/sandboxes/myproject/tests"
                                              ))
                                (put 'compilation-search-path 'permanent-local t)
                                (compilation-mode))))))


Cheers,
Len.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]