Add live error feedback as you type #903

tylerstillwater · 2017-03-31T18:16:41Z

This PR adds an optional (disabled by default) live error reporting system.

Closes #883

Motivation

I've used many editors in which a live as-you-type feedback system was available. I've found that it helps me catch errors as they happen and fix them immediately. This constant feedback allows me to code more quickly, as I am still in the context of an error when I see it, rather than having to come back to it after the build has failed.

Implementation

To implement this feature, I have taken advantage of my custom fork of gotype, called gotype-live.

My fork enables the processing of an in-memory version of a file by accepting the contents via stdin. This allows us to get errors back from gotype as we code, rather than having to save the file first.

Configuration

The default configuration for this feature, as of now, is as follows:

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

The delay value configures a timer that waits for nms after a keystroke before running the process. If a keystroke occurs during that window, the timer is reset.

Example

Below is a short video showing the feature in action. This video was recorded with a 250ms delay time.

msftclas · 2017-03-31T18:16:46Z

@tylerb,
Thanks for your contribution.
To ensure that the project team has proper rights to use your work, please complete the Contribution License Agreement at https://cla.microsoft.com.

It will cover your contributions to all Microsoft-managed open source projects.
Thanks,
Microsoft Pull Request Bot

tylerstillwater · 2017-03-31T18:17:56Z

@ramya-rao-a I would greatly appreciate a code review, as I have never worked in typescript before. I want to make sure my code is clean and correct. 😄

msftclas · 2017-03-31T18:23:45Z

@tylerb, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request.

Thanks, Microsoft Pull Request Bot

ramya-rao-a · 2017-04-02T05:48:01Z

package.json

@@ -541,6 +541,23 @@
          },
          "description": "Tags and options configured here will be used by the Add Tags command to add tags to struct fields. If promptForTags is true, then user will be prompted for tags and options. By default, json tags are added."
        },
+        "go.liveErrors": {
+          "enabled": {


The "enabled" and "delay" objects here should be inside "properties":{}. Only then will the validation work i.e green squiggly appears when user types anything other than a boolean for "enabled"

ramya-rao-a · 2017-04-02T05:48:55Z

src/goInstallTools.ts

@@ -26,7 +26,8 @@ function getTools(goVersion: SemVersion): { [key: string]: string } {
 		'go-symbols': 'github.com/acroca/go-symbols',
 		'guru': 'golang.org/x/tools/cmd/guru',
 		'gorename': 'golang.org/x/tools/cmd/gorename',
-		'gomodifytags': 'github.com/fatih/gomodifytags'
+		'gomodifytags': 'github.com/fatih/gomodifytags',
+		'gotype-live': 'github.com/tylerb/gotype-live'


This should be inside an if block so that only people who have opted-in to use the live error feature get the tool installed when Go: Install Tools is run

ramya-rao-a · 2017-04-02T05:50:17Z

src/goLiveErrors.ts

+			return;
+		}
+
+		diagnosticCollection.clear();


The problem with clearing the diagnosticCollection is that any diagnostics prior to running the processFile will disappear. For example: all linting and vetting warnings will be removed.

You could create a new collection and all the errors from gotype there, but on save you will end up with multiple errors (1 from gotype the other from go build) showing up in the Problems pane.

What you could then do is check the current collection if it has any errors/warnings for the same line that gotype is returning an error. If yes, then let the current collection win, if not then go ahead and add the error to the new collection.

ramya-rao-a · 2017-04-02T06:11:27Z

@tylerb Great job! Your typescript is spot on :)

I have a left a few comments, have a look.

tylerstillwater · 2017-04-02T18:37:43Z

@ramya-rao-a

I've made the changes you requested.

Regarding the changes for preserving existing diagnostics, here is the approach I've used:

Load existing diagnostics for this file
Delete existing diagnostics for this file
Iterate through the previous diagnostics and re-add any non-error level diagnostics
Iterate through errors reported by gotype-live, if any, and add them to the array
Set the new diagnostic array into the diagnosticCollection

The goal is to preserve all non-error level diagnostics, because gotype-live should be reporting any error-level diagnostics that we'd see during a build, so we are safe to clear those out. This lets us avoid duplicate reports while preserving diagnostics that already existed.

Please review and let me know if you need anything else.

ramya-rao-a · 2017-04-02T18:56:50Z

package.json

+            "enabled": false,
+            "delay": 500
+          },
+          "description": "Tags and options configured here will be used to configure how the live errors system behaves."


copy paste error ? :)

Hmm.. I don't see an error. What am I missing? :)

Oh I meant that the description needs an update :)

ramya-rao-a · 2017-04-02T19:04:57Z

src/goLiveErrors.ts

+		return;
+	}
+
+	let config = <GoLiveErrorsConfig>vscode.workspace.getConfiguration('go')['liveErrors'];


why not re-use goLiveErrorsEnabled() ?

I use config.delay a few lines below, otherwise I would have reused that function, yeah.

I'm re-using it now, since we are also checking for autoSave.

ramya-rao-a · 2017-04-02T19:05:31Z

src/goLiveErrors.ts

+}
+
+export function goLiveErrorsEnabled() {
+	return <GoLiveErrorsConfig>vscode.workspace.getConfiguration('go')['liveErrors'].enabled;


add a null/undefined check for vscode.workspace.getConfiguration('go')['liveErrors'] before accessing the enabled property

Also, I think that when auto save is enabled, we shouldn't be enabling live errors. That would just be redundant work being done by build and gotype.

Can you add that check here?

ramya-rao-a · 2017-04-02T19:16:28Z

src/goLiveErrors.ts

+		//
+		// error-level diagnostics will be reported by this process, so we want to
+		// clear out the existing errors to avoid getting duplicates
+		diagnosticCollection.delete(uri);


gotype-live should be reporting any error-level diagnostics that we'd see during a build

If the above assumption is indeed true, I'd still suggest having 2 separate diagnostic collections.

One for warnings (this will be fed by the linting and vetting), the other for errors (this will be fed by build and live errors).

This way you don't have to copy the warnings from currentDiagnostics.
The rest of your code here (delete diagnostics for uri etc.) can remain

I am not too picky about this one though. Perf wise, it shouldn't be a problem because you are only touching diagnostics for a single file. But it just feels wrong (gut wise) to be copying array items everytime liveError is run

I tried using two separate diagnostics, but when I called .set on the live diagnostic object, it erased the warning diagnostics that were there. It appeared to me that you can only have one diagnostic object in use, per file, at a time.

I may have done something wrong, though. Is it possible for me to use two separate diagnostic objects on the same file and the same time and the diagnostics from both objects will be displayed?

ramya-rao-a · 2017-04-02T23:08:11Z

This is great work @tylerb!

I just added 1 commit with some description update, edit to README etc.

Will merge as soon as the tests are green.

tylerstillwater · 2017-04-02T23:09:26Z

Thanks! And thanks for cleaning up that last bit. I appreciate your feedback and help on this!

…

On Apr 2, 2017, 5:08 PM -0600, Ramya Rao ***@***.***>, wrote: This is great work @tylerb (https://github.com/tylerb)! I just added 1 commit with some description update, edit to README etc. Will merge as soon as the tests are green. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#903 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAEUlD0M4NID1aicIbLTg9EoN_IoYLjuks5rsCpdgaJpZM4Mv_Y7).

tylerstillwater · 2017-04-02T23:51:54Z

Looks like the gometalinter test failed. I can't retry, though, it seems.

23doors · 2017-04-04T21:08:19Z

src/goLiveErrors.ts

+		return false;
+	}
+	let autoSave = vscode.workspace.getConfiguration('files')['autoSave'];
+	if (autoSave !== null && autoSave !== undefined && autoSave !== 'off') {


I know it is closed but to be honest, I don't see a reason why autosave is checked at all. I use autosave onFocusChange and why would it be clashing with a linter running after some delay? Even autosave afterDelay makes little sense to check as it may just be some much higher value than linter delay.

I was erring on the side of caution.

Good point on the fact that auto save onFocusChange and onWindowChange has no affect whatsoever.

I was concerned with the autosave on delay. Then you have build and gotype both running and giving essentially similar results and overriding each other.

On second thoughts, it is definitely being over cautious. We can remove the check in the next update. And leave it up to the user to choose between the 2 features if the experience is not pleasant

keithballdotnet · 2017-04-11T05:57:35Z

@tylerb just wanted to come along and say that this is a great feature. Love it!!! Thank you!!

tylerstillwater · 2017-04-11T05:59:42Z

@keithballdotnet glad you're enjoying it! You're most welcome!

Add live as-you-type error reporting

a76f8d2

msftclas added the cla-required label Mar 31, 2017

msftclas added cla-signed and removed cla-required labels Mar 31, 2017

Fix linter errors

4335c9f

tylerstillwater changed the title ~~Add live as-you-type error reporting~~ Add live error feedback as you type Mar 31, 2017

ramya-rao-a suggested changes Apr 2, 2017

View reviewed changes

tylerb added 3 commits April 2, 2017 12:30

Correct properties so validation will work

910cd8d

Do not install gotype-live if not enabled

0f65407

Preserve existing non-error diagnostics

f57bc9c

Fix lint errors

8ce24b6

ramya-rao-a suggested changes Apr 2, 2017

View reviewed changes

tylerb and others added 4 commits April 2, 2017 14:31

Clean indentation

4b51004

Add null/undefined/auto-save checks

816b8c4

Use separate diagnosticCollections for warn/err

aaf028a

update to setting description

b6d764c

ramya-rao-a approved these changes Apr 2, 2017

View reviewed changes

ramya-rao-a merged commit 6db72e6 into microsoft:master Apr 2, 2017

23doors reviewed Apr 4, 2017

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add live error feedback as you type #903

Add live error feedback as you type #903

tylerstillwater commented Mar 31, 2017 •

edited

Loading

msftclas commented Mar 31, 2017

tylerstillwater commented Mar 31, 2017

msftclas commented Mar 31, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a commented Apr 2, 2017

tylerstillwater commented Apr 2, 2017

ramya-rao-a Apr 2, 2017

tylerstillwater Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

tylerstillwater Apr 2, 2017

tylerstillwater Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

ramya-rao-a Apr 2, 2017

tylerstillwater Apr 2, 2017

ramya-rao-a commented Apr 2, 2017

tylerstillwater commented Apr 2, 2017 via email

tylerstillwater commented Apr 2, 2017

23doors Apr 4, 2017

ramya-rao-a Apr 4, 2017 •

edited

Loading

23doors Apr 4, 2017

keithballdotnet commented Apr 11, 2017

tylerstillwater commented Apr 11, 2017

Add live error feedback as you type #903

Add live error feedback as you type #903

Conversation

tylerstillwater commented Mar 31, 2017 • edited Loading

Motivation

Implementation

Configuration

Example

msftclas commented Mar 31, 2017

tylerstillwater commented Mar 31, 2017

msftclas commented Mar 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ramya-rao-a commented Apr 2, 2017

tylerstillwater commented Apr 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ramya-rao-a commented Apr 2, 2017

tylerstillwater commented Apr 2, 2017 via email

tylerstillwater commented Apr 2, 2017

Choose a reason for hiding this comment

ramya-rao-a Apr 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

keithballdotnet commented Apr 11, 2017

tylerstillwater commented Apr 11, 2017

tylerstillwater commented Mar 31, 2017 •

edited

Loading

ramya-rao-a Apr 4, 2017 •

edited

Loading