Add support for "on the fly compilation" even when Auto Save is off about vscode-go HOT 7 CLOSED

The suggestion in the README is to turn on Auto Save in Visual Studio Code, which saves your code as you type. It's a generally nice feature once you get used to it, but especially nice with the vscode-go extension as you then get on-the-fly error reporting.

I hadn't see goflymake before - but that looks like it might make it possible to do this without relying on build-on-save + auto-save. If that works well, I'd be open to moving error checking away from the 'on-save' hook and to an on-th-fly model that works even with auto-save turned off.

from vscode-go.

Basically what my sublime plugin does is run flymake when the file changes, and then not for a minimum of 5s (to balance responsiveness of the editor with getting error messages when typing). It works quite well. if you have questions or need help with the impl let me know.

from vscode-go.

Thanks @newhook. That sounds great.

BTW - Definitely also open to PRs for this if you are interested.

from vscode-go.

I've been working on this and have it basically working :) However, one thing i ran into with the latest master is that if have:

foo_test.go

and then type

package foo_test

this ends up creating a bunch of files
f.test
fo.test
foo.test

and so forth. Is this a known issue?

from vscode-go.

One other thought: With support for flymake it isn't necessary or even desirable to use auto-save any longer. In fact, I would recommend against it. This means that its easy then to support gofmt (or goimport or whatever) on save - #14

from vscode-go.

@newhook I haven't seen the first issue you mention. Could you open another issue to track this with details on how to repro it. From a quick test of what you mention I didn't see those files being generated.

On the second point I completely agree. I think doing both of these features together could make sense.

Feel free to open up a WIP PR when you have something working here.

from vscode-go.

Per gitter discussion, we'll go ahead and close this for now, since we're not ready to move over to a model where Go tools that need global understanding can operate on in-memory state yet.

We'll likely want to revisit this in the future.

from vscode-go.