[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
.project-locals.el.
>
> 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
Regards,
Fabián
- A unified project root interface, Jorgen Schaefer, 2013/03/09
- Re: A unified project root interface,
Fabian Ezequiel Gallina <=
- Re: A unified project root interface, Stefan Monnier, 2013/03/10
- Re: A unified project root interface, Jorgen Schaefer, 2013/03/10
- Re: A unified project root interface, Lluís, 2013/03/11
- Re: A unified project root interface, David Engster, 2013/03/13
- Re: A unified project root interface, Sudish Joseph, 2013/03/13
- Re: A unified project root interface, Eric M. Ludlam, 2013/03/15
- Re: A unified project root interface, David Engster, 2013/03/16