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

Use binstubs only if they exist #36

Open
alindeman opened this issue Mar 16, 2013 · 6 comments
Open

Use binstubs only if they exist #36

alindeman opened this issue Mar 16, 2013 · 6 comments

Comments

@alindeman
Copy link

Thoughts on a value for g:vroom_use_binstubs (maybe 2?) that uses binstubs if the appropriate one exists, but if not, falls back to default behavior?

If you agree, I could try to hack something together :)

@charlietanksley
Copy link
Collaborator

This sounds like a good idea to me. It seems like it should maybe be the default eventually, at least if you want to use binstubs.

Re: implementation. The options for this plugin are getting unwieldy. I do see why they are all needed, but I think we can do a redesign that makes all the option stuff more elegant and easier to reason about. Off the top of my head, I'm not sure what would happen if you used 2 for the optional bistubs value. If I understand correctly, VimL has us use 1 and 0 as booleans. So I'm a little leery of throwing another value in there (I could be wrong about that, though!). So for now I'd add another option g:use_binstubs_optionally or something. When someone gets around to changing the way we deal with all these options, that will play nicely with the others.

Seem reasonable? Am I missing something?

@alindeman
Copy link
Author

MOAR options :) Would changing it to be the default now be a breaking change?

@charlietanksley
Copy link
Collaborator

I'm not entirely sure what constitutes a breaking change. It is a change in current behavior that is unexpected. I can't say for sure whether it would actually mess anyone up, but I suppose it could.

My instinct is to create a version 2.0 branch, add your feature as the default there, and then when we are ready we can transition to the new version. I have a couple of ideas for things we should change in 2.0 (I have an issue here about handling options in a more sane way, and I really want to get tests around this thing so we can merge pull requests more quickly and confidently). Reasonable?

@charlietanksley
Copy link
Collaborator

I think we need @skalnik to chime in here; I'm not entirely sure what to do and I don't feel completely comfortable making any calls like this without his input.

@skalnik
Copy link
Owner

skalnik commented Mar 18, 2013

I think a 2.0 branch w/this being the default there makes sense. I'm definitely in favor of making options a bit more sane :)

Tests would be AMAZING. Like I've mentioned in the past, I don't know of a good way of doing tests other than having sample ruby projects with different test setups and having a small script that automates opening up vim, running vim-vroom, and then having the tester manually ensure it ran. @charlietanksley I remember you mentioned something about tests, what was that again?

@charlietanksley
Copy link
Collaborator

@skalnik Here is what I started: https://github.com/charlietanksley/vim-vroom-testing. It works for what it does, but I think either one of the new VimL test frameworks (which I can't really figure out 😦) or some custom steps using Aruba would be a better way to go.

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

3 participants