New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Project-local variables. #139

Closed
k-bx opened this Issue Jul 8, 2013 · 30 comments

Comments

Projects
None yet
@k-bx

k-bx commented Jul 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@proofit404

proofit404 Jul 9, 2013

Contributor

+1

Contributor

proofit404 commented Jul 9, 2013

+1

@dhaley

This comment has been minimized.

Show comment
Hide comment
@dhaley

dhaley Jul 10, 2013

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.

dhaley commented Jul 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Jul 10, 2013

Owner

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

Owner

bbatsov commented Jul 10, 2013

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

@bbatsov

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Jul 10, 2013

Owner

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

Owner

bbatsov commented Jul 10, 2013

@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

This comment has been minimized.

Show comment
Hide comment

drd commented Aug 27, 2013

+1

@kolya-ay

This comment has been minimized.

Show comment
Hide comment
@kolya-ay

kolya-ay Sep 4, 2013

+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

kolya-ay commented Sep 4, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Sep 26, 2013

Contributor

I have wanted this exact thing.

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

Contributor

joelmccracken commented Sep 26, 2013

I have wanted this exact thing.

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

@bbatsov

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Sep 26, 2013

Owner

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

Owner

bbatsov commented Sep 26, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Sep 26, 2013

Contributor

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.

Contributor

joelmccracken commented Sep 26, 2013

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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Sep 30, 2013

Contributor

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

Contributor

joelmccracken commented Sep 30, 2013

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

@dsvensson

This comment has been minimized.

Show comment
Hide comment
@dsvensson

dsvensson Nov 21, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

This comment has been minimized.

Show comment
Hide comment
@diadara

This comment has been minimized.

Show comment
Hide comment

diadara commented Dec 1, 2013

+1

@joelmccracken

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Dec 2, 2013

Contributor

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

Contributor

joelmccracken commented Dec 2, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Dec 2, 2013

Owner

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

Owner

bbatsov commented Dec 2, 2013

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

@joelmccracken

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Dec 2, 2013

Contributor

<3 Thanks!

On Dec 2, 2013, at 11:42 AM, Bozhidar Batsov notifications@github.com 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.

Contributor

joelmccracken commented Dec 2, 2013

<3 Thanks!

On Dec 2, 2013, at 11:42 AM, Bozhidar Batsov notifications@github.com 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

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Feb 12, 2014

Owner

@joelmccracken Any progress?

Owner

bbatsov commented Feb 12, 2014

@joelmccracken Any progress?

@joelmccracken

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Feb 25, 2014

Contributor

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
notifications@github.comwrote:

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

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

Contributor

joelmccracken commented Feb 25, 2014

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
notifications@github.comwrote:

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

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

@photex

This comment has been minimized.

Show comment
Hide comment
@photex

photex Mar 13, 2014

+1 Looking forward to this feature.

photex commented Mar 13, 2014

+1 Looking forward to this feature.

@timoc

This comment has been minimized.

Show comment
Hide comment
@timoc

timoc Jun 30, 2014

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

timoc commented Jun 30, 2014

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

@zargener

This comment has been minimized.

Show comment
Hide comment

+1

@daimrod

This comment has been minimized.

Show comment
Hide comment
@daimrod

daimrod Jul 14, 2014

Contributor

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?

Contributor

daimrod commented Jul 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Jul 14, 2014

Owner

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

Owner

bbatsov commented Jul 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Jul 14, 2014

Contributor

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 notifications@github.com 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.

Contributor

joelmccracken commented Jul 14, 2014

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 notifications@github.com 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 comment has been minimized.

Show comment
Hide comment
@daimrod

daimrod Jul 14, 2014

Contributor

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.

Contributor

daimrod commented Jul 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Jul 14, 2014

Contributor

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.

Contributor

joelmccracken commented Jul 14, 2014

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

This comment has been minimized.

Show comment
Hide comment
@bbatsov

bbatsov Jul 14, 2014

Owner

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

Owner

bbatsov commented Jul 14, 2014

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

@zargener

This comment has been minimized.

Show comment
Hide comment

Check #387

@bbatsov bbatsov closed this Aug 7, 2014

@joelmccracken

This comment has been minimized.

Show comment
Hide comment
@joelmccracken

joelmccracken Nov 17, 2014

Contributor

@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 #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.

Contributor

joelmccracken commented Nov 17, 2014

@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 #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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment