Issue with Vim Bindings and type provider

[sillyotter]

I'm running the apt-get provided of vim on a new mint xfce install, with mono-3.10 latest build and a fsharp head build. Mostly I've found the fsharpbindings and new vim scripts to work nicely, but I did find one or two problems I thought I'd report.

Here is a project that exhibits these issues. It contains a sample project that shows the issues.

This project was a bit of a test of the bindings as its using a type provider. In addition to the above problem, I noticed that opening up something that uses the type provider starts off marking some things as missing but after a save of the file its fine.

Before a save it looks like this:

After the save it looks like this:

[rneatherway]

I think this is related to #761. Thanks for reporting. Is it OK if I incorporate these projects as tests?

[sillyotter]

Please do. The type provider came form MSDN examples.

[sillyotter]

Just did an experiment with the tools version set to 4.0 in the .fsproj file, and saw some interesting behavior. With vim, in a console, everything looks fine, none of the regex or typeprovider errors show up. With gvim, the Test/test.fs file shows errors related to the typeprovider and Main/main.fs showed problems with typeprovider and regex libraries, but all went away after a save. Not quite the same errors as before, it no longer thinks i need to add System to the import list, but the errors are still showing up until I save the file (no changes needed, just a :w)

Before and after images below:

[sillyotter]

Actually, re the last comment, it doesn't really require a save - loading another file and closing it will cause the first buffer to refresh and loose its errors. Also, when looking at that second file, you can still see the squiglly underlines displayed. I think that last bit might be vimscript code that needs to know that the buffer has been hidden.

[rneatherway]

OK, I think that is probably a VIM issue to do with when the parsing is done. One for @kjnilsson, although it might be preferable to wait until the project loading is fixed to make sure it isn't any residual issue with that.

[sillyotter]

One more tiny bit of information, the issue mentioned above, where the errors didn't show up in the console seems to be timing dependent. On one machine the console shows no errors, one another, it does until the refresh. Smells like a timing problem.

[kjnilsson]

When loading a new file in a new vim instance I have noticed that the parse that is triggered after load times out due to fsac jitting most likely. I occasionally have to do e after loading a new file to make sure the current loclist is correct. Perhaps I should be compiling fsac with - aot as part of the make install to improve initial load times? // @rneatherway

ah yes the loclist (which is used for error "squigglies") is set per window (ircc) so switching to a new buffer in the same window may not clear it. Should be easy to fix.

[kjnilsson]

btw now sure why I didn't get a notification when I got mentioned above. Strange.

[rneatherway]

aot is worth trying, but I haven't found it that useful on Linux i.e. it doesn't seem to make as much difference as we would like.

What do you mean when you say the parse times out? Parse is fire and forget, and then it will print the errors when it's finished.

[kjnilsson]

sorry I mean the error check (which involves a parse then blocking until a result it returned) has got a timeout which I have set fairly short not to hang the ui for too long. When fsac is just starting up it is more likely to timeout. I am only really suggesting --aot to reduce fsac startup times which I assume to be slightly slow due to JIT-ing.

[kjnilsson]

here is a PR that may help when switching buffers in the same window https://github.com/fsharp/fsharpbinding/pull/768

[rneatherway]

I see. Is it not possible to have a check on idle that doesn't send any commands to fsac but just checks if there are any messages waiting in the pipe? And then display the latest errors if they've arrived.

I know what you mean about --aot, but I tried it on fsc/fsi and required DLLs a while back without much improvement in startup time. As FSharp.Compiler.Service is basically doing the same as fsc/fsi, I would be surprised if it made a big difference. I would be interested to know the results if you try it though.

[kjnilsson]

I considered that but too keep the results reasonably fresh I'd basically have to send a parse request on each normal mode edit to the file or each time it left insert which I could do but might keep fsac a bit too busy.

On 17 October 2014 13:41, Robin Neatherway notifications@github.com wrote:

I see. Is it not possible to have a check on idle that doesn't send any commands to fsac but just checks if there are any messages waiting in the pipe? And then display the latest errors if they've arrived.

I know what you mean about --aot, but I tried it on fsc/fsi and required DLLs a while back without much improvement in startup time. As FSharp.Compiler.Service is basically doing the same as fsc/fsi, I would be surprised if it made a big difference. I would be interested to know the results if you try it though.

— Reply to this email directly or view it on GitHub https://github.com/fsharp/fsharpbinding/issues/762#issuecomment-59506650 .

Karl Nilsson twitter: @kjnilsson blog: coderkarl.wordpress.com

[rneatherway]

I issue a parse every time the editor is idle for a second or so (and the text has changed), and it seems to work reasonably well. I think FCS has a lot of caching built in that we can rely on there.

[kjnilsson]

I'll give it a try at some point. The problem with vim is there is only one timer of sorts (CursorHold) so I can't issue a parse and then later display errors. I either have to issue a parse at some other event such as entering normal mode or doing an edit and then display errors on CursorHold. It could work. Currently I am looking to improve the fsi integration which has it's own set of constraints. :)

On Friday, 17 October 2014, Robin Neatherway notifications@github.com wrote:

I issue a parse every time the editor is idle for a second or so (and the text has changed), and it seems to work reasonably well. I think FCS has a lot of caching built in that we can rely on there.

— Reply to this email directly or view it on GitHub https://github.com/fsharp/fsharpbinding/issues/762#issuecomment-59542212 .

Karl Nilsson twitter: @kjnilsson blog: coderkarl.wordpress.com

[sillyotter]

Earlier I reported that when I used gvim and switched to a different buffer, I could still see the 'red squiggly lines' (undercurl) from the previous buffer. I noticed a commit earlier that mentioned it removed these marks when buffer was loaded, and so I did some testing. When I move from .fs file to .fs file, those marks do seem to be cleared. But when I moved from a .fs file to a .fsproj file, they were still there. This makes sense as the clearmatches() and setloclist(0) calls are done when the fsharp.vim script is run (on load, it seems) but it appears we really need to do it on buffer leave(?) to ensure that it happens when switching filetypes.

I apologize for just dropping that earlier report in here as a comment, it would have been easier to track as its own bug. Feel free to create one and we can move this discussion over there.

[kjnilsson]

I see. Yes that makes sense. I'll try to find the appropriate event.

On Saturday, 18 October 2014, sillyotter notifications@github.com wrote:

Earlier I reported that when I used gvim and switched to a different buffer, I could still see the 'red squiggly lines' (undercurl) from the previous buffer. I noticed a commit earlier that mentioned it removed these marks when buffer was loaded, and so I did some testing. When I move from .fs file to .fs file, those marks do seem to be cleared. But when I moved from a .fs file to a .fsproj file, they were still there. This makes sense as the clearmatches() and setloclist(0) calls are done when the fsharp.vim script is run (on load, it seems) but it appears we really need to do it on buffer leave(?) to ensure that it happens when switching filetypes.

I apologize for just dropping that earlier report in here as a comment, it would have been easier to track as its own bug. Feel free to create one and we can move this discussion over there.

— Reply to this email directly or view it on GitHub https://github.com/fsharp/fsharpbinding/issues/762#issuecomment-59612619 .

Karl Nilsson twitter: @kjnilsson blog: coderkarl.wordpress.com

[kjnilsson]

https://github.com/fsharp/fsharpbinding/pull/769 <- PR that hopefully fixes the buffer switching issue.

[sillyotter]

Thanks, I was working on something very similar myself, though I was using bufhide rather than bufleave. I don't know which is right. My idea was that if I had two panes up in a split window, bufleave might trip it if I toggled to the next pane, though the original was still visible. I hadn't done enough testing to know if that was true or not. I'll let you know.

[sillyotter]

OK, I did my testing, BufHidden doesn't seem to work at all, using it results in the red error markings showing up when a new buffer is loaded over top of it. But BufLeave has the issue I thought it might.

What I did to create the issue:

Open up a fsharp file with errors in it.

Split the window (vsp) to a different file. On my test machine this got rid of the margin error markers, but not the underlines.

Click back to the fsharp file, nothing happens. Click on the new non fsharp file, and the underlines disappear from the error containing buffer as well. Clicking back to the fsharp and it doesn't bring redisplay the error.

I have a pull request just about to be submitted that deals with this. Should be submitted shortly.

[rneatherway]

Guys, @kongo2002 has submitted a PR to use syntastic at #770. Might that work around some of these problems?

[sillyotter]

It certainly seems worth a try. My usage of syntastic with other languages is shallow, but the little I know of it makes it seem that it does quite a lot of what this plugin would need done.

I pulled @kongo2002's PR and tried it. There were a few small problems, but it looks promising. I left notes on the PR (#770) with what I saw, but it looks promising. I need to test it more under gvim, but under console vim it worked nicely.

[sillyotter]

With @kongo2002's syntastic changes in place, most of the problems I reported are fixed. I did find that part of this particular report still occurs. Specifically, this report links to a project that has a type provider in it. If you modify the .fsproj files in there to use tool version 4.0 instead of 12.0, things mostly work as expected, except for one thing. When opening up the type provider project, I still see the behavior I noticed above in the last pair of screen shot images. Syntastic is set to check on open, and when I open the project I'm told that the ProviderImplementation stuff is unknown. Once i force a syntastic scan again (usually by saving the file) those errors go away.

Everything else seems perfect, but for some reason the first time we ask for errors from the fsharp compiler it gets this bit wrong. But not the second time

[kjnilsson]

Probably a time-out on first call. We need time-outs not to hang the UI indefinitely but perhaps they can be tweaked.

On 24 October 2014 13:20, sillyotter notifications@github.com wrote:

With @kongo2002 https://github.com/kongo2002's syntastic changes in place, most of the problems I reported are fixed. I did find that part of this particular report still occurs. Specifically, this report links to a project that has a type provider in it. If you modify the .fsproj files in there to use tool version 4.0 instead of 12.0, things mostly work as expected, except for one thing. When opening up the type provider project, I still see the behavior I noticed above in the second pair of screen shot images. Syntastic is set to check on open, and when I open the project I'm told that the ProviderImplementation stuff is unknown. Once i force a syntastic scan again (usually by saving the file) those errors go away.

Everything else seems perfect, but for some reason the first time we ask for errors from the fsharp compiler it gets this bit wrong. But not the second time

— Reply to this email directly or view it on GitHub https://github.com/fsharp/fsharpbinding/issues/762#issuecomment-60379388 .

Karl Nilsson twitter: @kjnilsson blog: coderkarl.wordpress.com

[rneatherway]

I think there is something strange going on with FSharp.AutoComplete, as this shows up in emacs as well. I will be releasing a new version with fixed project support and a more recent version of FSharp.Compiler.Service over the weekend, so let's revisit it after that is done, in case it helps.

[sillyotter]

The most recent commits seem to have fixed this issue as well. It no longer shows the incorrect errors on startup. Great work! I think this and the other issue I brought up can be closed, but i've lost track of what all we mentioned in them. :)

[rneatherway]

OK, I'll close this for now, but feel free to reopen or create a new issue if it isn't working as expected.