Feedback wanted! stdio

[nickspoons]

Asynchronous server interactions have been added, with the server switch from the HTTP to stdio version of OmniSharp-roslyn.

In my personal usage the new version has been very good, much faster and smoother. I also hope this will remove some barriers to getting OmniSharp running initially for new users, as the OmniSharp-vim python dependency and OmniSharp-roslyn libuv dependency are both removed.

I'm opening this issue in the hope of getting some feedback from anyone trying out the new server. Bugs should be reported of course, but anyone who doesn't have any problems is most welcome to comment or give a 👍, and that way I can get a better idea of when to make stdio the default (currently the feature is opt-in only with the g:OmniSharp_server_stdio flag).

[jpfeiffer16]

I'm trying it out and so far so good. I do notice a lot more speed. I have noticed on a few occasions though that when I pick a code action, it seems like the omnisharp server is duplicating the files in the solution in memory or something because I get a bunch of errors about duplicate/ambiguous classes etc.. Restarting the server fixes it. Still trying to get something that is more reproducible.

[stevearc]

I did a quick check to see if it's a drop-in replacement. I updated to OmniSharp 1.32.19 (64-bit windows) and set let g:OmniSharp_server_stdio = 1. I'm running inside of WSL with neovim and it doesn't appear to be working. Is there an easy way to get a verbose log of the communication to/from the the OmniSharp process?

[nickspoons]

@stevearc yes all requests responses are logged, I meant to add an option to turn that off but forgot. I also forgot the command to open the log, similar to :OmniSharpOpenPythonLog, but the stdio log is next to the python one, in ~/.vim/plugged/omnisharp-vim/stdio.log (if you're using vim-plug)

[nickspoons]

@jpfeiffer16 yes I've experienced that too at times. I think it's a server bug, where server requests sent before the server is fully loaded store the buffer as unattached files. AFAIU the idea is that once the project is loaded in the server, the unattached buffer is recognised as belonging to the project and included, but that doesn't always happen, so in the server you end up with both the unattached buffer and the project file. Hence, duplicates.

Currently I listen for a specific message from the server before I mark the server as "loaded". I'm thinking I need to extend this to listen for "project XYZ" loaded from the server from_all_ solution projects, which will mean a longer wait before the server accepts requests, but will avoid these errors. Perhaps if the bug is fixed in OmniSharp-roslyn at some stage we can do back to this current behaviours.

Note that this bug also occurs occasionally in the HTTP version.

[nickspoons]

Another thing that might be handy is a statusline function. I have one I use in my config, where a flag indicates the server state - I think I might move this from my config into OmniSharp-vim.

[nickspoons]

@stevearc did you run :OmniSharpInstall after seeing let g:OmniSharp_server_stdio = 1?

[nickspoons]

@stevearc I have added a generic :OmniSharpOpenLog command, which opens the stdio.log in stdio mode and the python.log in HTTP mode. The logging now also respects g:OmniSharp_loglevel (values 'debug', 'info' and 'none') so make sure to let g:OmniSharp_loglevel = 'debug'.

[stevearc]

I didn't run :OmniSharpInstall because I was under the impression that it wouldn't install the Windows version if run from inside WSL.

Found my issue though, I forgot to check the path to the exe and it changed because I unzipped the new server differently. Now it works! I'd recommend printing an error message if the executable path couldn't be found.

Most of the things I use regularly seem to work, but I'm not getting ALE linting. Is there another config change I need to make for that?

[nickspoons]

Oh no you're right, it won't install the correct version inside WSL. In that situation I tend to open a Windows gvim and do the :OmniSharpInstall from there.

Printing some error messages is a good idea, I'll try to set up some listeners.

I'm not sure why you're not getting ALE linting, that works fine for me out of the box I think. I'll try later on with a clean config.

[nickspoons]

@stevearc do you have an up-to-date ALE? The linting depends on its relatively new ALEWantResults autocmd

[nickspoons]

@jpfeiffer16 I have updated the "loaded" listener now so it listens for all projects to be loaded. For me, this appears to have removed the "Duplicate definition" errors.

I have made this optional, so for users who don't experience the duplication issue, or are trying different versions of OmniSharp-roslyn which might not have this problem, you can let g:OmniSharp_server_stdio_quickload = 1

[stevearc]

Found the issue. I'm using .vim/ftplugin/cs.vim to set my OmniSharp config, including let g:OmniSharp_server_stdio = 1. Unfortunately, the ALE autocommand is set inside plugin/OmniSharp.vim, which is executed when vim loads (well before filetype events). I got it working by moving my config into .vimrc.

I think an easy fix for this would be to always register the s:ALEWantResults function with the autocommand and do the variable check & early return there.

[nickspoons]

@stevearc good idea, done.

[stevearc]

Everything's working for me now! I'll keep using it and see if anything else turns up.

I've noticed it starts up much faster. I used to have to wait 1-2 minutes for the server to spin up, but now it's closer to 10 seconds. Awesome! Thanks for all your work on the upgrade!

[nickspoons]

You're welcome! Yeah it's pretty speedy, I'm finding it much nicer to work with - and more reliable too, since updating the listeners for completed projects. Being able to listen for all server events as they arrive rather than polling is really nice.

There are a few more improvements I can build on on top now, like listening for unrequested diagnostics, and the TextChanges mentioned (4 years ago!) in #215. Currently we don't receive changes that way from the server but that could well be the way we request them ... I'll take a look when I find some more time.

[stevearc]

Back again 😅

NeoVim apparently doesn't have deletebufline. Some more information here: dense-analysis/ale#1739

I'm also seeing that when I :w a file the buffer "bounces" from written back to dirty. It seems to be a problem with my autoformatter. I have it configured to call OmniSharpCodeFormat on BufWritePre. Is it possible that this operation has become asynchronous with the stdio implementation? Is there any way to force it to complete synchronously?

[nickspoons]

Oh I didn't realise deletebufline was new, and not in neovim. I'd better do something about that - I'll add a patch check or something.

Yes :OmniSharpCodeFormat is asynchronous now, so it's not going to work in a BufWritePre. We could do 2 things:

1. Add an option to make it synchronous, which involves sleeps until the response has returned (this is how OmniSharp#GetCompletions works when being run as omnifunc)
2. Add an optional callback, so you'd be able to do something like this:

   " ~/.vim/after/ftplugin/cs.vim
   autocmd BufWriteCmd <buffer> call OmniSharp#CodeFormat({->execute('noau w')})

   I haven't tried this, but the docs say that BufWriteCmd is expected to do its own writing, so using this method should work.

I prefer option 2 - what do you think?

[nickspoons]

@stevearc I have implemented option 2. I tested it out and it works well I think - just make sure you use :noautocmd in the callback, or you'll start an endless loop!

function! s:CBCodeFormat() abort
  noautocmd write
  set nomodified
endfunction
autocmd BufWriteCmd <buffer> call OmniSharp#CodeFormat(function('s:CBCodeFormat'))

I also added a test for deletebufline.

[stevearc]

Works! Thanks for the fast fix! I'll keep an eye out for other issues 🙃

[psuong]

Hey there, the stdio implementation works quite well on my side too! Even on Unity side it's quite responsive :)

[nickspoons]

Thanks @psuong, that's good to hear. It seems to be working very well, I'd like to make it the default now but I need to work out how to do it smoothly, ideally it should detect existing HTTP servers and use the correct mode for those. Perhaps echo a recommendation to switch to stdio (for vim8 and neovim which can handle it).

[jmzagorski]

@nickspoons thank you for all the hard work with this repo by keeping it up to date and being responsive to issues. I switched to stdio in WSL and GVIM and it is super fast! I had no issues following your instructions. Great work!

[Incubatio]

Had a working version before, tried to upgrade everything and use stdio, can't get it to work anymore.
The weirdest part is that I don't have any particular error from :OmniSharpOpenLog

Log report no error and stops after it started up, last log being: process 43572 run {"Event":"log","Body":{"LogLevel":"INFORMATION","Name":"OmniSharp.Stdio.Host","Message":"Omnisharp server running using Stdio at location '/Users/myuser/dev/csharp/myApp' on host -1."},"Seq":14,"Type":"event"}

Using shortcut gs do display :OmniSharpGotoDefinition in vim, but nothing happens.

Here is my environment:

Mac os 10.13.5
vim 8.1.1450 and MacVim 8.1.1950
OmniSharp v1.32.20
let g:OmniSharp_server_stdio = 1
let g:OmniSharp_server_use_mono = 0
All vim plugin including ale are to latest version (installed via vundle)

[nickspoons]

@Incubatio do you mean you have previously had a working Http version, or a working Stdio?

It looks like you have installed the Stdio with :OmniSharpInstall. And I assume you have restarted Vim after that?

Could you try clearing the log, adding let g:OmniSharp_loglevel = 'debug' to your .vimrc, and then loading vim with a .cs file and try some things please, i.e. :OmniSharpGotoDefinition, :OmniSharpHighlightTypes, :OmniSharpGlobalCodeCheck? Then post the full log here, or link to a pastebin or something.

[scottbass47]

I'm having a very similar problem. I'm using the new Stdio server with Neovim but every OmniSharp command I results in nothing happening. Here is a pastebin with let g:OmniSharp_loglevel = 'debug' set and running a few of the commands you listed. https://pastebin.com/VVLH4Tb6

[Incubatio]

Yes it was previously working with the http version.
It took me few hours to get it to work the first time (as there was a http connection error with very recent roslyn server version), and I spent 2 more hour yesterday trying to update it to stdio.

I've installed it and re-installed it with different options many times, but yes the main way of doing it was via :OmniSharpInstall.

let g:OmniSharp_loglevel = 'debug' is already in my vimrc as you mentioned it in this thread.

As I have literally no log on my work machine, I'm gonna try on on a different machine where I never installed it. I will post again later today.

[Incubatio]

Re-installed everything on another machine at home, same result.

what I do:
After everything is installed, I open a cs file (either from a simple dotnet console application, or from a more complex unity project), then I tried twice :OmniSharpGotoDefinition, :OmniSharpHighlightTypes, :OmniSharpGlobalCodeCheck

log generated via :OmniSharpOpenLog: https://pastebin.com/yxc5ykTu

As you can see still no log about Omnisharp commands, they fail, and fail silently.

It is weird because changing the loglevel doesn't log anything more.
I went directly in the source to force set "debug", doesn't log anything more.
Went back again and changed the log function to:

  function! s:Log(message, loglevel) abort
    call writefile([a:message], s:logfile, 'a')
  endfunction

aaaannd still doesn't log anything more.

I'm gonna go through your sources, read it and try to add some logging ...

[Incubatio]

Ok I seem to have identified the source of the problem:
in stdio.vim:124, when building the raw request, job.loaded is always false , which leads to always early return.
When I remove the condition || !job.loaded, omnisharp seem to work properly again.

now i need to figure why job.loaded is always false.

[Incubatio]

stdio:27, in ListenToServer you're expecting a communication that never happen in my environments "OmniSharp.MSBuild.ProjectManager".
And there are no timeout or no contraption to notify the user that he didn't received that message and that your app didn't load.

I'm not familiar at all with the whole omnisharp process, so I will leave it to someone else to apply a fix that could work for everyone.
In the meantime a quickfix is to enable let g:OmniSharp_server_stdio_quickload = 1

Note: I would suggest to rename ListenToServer to handleServerRequest.
ListenToServer feels like it will be executed only once, it infers that your code is switching to a state where you're listening, like you're opening a socket to listen to the server.

[nickspoons]

Oh great debugging, thanks! That's very interesting that you aren't getting any of those events. Yes adding a timeout there is a good idea, I'll do that.

I'm currently trying to improve that area as I don't think it works properly as it is anyway, see OmniSharp/omnisharp-roslyn/issues/1521

[nickspoons]

That does seem to be the case, and yes, using your proxy does make nvim start working on Windows (it already worked for me in Windows WSL). So I think you're bang on, but I don't know really what our options are from here. The proxy is brilliant for debugging but we shouldn't need it, right? I can't find any documentation on how to send data to neovim channels differently than the way we currently are.

[jpfeiffer16]

Yeah. I'm kind of stuck here to. We definitely shouldn't need the proxy for it to function as normal. My only thought was that maybe there is some nvim channel setting that might help. But I haven't found anything like that.

…

On Sun, Jun 16, 2019, 5:57 AM Nick Jensen ***@***.***> wrote: That does seem to be the case, and yes, using your proxy does make nvim start working on Windows (it already worked for me in Windows WSL). So I think you're bang on, but I don't know really what our options are from here. The proxy is brilliant for debugging but we shouldn't need it, right? I can't find any documentation on how to send data to neovim channels differently than the way we currently are. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#468?email_source=notifications&email_token=ACCVOZDM7XIRNFWGP74I6WTP2YTBXA5CNFSM4HOBC6Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXZLL4I#issuecomment-502445553>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCVOZDOQIGGG7EIOPQ6DALP2YTBXANCNFSM4HOBC6ZQ> .

[nickspoons]

If anyone is interested in a server status statusline flag, I've now created vim-sharpenup which currently includes the code actions available functionality from the wiki and a configurable statusline function. I haven't managed to get it to work well in airline yet but there is some lightline config suggestions in the README, as well as plain 'statusline' configuration of course.

[jpfeiffer16]

Looks awesome! I'll definitely be giving it a try when I get a chance.

[Confuset]

I don't really know if this is stdio related but I received lots of No actions taken for lots of different codeactions I tried these days.
Then I downgraded OmniSharp-Roslyn to v1.32.0 and then it started working again. Which version of roslyn you guys are using?

[nickspoons]

@Confuset I've been using 1.32.20, haven't tried out 1.33.0 yet

[jpfeiffer16]

I'm on 1.32 as well right now.

…

On Sat, Jul 6, 2019, 1:42 AM Nick Jensen ***@***.***> wrote: @Confuset <https://github.com/Confuset> I've been using 1.32.20, haven't tried out 1.33.0 yet — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#468?email_source=notifications&email_token=ACCVOZBMQ3UKH5ERZ2G4H5DP6BEFJA5CNFSM4HOBC6Z2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKUNQQ#issuecomment-508905154>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCVOZHYYWTD6KOBTEVT2SDP6BEFJANCNFSM4HOBC6ZQ> .

[hannasm]

Really appreciate all the work going into this. It's awesome being able to do my work from VIM.

On initial install, i was upgrading from an older syntastic configuration and there were all sorts of major errors going on a simple switch to the stdio version. After i removed syntastic and installed ALE everything worked great though.

Also on install, that line in the readme about 'installing a specific version of roslyn' tripped me up for a bit. I believe that the version number in the example is completely broken on ubuntu, and so when i copy / pasted without really reading too carefully omnisharp server was failing to start.

I've been running in tmux with a couple sessions connected to the same solution. Saving changes to one file (in one vim process) doesn't cause a re-parse in the other vim processes that are open on the same solution. If i close and re-open the file it will parse again but it would be nice to have some automated orchestration for that.

I also seem to be have some issues with 'missing namespace' errors. I can build / run my solution fine, but references to my nuget packages are being highlighted as 'the type or namespace does not exist' errors by vim. I'd assume someone else has nuget references working and it's probably a more localized issue but any pointers on tracking that down would be appreciated?

[hannasm]

Once i added the configuration for ale to ~/.vimrc the issue with nuget projects went away. This is in the readme so my own fault for not migrating properly. I guess there was a default c# linter that was having problems with the nuget stuff that needed disabled:

let g:ale_linters = {
\ 'cs': ['OmniSharp']
\}

This is a lot easier than the experience launching omnisharp server manually when poking around. It probably is a bit slower and doesn't handle the concurrent edits across processes as nicely. Maybe I should be using vim splits instead of tmux-splits.

I infrequently have seen some other weird stuff going on but i can't reliably produce any of these issues unfortunately:

• file suddenly has errors on every line and must restart vim to fix, it seems to be happening during loading / early on more so than once things have been running for a while.
• hang for 30-45 seconds, vim is non-responsive and syntax highlighting seems to be broken when it comes back to life, it does eventually recover though
• auto-indenter got lost on one occasion, it was putting me one space past where the tab stop should be most of the time, and then i think it even thought it needed a full indent after a semicolon in one region. restart fixed it.

The extra keybindings / lightline settings in sharpen-up are a nice touch!

Setting "g:OmniSharp_highlight_types = 2" must ocur before loading omnisharp plugin , that wasn't so obvious to me from the README. Furthermore, in stdio mode, we won't actually see highlighting until omnisharp finishes loading and then hits an InsertLeave. Maybe stdio should selectively be kicking this command off once the server is fully loaded (or watching for server loaded event?)

autocmd User OmniSharpStarted,OmniSharpReady,OmniSharpStopped call OmniSharpHIghlightTypes

[nickspoons]

Hi there @hannasm, thanks very much for the feedback.

I guess there was a default c# linter that was having problems with the nuget stuff that needed disabled

Yes ALE has a default mcs linter, which isn't great.

This is a lot easier than the experience launching omnisharp server manually when poking around. It probably is a bit slower and doesn't handle the concurrent edits across processes as nicely. Maybe I should be using vim splits instead of tmux-splits.

I'm not totally sure what you mean here? But yes in my experience keeping a single Vim session running for a project has the best results - launching language servers is slow, but that's a one-off cost and everything is fast once the server is loaded. OmniSharp-vim will also quite happily open multiple servers if you are navigating between solutions - I used to have a tmux window per solution but these days I keep a single Vim running and I use Vim tabs for solutions/projects. This is just personal preference of course.

Your idea of detecting file changes and updating OmniSharp-roslyn is interesting, but I don't really feel that it's OmniSharp-vim's place - adding file watchers on all files in the solution would be quite heavy for the client. It might make sense on the server though ... I don't know this is something that OmniSharp-roslyn may implement?

in stdio mode, we won't actually see highlighting until omnisharp finishes loading and then hits an InsertLeave. Maybe stdio should selectively be kicking this command off once the server is fully loaded (or watching for server loaded event?)

This is something I'm working on here. The idea is that requests made while the server is loading are "replayed" once the server is loaded. The problem is in detecting exactly when the server is fully loaded. Currently OmniSharp-vim reports the server as "loaded" when certain diagnostics are received, and actually calling :OmniSharpHighlightTypes at this point works fine (as your autocmd shows). However calling some server endpoints such as /codecheck (which is what ALE requests call) at this time result in the current buffer being loaded incorrectly - this buffer will subsequently never receive correct diagnostics until the server is reloaded. This is an OmniSharp-roslyn bug and has been reported here - once that is resolved I'll merge the replay branch, which will result in a much smoother startup experience.

• file suddenly has errors on every line and must restart vim to fix, it seems to be happening during loading / early on more so than once things have been running for a while.

This may be the same OmniSharp-roslyn issue?

• hang for 30-45 seconds, vim is non-responsive and syntax highlighting seems to be broken when it comes back to life, it does eventually recover though
• auto-indenter got lost on one occasion, it was putting me one space past where the tab stop should be most of the time, and then i think it even thought it needed a full indent after a semicolon in one region. restart fixed it.

I haven't seen these - what OS and vim version are you using?

Setting "g:OmniSharp_highlight_types = 2" must ocur before loading omnisharp plugin

Yes all global settings should be set in a .vimrc and not in an ftplugin script (is that what you're referring to?). This is because your .vimrc is sourced on Vim launch, then omnisharp-vim/plugin/omnisharp.vim (along with all other <plugin>/plugin/*.vim scripts). ftplugin scripts (yours and those in your plugins) are sourced later, after the initial configuration is complete.

As far as I've seen this is pretty standard plugin behaviour. Some of the plugin initialisation could be moved to the ftplugin script, but most of it needs to happen just once and the omnisharp-vim/plugin/omnisharp.vim script is the logical place.

[hannasm]

There definitley appears to be some correlation with the one issue and the timing of omnisharp-loading. To be honest the other issues could have as well and i just didn't connect the dots in those other cases.

I'm running vim 8.0 on ubunutu 18. I mostly just have vim plugins as suggested from the README, for C# development on a special virtual machine. Here's a full list of my plugins (excluding the color scheme). I know editorconfig-vim interacts with the indentation settings to some extent or another and could have been involved too

ale  deoplete.nvim-4.0  echodoc.vim  editorconfig-vim  lightline-ale  lightline.vim  nvim-yarp  omnisharp-vim  unite.vim  vim-csharp  vim-dispatch  vim-hug-neovim-rpc  vim-pathogen  vim-sharpenup  vim-wordmotion

I'm not seeing these errors frequently and everything is working great in general, those are probably edge cases whatever I would open a separate issue if i was able to identify valid repo steps or see the frequency increase.

Setting "g:OmniSharp_highlight_types = 2" must ocur before loading omnisharp plugin

I was actually just thinking about mentioning this in the relevant part of the README, i'm sure it's fairly common practice. I had put this setting after pathogen#inject() originally and combined with the other highlighting issue led to some confusion.

[nickspoons]

Setting "g:OmniSharp_highlight_types = 2" must ocur before loading omnisharp plugin

I was actually just thinking about mentioning this in the relevant part of the README, i'm sure it's fairly common practice. I had put this setting after pathogen#inject() originally

That should be fine - I haven't used pathogen for a few years but don't you put all the pathogen stuff at the top of your .vimrc, and everything else below? That's certainly how I do it with vim-plug.

[nickspoons]

For anyone interested: I have merged the ReplayRequestsOnLoad feature, which means that users who have highlighting and ALE enabled will see these automatically triggered once the server is loaded. Unfortunately there has not been any movement on OmniSharp/omnisharp-roslyn#1521 so I have added a 1 second delay before replaying the highlight/diagnostics requests. Hopefully when some OmniSharp-roslyn refactorings like this one come in, we'll be able to remove this and speed things up.

[jpfeiffer16]

So far it works great for me! I love not having to manually highlight the first file I open. Thanks!

[mszyszko]

Here is the issue that I am having right now:

• I get the following error using OmniSharpFindUsages whenever I select a usage in a file that is different than the current file:

Error detected while processing function OmniSharp#proc#vimOutHandler[5]..OmniSharp#stdio#HandleResponse[19]..<SNR>50_FindTextPropertiesRH:
line   35:                                                                                                           
E964: Invalid column number: 7

(I am navigated properly, I just get that error message every time)

• After jumping to usage in another file and using OmniSharpFindUsages again (in order to go back to the previous file) I get the `-- No lines in buffer --' and have an empty buffer.

Tested on Windows with:

• VIM 8.1 (Included pathes: 1-1836),
• two OmniSharp Versions: 1.34.1 and 1.34.2
• the following simple dotnet project (I use OmniSharpFindUsages on the Class1):

.
├── OmniSharpTest.ConsoleApp
│   ├── Class1.cs
│   ├── OmniSharpTest.ConsoleApp.csproj
│   ├── Program.cs
│   ├── bin
│   └── obj
└── OmniSharpTest.sln

Program.cs

using System;

namespace OmniSharpTest.ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            var test = new Class1();
            Console.WriteLine("Hello World!");
        }
    }
}

Class1.cs

using System;
using System.Collections.Generic;
using System.Text;

namespace OmniSharpTest.ConsoleApp
{
    public class Class1
    {
    }
}

.vimrc

syntax on
filetype indent plugin on

let g:OmniSharp_loglevel = 'debug'
let g:OmniSharp_server_stdio = 1
let g:OmniSharp_selector_ui = ''
let g:OmniSharp_timeout = 5 
set completeopt=longest,menuone,preview
let g:OmniSharp_highlight_types = 2

let g:OmniSharp_highlight_groups = {
\ 'csUserIdentifier': [
\   'constant name', 'enum member name', 'field name', 'identifier',
\   'local name', 'parameter name', 'property name', 'static symbol'],
\ 'csUserInterface': ['interface name'],
\ 'csUserMethod': ['extension method name', 'method name'],
\ 'csUserType': ['class name', 'namespace name', 'enum name', 'struct name']
\}

augroup omnisharp_commands
    autocmd!

    " Show type information automatically when the cursor stops moving
    autocmd CursorHold *.cs call OmniSharp#TypeLookupWithoutDocumentation()
 
    " The following commands are contextual, based on the cursor position.
    autocmd FileType cs nnoremap <buffer> gd :OmniSharpGotoDefinition<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fi :OmniSharpFindImplementations<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fs :OmniSharpFindSymbol<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>fu :OmniSharpFindUsages<CR>

    " Finds members in the current buffer
    autocmd FileType cs nnoremap <buffer> <Leader>fm :OmniSharpFindMembers<CR>

    autocmd FileType cs nnoremap <buffer> <Leader>fx :OmniSharpFixUsings<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>tt :OmniSharpTypeLookup<CR>
    autocmd FileType cs nnoremap <buffer> <Leader>dc :OmniSharpDocumentation<CR>
    autocmd FileType cs nnoremap <buffer> <C-\> :OmniSharpSignatureHelp<CR>
    autocmd FileType cs inoremap <buffer> <C-\> <C-o>:OmniSharpSignatureHelp<CR>

    " Navigate up and down by method/property/field
    autocmd FileType cs nnoremap <buffer> <C-k> :OmniSharpNavigateUp<CR>
    autocmd FileType cs nnoremap <buffer> <C-j> :OmniSharpNavigateDown<CR>

    " Find all code errors/warnings for the current solution and populate the quickfix window
    autocmd FileType cs nnoremap <buffer> <Leader>cc :OmniSharpGlobalCodeCheck<CR>
augroup END

" Start the omnisharp server for the current solution
nnoremap <Leader>ss :OmniSharpStartServer<CR>
nnoremap <Leader>sp :OmniSharpStopServer<CR>

let mapleader=","

(and no other plugins)

Any ideas about what could've caused that unwanted behavior?

Please let me know if there are any other information that would be useful for you.

EDIT

I forgot to add that this problem does not exist if let g:OmniSharp_highlight_types = 0.

[nickspoons]

@mszyszko I opened issue #496 to track this

[resolritter]

Is deoplete working with stdio? I get this error:

2019-08-11 19:26:13,178 ERROR Error autocompleting 'Types'
Traceback (most recent call last):
  File "/home/joaopaulo/.config/.plugged/omnisharp-vim/rplugin/python3/deoplete/sources/deoplete_OmniSharp.py", line 50, in gather_candidates
    return self._do_gather(context)
  File "/home/joaopaulo/.config/.plugged/omnisharp-vim/rplugin/python3/deoplete/sources/deoplete_OmniSharp.py", line 61, in _do_gather
    json=True)
  File "/home/joaopaulo/.config/.plugged/omnisharp-vim/python/omnisharp/util.py", line 206, in getResponse
    json=json)
  File "/home/joaopaulo/.config/.plugged/omnisharp-vim/python/omnisharp/util.py", line 210, in doRequest
    target = urlparse.urljoin(host, path)
  File "/usr/lib/python3.6/urllib/parse.py", line 488, in urljoin
    base, url, _coerce_result = _coerce_args(base, url)
  File "/usr/lib/python3.6/urllib/parse.py", line 120, in _coerce_args
    raise TypeError("Cannot mix str and non-str arguments")
TypeError: Cannot mix str and non-str arguments

If it's a known issue, please point me to it; I couldn't find one in the tracker.

[nickspoons]

@reaysawa no, no specific stdio support has been added for deoplete - thanks for pointing that out.

You're welcome to open an issue - and if you want to and know a bit of python, feel free to implement it! I don't use deoplete myself but if nobody else does it, I will try to find some time at some stage.

[levihb]

I'm not getting any completion using the stdio version. I've tried it with deoplete and without, all I get are the normal words buffers as suggestions.

[nickspoons]

@levihb as stated in the previous comment, there is no deoplete support (still!). To get completions without deoplete, use <C-x><C-o> - this will never return anything but actual semantic completions. Or use a different autocompletion plugin, such as asyncomplete.

If you still aren't getting completions, there is something wrong with your setup - please open an issue and I'll help you get it worked out.

[psuong]

@levihb as stated in the previous comment, there is no deoplete support (still!). To get completions without deoplete, use <C-x><C-o> - this will never return anything but actual semantic completions. Or use a different autocompletion plugin, such as asyncomplete.

If you still aren't getting completions, there is something wrong with your setup - please open an issue and I'll help you get it worked out.

Hmm I'd love to try and figure out how to write the python source for deoplete - this might not be the right thread for this - but know of resources on how to get started to writing a completion source? I can kind of get the structure from the current implementation for the http server.

@nickspoons

[nickspoons]

@psuong I'm really not sure how to go about it, as a non-deoplete user. The existing deoplete source may not be the best place to look - the OmniSharp-vim python implementation is very well structured and the deoplete source integrates with that perfectly, but we don't have any similar python integration with the stdio stuff.

I wonder if a better place to look would be other plugins which use async job servers. Perhaps LSP clients like vim-lsc?

[psuong]

Alright - thanks @nickspoons. I'll start poking around this upcoming weekend.

[levihb]

@nickspoons regarding asyncomplete, I'm not always getting suggestions, e.g.:

var x = GetThis(argument1

Which will show all the GetThis methods with arguments of type argument1, but then soon as I press , it disappears and just starts to suggest basic suggestions again?

Similarly with:

var x = new List<

It will show completion up to here. But then when I do e.g.

var x = new List<int>(

Suddenly I lose all suggestions?

Is this a problem with asyncomplete or omnisharp, and do you know how to fix it?

[nickspoons]

@levihb can you please open a new issue, and include some screenshots or asciinema or something demonstrating exactly what you mean?

[nickspoons]

Right, over a year later and I would really like to make stdio the default, and simplify the minimal .vimrc to get a really good OmniSharp experience.

The 2 blockers for this have been:

1. The Windows neovim stdio error, which has now been fixed in neovim, see Stdio isn't working with NeoVim v0.4.0 in Windows #499
2. A way of detecting which server is actually installed, so users can be informed if the wrong one is used, rather than just presented with a wall of errors and a broken OmniSharp. To deal with this, I've made PR Project management #598, where the HTTP server is detected and stopped cleanly. A warning message then tells users to either install the stdio server with :OmniSharpInstall, or explicitly add let g:OmniSharp_server_stdio = 0 to their .vimrc.

I was pretty keen to make the switch with these in place but ... unfortunately, the latest OmniSharp-roslyn release does not work properly. There's been some kind of change in project loading system, so opening a large solution such as the OmniSharp-roslyn source will not load completely - just the first project. So I need to look into what they've done there. I don't want to switch to stdio by default, then immediately have to tell users to downgrade their server.