Feedback as you type

[tylerstillwater]

One of the things I miss about Sublime Text is the linter setup I had. I created a sublime linter package that called gotype to display errors, then changed gotype to accept the contents of a file via stdin, so the in-memory edited file could be used when linting. This allowed gotype to provide as-you-type feedback.

To enable this functionality, you simply call gotype exactly as you would before, but add -lf <path/to/file.go> and send the contents of that file via stdin.

I would love to have this functionality in vscode-go, so I am opening an issue here to get some discussion going around it. I'm happy to do the work myself, but I am not sure where to start.

The questions that would need to be answered in order for this to work are:

1. Can VSCode/vscode-go execute the linter automatically as you type, preferably after a set timeout?
2. Can VSCode/vscode-go send the path of the currently focused file as an argument to the command?
3. Can VSCode/vscode-go send the contents of the currently focused file via stdin to the command?

If these things are possible, then we should be able to integrate this lint-as-you-type functionality.

I suppose it would be best to also ask: would anyone else even be interested in this functionality? I find it extremely useful to get feedback as I type to catch all sorts of simple mistakes. I am able to code more quickly this way.

And, lastly, here is a link to gotype-live. (It may be a good idea to try and get this integrated into gotype proper, of course.)

[ramya-rao-a]

Hey @tylerb ,

Answers to your 3 specific questions are Yes, Yes, and Yes. :)

Before we dive into this feature, I have a few questions first though

• Currently the Go extension supports the use of golint or gometalinter for linting. Is there anything specific about gotype that you feel either of the 2 existing options doesnt do for you?
• For feedback as you type, have you tried the Auto Save feature of VS Code? You can configure the delay after which VS Code would automatically save your file. And since build/lint/vet are currently run on save, this would be the same as feedback as you type. Only catch is that you might have to turn formatOnSave off so that things dont keep changing under your cursor.

[tylerstillwater]

Hey @ramya-rao-a!

So golint is great and I love using it. However, it doesn't report the kinds of errors I'm wanting to see as I code.

For example, if you create a go file containing this:

package main

import "fmt"

func main() {
	_ = fmt.Errorf("Capital error.")
	myString := "hi there"
	fmt.Println(mystring)
}

golint reports:

test.go:6:17: error strings should not be capitalized or end with punctuation or a newline

gotype reports:

test.go:8:14: undeclared name: mystring
test.go:7:2: myString declared but not used

From the gotype documentation:

The gotype command, like the front-end of a Go compiler, parses and type-checks a single Go package.

Seeing these kinds of errors as you type is very useful, as in the example above, where you can catch a simple typo immediately.

As for the Auto Save feature, that is certainly an option, but I would hate to lose the auto formatting on save functionality in order to have live-feedback as I type.

I hope this clears up my motivation here. Thanks for the response! Let me know what you think.

[ramya-rao-a]

This opens up questions around lint/vet/build as you type as well

cc @rakyll @campoy @mattetti for their thoughts

[23doors]

FYI, gometalinter uses gotype by default (among other linters) so it's actually already supported. And I believe that you can also use "go.lintTool": "gotype" and it would work just as well. Personally I found gotype riddled with bugs so stopped using it.
But an option to lint as-you-type without save (so it's not autoformatted) would be pretty neat.

[campoy]

I don't think that gotype should be considered a linter, if what it does is type checking.
This is actually more of a vet kind of tool, or maybe even simply a compiler.

Having lint or vet running as you type seems like a bit of a distraction personally, so I'd like to have this under some setting so I can turn it off.
There's also concerns about CPU consumption, of course.

[tylerstillwater]

Agreed. It is not necessarily a linter. I suppose a more succinct restatement of what I am trying to do is have live feedback of any errors that I may get when I go to compile, so I can fix those errors before compiling or running tests, etc. I've found it to be very helpful when using sublime.

And it should definitely be configurable as to whether it runs or not. Perhaps this is a new concept, something that lives, optionally, along the lint-on-save concept that currently exists.

[mattetti]

I'm with Francesc on this one, I wouldn't want that feature ON by default either and I would strongly suggest to add latency before triggering gotype so you can hopefully only trigger when the user stopped typing and therefore not max out her CPU every keystroke.

[rakyll]

Agreeing with what @campoy says about the gotype.

What's so bad about linting on save? It is not necessary a lot of effort to press (cmd+s/control+s) once a while if you need early feedback. An editor that lints my code as I live code is nothing but noise to me.

[tylerstillwater]

I spent a bit of time this morning getting a dev environment set up for vscode-go. I've managed to put together a quick, working example of what I'm looking to do.

Here's a quick gif to see what it looks like. Currently the debounce is set at 200ms, but would definitely be configurable were this to be accepted as a feature.

The code is rough and would require a good deal of cleanup before I could submit a PR, but so far I am very much enjoying how it behaves.

[23doors]

Coming from IntelliJ IDE, this is something I would really enjoy as well.

[campoy]

Definitely not against, as long as it's not on by default

…

On Fri, Mar 31, 2017 at 10:00 AM Robert Kopaczewski < ***@***.***> wrote: Coming from IntelliJ IDE, this is something I would really enjoy as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#883 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACIkDEWGvnB6-o4IPqI06ihRAg10C2oJks5rrTEsgaJpZM4MnWAO> .

[ramya-rao-a]

This is out in the latest update (0.6.59)

[stanleynguyen]

Hi @ramya-rao-a I'm new to vscode and this extension so pardon me if I ask stupid question. But this "lintOnType" option seems to be no where to be found, would you mind assisting on this? Thank you!

[ramya-rao-a]

@stanleynguyen Welcome to VS Code :) Add this to your settings:

  "go.liveErrors": {
    "enabled": false,
    "delay": 500
  }

[stanleynguyen]

@ramya-rao-a Thanks for your prompt reply. I have added this previously, but it only tells me about syntax errors in the code, not code style problems (i.e. not commenting on top of exported functions), that's what I'm looking for :)

[ramya-rao-a]

@stamblerre We dont have lint on type feature. This current issue was to track showing of syntax errors and so I assumed that's what you were referring to

Linting errors show up once you save your changes as long as the setting go.lintOnSave is set to package or workspace