-
Notifications
You must be signed in to change notification settings - Fork 166
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
Comments
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? |
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. |
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 ;) |
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. |
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. Ideally, (from my point of view) Omnisharp would just provide the NRefactory server and a vim plugin for project file management. |
It would be pretty simple to detect YCM and disable the completion stuff in OmniSharp in that case. |
OmniSharp and YCM didn't collide at all when I tried. |
"It would be pretty simple to detect YCM and disable the completion stuff in OmniSharp in that case." "OmniSharp and YCM didn't collide at all when I tried." 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? |
Yes. Just these two lines would need disabling AFAIK. setlocal omnifunc=OmniSharp#Complete |
Okay, how would you detect if YCM is installed? |
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. |
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 ;) |
I removed those settings completely from the plugin as #34 . It's up to the user to add them in vimrc |
I would like to bump this issue. The server should be a separate repo. |
@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! |
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? |
@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. |
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.
The text was updated successfully, but these errors were encountered: