[Top][All Lists]

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

Re: A unified project root interface

From: Fabian Ezequiel Gallina
Subject: Re: A unified project root interface
Date: Sat, 9 Mar 2013 14:12:05 -0300

2013/3/9 Jorgen Schaefer <address@hidden>:
> It would be really useful if there was a single standard way to define
> the project root, so that extensions can just use that standard way
> without each and every one of them writing the same code over and over
> again. Sadly, as the code is not exactly difficult and so many projects
> have already used their own way, it's highly unlikely that a random
> third-party library would simply "emerge" as the standard way of doing
> things. Which makes me believe the only way to solve this is via a bit
> of a top-down decision to include a library in Emacs and declare it as
> "the default".

There's a standard way of defining variable values for files inside a
parent folder (read project). This mechanism is the Directory Local
variables [M-: (info "(emacs)Directory Variables")]. And it works, and
works good, in fact python.el makes use of this a lot and is able to
even to set the virtualenv for all your project files (without messing
with external others) thanks to it[0].

Normally I would consider the .dir-locals.el file location as the
project root, but then perhaps the user needs to override some values
in a sub-folder. So in that case I think it might be a good idea to
introduce an additional standard name for .dir-locals.el files that
are ought to be used only at the project root. I propose the name of
.project-locals.el. With this detecting if a file belongs to a project
and what's the project root is as easy as to find the

> So this is my somewhat verbose request to say "yes, let's do this" and
> pick a library to provide the functionality. The library itself doesn't
> have to be big at all, in theory a single variable `project-root'
> that everyone is encouraged to use would be enough. Adding some
> basic functionality to this would be helpful, though. If we keep the
> functionality to a minimum, this lets other extensions use it without
> being annoyed at the features they drag in.

With something like the .project-locals.el, the only thing missing is
some UI for people fearing associations lists. I think, the best way
to go is a similar interface of what you get with customize-group
(hopefully most of its code could be borrowed).

[0] See Directory Local Variables section at: http://bit.ly/ZzUxxL


reply via email to

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