Ale only updates after entering and leaving insert mode multiple times.

[DasOhmoff]

Hello. Thank you for your support.

There is an issues that I cannot resolve:

1. When I type code that has syntax errors and exit the insert mode, Ale does not show the syntax errors, until I enter and leave insert mode once again.
2. When I fix the syntax error and exit the insert mode, Ale continues showing syntax errors, until I enter and leave insert mode once again.

Here is a demonstration:

https://user-images.githubusercontent.com/16063186/147383443-990082cb-e049-410d-b526-00aa8c508261.mp4

This is the whole config that I used in this video.

set runtimepath^=~/VimFiles
let &packpath = &runtimepath

call plug#begin("~/VimFiles/plugged")
Plug 'OmniSharp/omnisharp-vim'
Plug 'dense-analysis/ale'
call plug#end()

[nickspoons]

I'm not entirely sure if this will resolve the issue, but I suspect you're not actually using OmniSharp-vim linting in this example: if you try :ALEInfo in a .cs buffer I think it will probably say it is using csc.

Add this to your .vimrc:

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

[DasOhmoff]

Hello, thanks for the answer.

I actually have this already configured in my vimrc. Here is the output of ALEInfo:

[nickspoons]

Ok but that's not being used in your sample

[nickspoons]

Just to rule things out, is ALE linting as expected (on exiting insert mode) with other linters?

Edit: Actually, since the sample wasn't configuring ALE to use OmniSharp, I think this looks like it's on the ALE side. I don't know why though, I don't think I've seen this before in gvim on Windows (but then, I don't often use vim in that environment).

[DasOhmoff]

I tested it out again using the following config:

set runtimepath^=C:/Users/Adam/AppData/Local/Nvim
let &packpath = &runtimepath

call plug#begin("C:/Users/Adam/AppData/Local/Nvim")
Plug 'OmniSharp/omnisharp-vim'
Plug 'dense-analysis/ale'
call plug#end()

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

The results are the same.

I remember using omnisharp some time ago, this error was not there then. I reset omnisharp to the previous commits to find out since when this error started occurring. I found out that this exact behaviour starts to appear since the commit 70405d87b823de1f5de498d77a735ff6a63caf0c. The two or three commits before this one, also seem to cause parts of the problem (maybe). Before these commits there is no such error, even if ale stays the same.

By the way, I use neovim-qt 0.6

[nickspoons]

I'm afraid I can't reproduce this at all. I've downloaded the latest nvim-qt from the github releases page (0.7.0-dev) as well as trying an old 0.5.0 version I had lying around. I've tried to recreate config you've used. I always get ALE linting immediately after leaving insert mode.

[DasOhmoff]

Well, this is very weird. I installed nvim-qt on another pc and set the same config there, and the same error still appears on the other pc. I don't understand why that is, these pc don't really have something special in common if I am not mistaken.

Furthermore I looked into the source code and found the commit called "Do not update buffer when requesting diagnostics"(226cfbc2c5d9a37d589ec61d3fa1d80e08a41911). It adds in the method OmniSharp#actions#diagnostics#StdioCheck the option 'SendBuffer': 0 to the OmniSharp#stdio#Request options. This is the line that causes the issues. If I use 'SendBuffer': 1 instead, then the errors disappear, and then ale works normally again. But of course this causes other issues.

If a not mistaken, then 'SendBuffer': 0 causes the old buffer content to be sent, the content that was there before entering insert mode. Therefore the errors are always 1 step behind the current buffer version.

[nickspoons]

No, 'SendBuffer':0 means that the buffer contents are not sent with the request. The linting is performed based on the server's own version of the buffer, which we update first in an OmniSharp#actions#buffer#Update() call if the buffer has been modified.

Until recently we have been sending the full buffer contents with every request to the server. However this adds an awful lot of overhead, the server doesn't need to be updated that often.

You and I have discussed this before in #738 and #736. At that time you had a similar issue which I couldn't reproduce but we got it working for you. I've had no issues since then.

[nickspoons]

Are your computers particularly fast or slow? My Windows is pretty slow because it runs in a vm on my Linux host, and the Linux machine is ok but not super fast. I wonder if computer speed could be an issue here? In the sense that we send the updated buffer to the server, but it hasn't managed to update its internal state before the next request is processed.

[DasOhmoff]

You are right, I literally added a millisecond of delay between the buffer update and the response request, and now everything works fine.

   " OmniSharp#actions#buffer#Update only updates the server state when the
   " buffer has been modified since the last server update
   call OmniSharp#actions#buffer#Update()
+  sleep 1m
   let opts = {
   \ 'ResponseHandler': function('s:StdioCheckRH', [a:Callback]),
   \ 'BufNum': a:bufnr,

This is proper weird, because my pc is not that fast at all, it is actually quite slow, but yet this made the difference. (edit: when I think about it, it is slow for my standards, it might be average for a non programmer, it is a laptop that I bought some time)

I know that this is not the solution, but at least we now know the problem.

[nickspoons]

I have an idea to send the diagnostics request as a callback from OmniSharp#actions#buffer#Update(). I'm currently on holiday but will have a look at it when I have some time, hopefully next week.

[DasOhmoff]

Hey. Are there any news in regards to this?

[nickspoons]

@DasOhmoff can you try out PR #755 and see if it resolves the issue for you? I assume it's still occurring?

[DasOhmoff]

I am not sure. It is difficult to say, because the behaviour started to become inconsistent, I am not sure since when or why. For now I don't have this issue any more because of the PR, but this could be something that might change later

[cachandlerdev]

Good grief. I'm sorry that I've had to comment on so many GitHub issues at this point, but I seem to be running into every problem under the sun while trying to get this working.

As you should be able to see in the video I linked, I also have a problem with poor performance on Ale's side...but then again, even if I were to figure out a fix for this issue, Ale seems to have another problem on top of this one where it thinks that every using directive is unnecessary, so I would probably have to chime in on #608, too.

I think this might be where I throw in the towel and use a vim plugin in another program for Unity projects, unfortunately.

Screencast from 2023-06-25 20-23-39.webm

[nickspoons]

@BagelSeasoning234 this is again probably not related to the original issue, can you just start a new discussion or issue please? It looks to me like your server is still warming up, this can sometimes take a while with a large solution, which a Unity solution probably is? I don't know I don't use it.

[cachandlerdev]

Alright. After further experimentation while filing a bug report, I noticed that the issue only seems to show up in certain repositories, so assuming I am having the same problem that DasOhmoff reported last year, I can see why he described it as inconsistent. Since I was working on a very barebones WIP Unity project, I was able to create a new version from scratch and copy-paste the code in without experiencing the same issue again.

I'll make the old version of the repo public (it's an extremely basic Flappy Bird clone with 3-4 unfinished C# scripts and a bunch of autogenerated Unity files, so that's no big deal) and link it to a new GitHub issue in case you want to look into the problem.

Edit: it appears as though the issue may have been caused by something else, as I wrote here. Hopefully, everything will be smooth sailing from here on.