[feature request] Project-local variables.

[k-bx]

Since projectile is already an awesome tool for managing projects in emacs, maybe it could somehow provide users with a documented ability for easily defining (and using in your .emacs file) project-local variables?

[proofit404]

+1

[dhaley]

Right now I use .dirlocals for this -- with this line inside:

((nil . ((eval . (setup-local-vars)))))

But it would be nice if projectile could call such a hook without a .dirlocals file, which is a pain adding to each project.

[bbatsov]

I'm thinking of something in the lines of modifying the format of .projectile to support local variables.

[bbatsov]

@sabof already had some good ideas a while back, unfortunately I've been extremely busy lately and haven't started working on that feature yet.

[drd]

+1

[kolya-ay]

+1. I think .projectile must (or may) be a folder with something like init.el file. The folder might be able containing also TAGS, desktop and other project-wide cache and scripts. It would be great if I can setup project-wide keybindings and variables, but I do not know if this is possible at all

[joelmccracken]

I have wanted this exact thing.

Since .projectile is taken, .projectile.el might be usable as well.

[bbatsov]

@kolya-ay Making .projectile a directory is a good idea. I've been thinking lately about the best way to approach that issue. I might start with reworking the existing functionality around a .projectile folder and continue from there. I'm not sure how wise (and safe) it would be to execute Lisp code when initializing a project.

[joelmccracken]

the .dir-locals.el method works decently well; i use the same technique @dhaley mentions. It is, however, rather user-unfriendly.

the .dir-locals.el method presents the user with a confirmation before applying elisp. These preferences (may) be saved in an init.el file automatically.

See the function hack-local-variables-filter, which sits in my files.el.gz on emacs 24.3.1.

I think we could probably just lift this technique. Its a good bit of work, but the rewards are great.

[joelmccracken]

@bbatsov are you still in favor of this as a plugin per the discussion in #70 ?

[dsvensson]

Would per project TAGS be a separate issue? I'm in a situation where I have multiple directories open with the same software, but different revisions (think fixing bugs in old versions), and would like to go to tags only in the same git repository as the buffer I'm in.

[huseyinyilmaz]

+1

[joelmccracken]

I wrote up a blog post about how I do this: http://joelmccracken.github.io/entries/project-local-variables-in-projectile-with-dirlocals/

[nithinsag]

+1

[joelmccracken]

@bbatsov this is blocking me, so I would like to work on it. Can you advise? This also seems like a dup of #79

[bbatsov]

@joelmccracken I guess using a file like .projectile.el makes sense. It would be processed similarly to the way .dir-locals.el.

[joelmccracken]

<3 Thanks!

On Dec 2, 2013, at 11:42 AM, Bozhidar Batsov [email protected] wrote:

@joelmccracken I guess using a file like .projectile.el makes sense. It would be processed similarly to the way .dir-locals.el.

—
Reply to this email directly or view it on GitHub.

[bbatsov]

@joelmccracken Any progress?

[joelmccracken]

blah, nope. I still haven't had time to really work on this.

I'll re-push this up in my queue.

On Wed, Feb 12, 2014 at 4:11 AM, Bozhidar Batsov
[email protected]:

@joelmccracken https://github.com/joelmccracken Any progress?

Reply to this email directly or view it on GitHubhttps://github.com//issues/139#issuecomment-34850786
.

[photex]

+1 Looking forward to this feature.

[timoc]

+1, though i would prefer extending .projectile with prefix characters # Coments, and @ or ( elisp-eval, that way it is all in the one place.
update: on reading up on the dir-locals I would suggest rather than the eval, or some projectile specific thing, that it just filters lines starting with '(' out and throws them at dir-locals (with appropriate confirmation possibilities ..)

[vandrlexay]

+1

[daimrod]

Reading this thread I don't understand what would be the differences
between a .projectile and .dir-locals.el.

I hope that it's not just two avoid having two files
(.projectile+.dir-locals.el), otherwise it seems like a waste of
times to me...

Can someone enlighten me?

[bbatsov]

Now most configuration options are marked as safe anyways (meaning users won't get a warning when setting them in .dir-locals.el), so using .dir-locals.el is a perfectly good option for just about everyone. I don't think there's much value in developing anything custom at this point...

[joelmccracken]

Interesting, I didn't know that.
I imagine the most valuable piece would be to simplify the format of dir-locals -- I still feel uncomfortable with it every time I need to use it.

Edit: GitHub parsed my email incorrectly

On Jul 14, 2014, at 2:25 AM, Bozhidar Batsov [email protected] wrote:

Now most configuration options are marked as safe anyways (meaning users won't get a warning when setting them in .dir-locals.el), so using .dir-locals.el is a perfectly good option for just about everyone. I don't think there's much value in developing anything custom at this point...

—
Reply to this email directly or view it on GitHub.

[daimrod]

This is going out of the scope of this thread but you can use M-x
add-dir-local-variable (just like you would have used M-x add-file-local-variable).

See the info page for more information (info "(emacs) Directory Variables").

I believe that going on with this feature would just mean to reinvent
dir-locals.el.

[joelmccracken]

Yeah. It seems like this is a popular request, though -- would better documentation solve this problem? I wrote that blog post I linked to earlier. Would that be a good starting point for this? Maybe if the README had a section on this that would be helpful.

I've been off the radar as far as open source goes for a while now. A bunch of IRL things have taken up my time. This is my most pressing open source commitment, though. It would be great if there was a way that was easy to use and could satisfy everyone.

[bbatsov]

I think that a good section in the README regarding this would be good enough for most users.

[vandrlexay]

Check #387

[joelmccracken]

@bbatsov I think I want to re-open this issue. There are a number of use cases that dir-locals doesn't work for, namely:

1. Setting per-project projectile-switch-project-action values. dir locals are only read after a file is already opened in a project.
2. Setting project-specific names as noted in Should be able to specify a name for projects #479.

There are others, but this is all I remember at the moment. Thoughts? I still believe a file that allows for additional project metadata will be useful.

[countvajhula]

I'm not too familiar with emacs, but what about exposing hooks for this purpose, something like projectile-project-loaded-hook? Users can set whatever project-specific variables they care about by using this like any other hook. The issue could be providing additional hooks such that the variables are reset to their original values when a non-project buffer is loaded, but I would assume that mode hooks like python-mode-hook already solve this problem. The use case I'm encountering at the moment is that some projects I work on use tabs while others use spaces, and I'd like to set tabstops, tab-indent-mode etc. based on which project it's in.

[madscientist]

I've successfully used .dir-locals.el for my needs but it is hacky, mainly due to @joelmccracken's issue 1 above: because file local variables are not set until AFTER important things like the mode hooks etc. are parsed, you are very limited in the kinds of things they can affect.

For example, I wanted to customize my LSP server by resetting its initialization options, but that's not possible because LSP starts the server with the global options before .dir-locals.el is read in.

You can get this to work, by adding the lsp mode invocation to hack-local-variables-hook instead of your mode's hook variable, but it's pretty gross and esoteric.

It would be really nice if there were a more straightforward way to get this to work. I confess I'm not exactly sure what the right way to do it would be, other than reproducing some aspects of the existing dir-local capabilities. Or maybe we could ask the Emacs devs to modify the way dir-locals work, so that variables defined in the nil context (always applied) are set up before the mode hooks are run and variables defined for a specific mode are set up after the mode hooks are run. Or something like that...