Inline-diagnostics for users typing a prompt

[wvhulle]

I am working on a patch that adds inline diagnostics to (partial) Nu prompt based on the linter I made for Nu (nu-lint).

The diagnostics would be shown in real-time as they type (with optional debounce of ~ 300 ms).

Users would have the ability to configure it with a bool or the nu-lint config as in:

$env.config.inline_diagnostics = true
$env.config.inline_diagnostics = {
  ignored: ["snake_case_variables"]
  rules: { trailing_whitespace: "error" }
  groups: { naming: "warning" }
  max_pipeline_length: 100
}

While typing they get something that looks like this (the violations displayed below are just examples)

❯ $env.config.inline_diagnostics = true
wvhulle ~/Code/nushell inline-diagnostics ≡
❯ ^head -20 ./README.md | lines
  ╰─ Unnecessary '^' prefix on external command 'head'
  ╰─ Nushell only checks the final external command's exit code in pipelines.
   ╰─ Use 'first N' to get the first N items

Is this something that might interest you?

I patched nu-cli (to depend on nu-lint optionally with a feature flag and connect its output with reedline) and reedline (for displaying diagnostics from a generic provider). I added an adapter in nu-lint to provide data in the right format to reedline. It is in early stages of development.

Users would be able to set a minimum lint level so they don't get spammed by eager lints.

Here is a screenshot of the above sample, so you can see the colors:

[fdncred]

It took me a while to figure out what's going on here. It seems like this is real-time linting, if I understand correctly aka linting as you type. I think it sounds cool. @ysthakur what do you think about this?

[wvhulle]

@fdncred, yes it is real-time while you are typing with a debounce. There are three violations displayed in the example, but it is just to demonstrate how the formatting looks currently. It uses the lint levels of the violations to color the underlines and violation messages. I am also using a custom prompt, but the diagnostics only take the last line into account.

[ysthakur]

I just installed and tried out nu-lint, and it looks really cool. But I'm not sure this is necessary to have directly in the REPL. I don't know about other people, but I usually write terrible code in the REPL and so would have to only enable the most severe lints to avoid getting spammed. I won't block merging this if you put up a PR, but I think this would be much more useful if integrated into nu-lsp instead. Or we could just point users to nu-lint as the "blessed" linter for Nushell and separately include nu-lint in vscode-nushell-lang (I see nu-lint uses the nightly toolchain, while the Nushell crates purposely use an older toolchain).

This is really cool btw. A lot of work must've gone into it.

[fdncred]

Would this require nu-lint to be installed too? If so, I don't want a dependency on an external tool that the nushell repo doesn't support.

[stormasm]

For me the nightly toolchain is clearly a show stopper...

[wvhulle]

Would this require nu-lint to be installed too? If so, I don't want a dependency on an external tool that the nushell repo doesn't support.

Nu-lint would need to be installed in some way. Either as a dependency or binary. Indeed, adding nu-lint as a dependency to nu-cli, even if optional, is maybe not ideal. It’s quite big and in early stages of development.

Is it possible to having these diagnostics with a more loosely coupled architecture? Maybe with nu Shell hooks or something? The tricky part is that I will need to interact with reedline.

[wvhulle]

For me the nightly toolchain is clearly a show stopper...

The nightly toolchain is not required. I just use it by default for all my new personal Rust projects to get nightly rustfmt formatter and easy access to unstable features.

I’ll have a look if I can implement these realtime diagnostics in reedline with less invasive changes to core Nu crates.

[fdncred]

Is it possible to having these diagnostics with a more loosely coupled architecture?

You may try using the pre_execution hook to see if it supports what you need.

What type of interaction with reedline do you need? We have the commandline command in nushell that interacts with reedline.

[wvhulle]

Is it possible to having these diagnostics with a more loosely coupled architecture?

You may try using the pre_execution hook to see if it supports what you need.

What type of interaction with reedline do you need? We have the commandline command in nushell that interacts with reedline.

The pre_execution hook would only run when the command is executed. I am not sure if the commandline command is the right thing here, since I expect real-time updates with new visual elements.

I have changed the structure a bit and now mostly need reedline integration, see this draft PR (#1004). The PR is not ready for review, but passes my local manual testing. I still need to refactor the actual painting of the diagnostics.

[wvhulle]

Added a second version replacing the custom diagnostics with a small lsp client #1004 (comment)