search

posit-dev / positron

Positron, a next-generation data science IDE
Other
2.53k stars 79 forks source link

diagnostics should show less aggressively when typing code in an editor #979

Open jjallaire opened 1 year ago

jjallaire commented 1 year ago

At least in Python, we currently have a very happy trigger finger with showing diagnostics (both in the console and in the source editor, though we're dealing with the console in a separate issue #1114). For example, if you simply enter this:

>>> x =

You will get a red underline indicating an "error" in your code:

Screen Shot 2023-08-08 at 1 49 04 PM

Especially for less experienced developers I think this will be at best annoying and at worst provoke users to actually figure out "what's wrong" with the code they just entered.

I think we need a fancier set of heuristics for when to show diagnostics around active edits. One thing I've seen work well is to never show diagnostics on the line where the cursor currently is. We could also never show diagnostics if the current line is empty. Another thing we could do is have diagnostics run debounced over a longer period (e.g. 3 seconds). The goal is to never mis-detect and incomplete edit as an error or warning.

We'll need to play around with different strategies in order to get this just right.

seeM commented 1 year ago

This also seems to be the case for R:

image
jmcphers commented 1 year ago

I wonder if we should disable diagnostics in the console entirely (as part of this work, in addition to tuning the source editor)

juliasilge commented 1 year ago

I wonder if we should disable diagnostics in the console entirely

The diagnostics are super helpful in a source file but seems not so helpful (and very hard to get right) for an interactive "I am typing" kind of situation. I think turning them off in the console could be a good option.

kevinushey commented 1 year ago

Also agree we should turn of diagnostics in the Console. If we wanted to maintain some amount of diagnostics, I'd suggest only the basic "syntax" diagnostics (e.g. checking for matching brackets, unclosed quotes)

petetronic commented 1 year ago

We'll tackle the Console first, but then the additional step is still needed in tuning the Editor.

jmcphers commented 1 year ago

This would be helpful to avoid issues like https://github.com/rstudio/positron/issues/1051.

petetronic commented 1 year ago

We're going to deal with the Console in a different issue #1114, this one will remain focused on the speed of which diagnostics show up while you're typing in the editor.

petetronic commented 1 year ago

Moving this to after Alpha but keeping the priority high as the experience doesn't meet our expectations for release.

petetronic commented 1 year ago

Would a simple first approach be to just not show diagnostics on the current line? Would this be too much to suppress?

juliasilge commented 8 months ago

This came up during our alpha user feedback session. The specific situation cited was opening a quote for a string, which causes the rest of your file to suddenly get highlighted as a string (huge color change which feels like flashing).

kevinushey commented 8 months ago

The specific situation cited was opening a quote for a string, which causes the rest of your file to suddenly get highlighted as a string

Shouldn't this normally be handled by auto-pairing of quote characters?

I think RStudio also dodges a bit of this pain by delaying the highlight / tokenization of lines later in the document; waiting for the user to be idle for ~700ms or so.