-
-
Notifications
You must be signed in to change notification settings - Fork 91
Keep custom g:netrw_list_hide intact #103
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
base: master
Are you sure you want to change the base?
Conversation
|
Ping? |
|
You can't just smash these two things together without adding a comma in between. |
5fdab32 to
8b55945
Compare
8b55945 to
ebc532c
Compare
|
Fixed, thanks for review. |
|
I just want to remind what tpope already said about
The variable
There has been a pull request as well
|
|
Well, I'm not changing 'wildignore' behaviour, you can check the patch. I'm just adding support for custom hide list. But maybe change 'wildignore' is better option after all. Will need to look into it. |
|
I know that your patch will still add
I struggled with this myself and would not mind if vinegar lets people decide which way they want to configure their ignore list Therefore user expect that they can use it this way. However, vinegar changes the use of this variable considerably: the only valid value is the magic string defined in Sometimes I appreciate tpope's standpoint and active measures that users of his plugins are more or less forced to take his standpoint. However, he should properly document this. This would reduce the number of issues and pull requests. Update |
|
Thank you @kiryph for tracking all those down, that was my next step. One thing I can't stand is trying out a new Vim plugin and being rewarded by getting yelled at on every Vim startup about some stupid crap I don't care about. I also like that you can have a basic netrw config you keep in your vimrc and have it "enhanced" on machines with vinegar without getting screwed when running on a server or something without your full setup. Maybe there's some sort of middle ground here but I think the first step is indeed documentation, as you point out. @fedorenchik do report back if you find a reason |
you are welcome.
Now I understand your motivation for the implementation. But it could still be made more explicit with a check if |
Fixes issue #102.