Skip to content
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

Support for local settings #28

Closed
monokrome opened this issue Jul 8, 2014 · 9 comments
Closed

Support for local settings #28

monokrome opened this issue Jul 8, 2014 · 9 comments

Comments

@monokrome
Copy link

It would be nice if projectionist allowed users to define settings for specific patterns. For instance, the following configuration might exist:

{
    "project/templates/**.html": {
        "settings": { "filetype": "djangohtml" }
    }
}

I considered just having a filetype setting as well, but it seems like this is a more flexible way to solve the problem. I'm wondering if you think that this is useful or out-of-scope before I tried to write it and send over a pull request.

@tpope
Copy link
Owner

tpope commented Jul 8, 2014

File type in particular is troublesome because we're already activating on the file type event. But yeah, this was always part of my grand plan. I just surprisingly haven't felt a need for it, at all.

@monokrome
Copy link
Author

I guess that there would have to be special-cases certain settings, which could become a bit tough to maintain.

Maybe it's better for things like filetype to be defined outside of a generic settings feature. I think that the need isn't very high-demand, but I know that I've wanted it in a few cases here and there when using plugins or frameworks that do more unusual things.

Such a case is represented here, where Django convention is to name templates with a .html extension but it makes sense for the the global Vim configuration to use something more usual for html files.

Another useful case that I can see from this is that I want to be able to provide settings for one of my Vim plugins on a per-file basis and thought that projectionist represents the right way to solve that particular problem.

@tpope
Copy link
Owner

tpope commented Jul 8, 2014

Make a list of options you'd like to set, and we can evaluate how to proceed. Only other thing I've thought of has been indenting, but personally I'm content to use sleuth.vim for that.

Regarding plugins, I think the ideal solution there is for plugins to manage that themselves. See :help projectionist#query.

By the way, you can drop all the hand-wringing about :Dispatch and 'errorformat' if you just use :Make instead. Something like this would work and fall back to :make automatically.

@monokrome
Copy link
Author

I think that the only options I've run into myself which I've wanted this feature for were indent-based options as well as the filetype setting. I personally haven't had a lot of luck with sleuth, but maybe I'm missing a setting or something.

There is a case where I've wanted to change colorscheme for specific files, but I think that's most likely an unusual use-case here. Another (possibly tangential) thing that I've wanted to do is to set mappings for specific files.

It seems that projectionist#query is exactly what I've been looking for with my plugin, and the tip regarding :Make seems to make a lot of sense. I was trying to think of a better way to do that. Thank you!

@tpope
Copy link
Owner

tpope commented Jul 10, 2014

Early version had an "indent" option that controlled 'shiftwidth', but that was an incomplete solution so I dropped it. A simple option would be to bring it back and force 'expandtab'. I'm not sure what to do about hard tabs, as they're nothing but trouble, and I'd like to support but discourage their use. (My guess is any Sleuth problems you're having is due to an inconsistent mix of spaces and tabs.)

@monokrome
Copy link
Author

I'm usually pretty insistent on people using the conventions for the given language, so I don't think that inconsistencies would be the reason that I've had issues with sleuth. In that same sense, I also use hard tabs in Go, Java, and C++ (for instance) because that is the conventional / recommended code style.

I'm pretty sure that gofmt even converts soft tabs to hard tabs automatically to keep this consistent. It might make sense to add an expandtabs option as well? Another option that I found myself wanting yesterday was textwidth, because some projects just make it more of a bother than useful. I'm mostly trying to deprecate my use of this plugin with these changes, but that's what I'm using for these things right now.

If any of these are features that you think is worth supporting, what do you think that the best interface for this would be?

@tpope
Copy link
Owner

tpope commented Jul 11, 2014

Just tried sleuth.vim on a random Go file, and it got confused by a multiline string, so perhaps there a further improvements to be had. Feel free to open an issue.

Vim's indenting options are a confusing mess, so the last thing I want to do is use that as an inspiration for our interface. I'm thinking something like this instead:

  • "indent": 2: set sw=2 et
  • "indent": 4, "tabstop": 8: set sw=4 ts=8 noet
  • "tabstop": 8: set sw=8 ts=8 noet

One major hitch in hooking this up is that indent settings shouldn't mix from different projections (a * tabstop shouldn't affect a *.rb indent), and we have no way to query along those lines currently.

After tackling indent, 'textwidth' would indeed be the most logical thing to include.

@monokrome
Copy link
Author

@tpope I'm wondering if this is still worth keeping open considering editorconfig has solved the indentation problem and a Vim plugin is available that works just fine alongside a projection file. Might be time to close this one?

@tpope
Copy link
Owner

tpope commented Aug 12, 2015

Don't get me started on editorconfig, but yeah, barring a flash of insight I don't anticipate working on this.

@tpope tpope closed this as completed Aug 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants