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

splitting the vim part from the server part #18

Closed
chtenb opened this issue May 6, 2013 · 17 comments
Closed

splitting the vim part from the server part #18

chtenb opened this issue May 6, 2013 · 17 comments

Comments

@chtenb
Copy link
Contributor

chtenb commented May 6, 2013

Is it an idea to split up the server from the vim files?
If they are in a separate repository, omnisharp is better pluggable into other software. For example, if one wants to use omnisharp for YCM, or within a different editor, one doesn't want to clone the vim files.

More specifically, I would create a repo for the server, and a repo for the vim plugin, which has the server as a submodule. The latter means that cloning the vim plugin would automatically clone the server as well.

@nosami
Copy link
Contributor

nosami commented May 6, 2013

So, you don't use the OmniSharp vimscript at all for your YCM plugin? I didn't realise that.

OmniSharp is more than just a completion plugin though. I couldn't see myself just wanting to use the completion side of OmniSharp without the other functionality (present and future) too.

It does kind of make sense for use with other editors... but nobody is using OmniSharp for that yet.

Thoughts?

@chtenb
Copy link
Contributor Author

chtenb commented May 7, 2013

I would like to utilize other features of the NFactory library too, but I like to integrate as much as possible with existing vim plugins. This is because that makes things behave consistently throughout different filetypes, which is neat and userfriendly. Besides it reduces the risk of collision between plugins. Also it makes the software more likely to be used by others and less work to find and install.

I think that many of the omnisharp features can be integrated in plugins such as vim-autoformat, syntastic and of course YCM. The only thing I don't see being integrated is the refactoring/code actions part, but I may be wrong.

That being said, I wouldn't want you to quit your own integration into vim, but I merely would want to open up space for the previous. By splitting up the repo's, your vim integration stays intact.

@nosami
Copy link
Contributor

nosami commented May 7, 2013

I'm not sure that I agree but on the other hand I don't really have anything against the suggestion apart from the work involved. Leave it with me and I'll get onto it within the next few days. I don't get a lot of time to spend on this.

One thing you might want to consider is the ReloadSolution command. Very useful for keeping completions in sync when switching branches. It's much faster than stopping and restarting OmniSharp as the assemblies are already loaded, especially for large solutions.

I plan to add many more features in the weeks to come, mostly related to project management... stuff like creating projects, adding/deleting files to projects, integrated test runner etc... basically everything I need to get my day job done without using VS ;)

@chtenb
Copy link
Contributor Author

chtenb commented May 7, 2013

Sounds good. I'm aware that there are C# specific things like project management that cannot be integrated into other plugins, simply because it is too C# specific. I'm not sure yet how to cope with that. I guess your vim stuff must come to aid there :) Looking forward to it.

@chtenb
Copy link
Contributor Author

chtenb commented May 8, 2013

I've been thinking about this a little more. First I want to mention that refactoring actions can be integrated in YCM too, which I just deduced from this issue: ycm-core/YouCompleteMe#255 (comment). This proves my previous remark wrong.
Secondly, the main reason that I asked for splitting the vim files from the server files, is that installing Omnisharp as a bundle (beside YCM) now would result in having two completer plugins installed for C#, which would collide. (Same for syntastic.) If there is another way to avoid this, without having the user to explicitly configure stuff, that might be a (better) solution to this problem as well.

Ideally, (from my point of view) Omnisharp would just provide the NRefactory server and a vim plugin for project file management.
What do you think?

@nosami
Copy link
Contributor

nosami commented May 8, 2013

It would be pretty simple to detect YCM and disable the completion stuff in OmniSharp in that case.

@nosami
Copy link
Contributor

nosami commented May 8, 2013

OmniSharp and YCM didn't collide at all when I tried.

@chtenb
Copy link
Contributor Author

chtenb commented May 9, 2013

"It would be pretty simple to detect YCM and disable the completion stuff in OmniSharp in that case."
That sounds like a plan actually. This may well be the easiest and best way to do it.

"OmniSharp and YCM didn't collide at all when I tried."
Weird enough Omnisharp and YCM don't collide currently, but that may change any moment.
Besides, it is just not good to have multiple plugins doing the same thing. That's asking for problems.

So summarizing the current idea: when a user wants to use YCM and omnisharp, he has to install both of them as a bundle, and Omnisharp will detect plugins that it can integrate with (currently just YCM), and disable its own functionality for that. Is that right?

@nosami
Copy link
Contributor

nosami commented May 9, 2013

Yes. Just these two lines would need disabling AFAIK.

setlocal omnifunc=OmniSharp#Complete
"don't autoselect first item in omnicomplete,show if only one item(for preview)
set completeopt=longest,menuone,preview

@chtenb
Copy link
Contributor Author

chtenb commented May 9, 2013

Okay, how would you detect if YCM is installed?

@chtenb
Copy link
Contributor Author

chtenb commented May 9, 2013

BTW, a second way to do it, is to disable the omnisharp completion from within the YCM plugin. But I don't know if that's reasonably possible.

@nosami
Copy link
Contributor

nosami commented May 9, 2013

No problem. It's no big deal for me to do it. Lots of OmniSharp users would want to use YCM but I'm not so certain about the other way around ;)

@nosami
Copy link
Contributor

nosami commented May 15, 2013

I removed those settings completely from the plugin as #34 . It's up to the user to add them in vimrc

@PaulCampbell
Copy link
Contributor

I would like to bump this issue. The server should be a separate repo.

@nosami
Copy link
Contributor

nosami commented May 20, 2013

@Chiel92 , @PaulCampbell The server component now lives here https://github.com/nosami/OmniSharpServer . Just need to sort out the submodule stuff and update the documentation.

Go crazy!

@nosami nosami closed this as completed May 20, 2013
@PaulCampbell
Copy link
Contributor

Nice one man! Regarding submodules... Do you think it's neccessary? With the sublime plugin I intend to add the server executables to the git repo (and distributed package) . The server is a dependency of the plugin rather than a part of it. This may be different for the vim plugin...

Does raise the question about whether binaries should be versioned and downloadable :)

Seems a simpler solution though?

@nosami
Copy link
Contributor

nosami commented May 21, 2013

@PaulCampbell Well, I wouldn't say it's necessary but I think I may be dealing with a different target audience than you. I suspect, but don't know, that most users of the vim plugin are using linux. Linux users expect source code.

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