Feature: Show error above/below the line

[suchcodemuchwow]

I think it's currently not possible to show the error above or below the line, the only option is inline. I believe it would be really helpful to show the error above/below the line also.

[usernamehw]

Not sure how it would be better. Unless, it was a real inset, created between the lines: microsoft/vscode#85682

To implement this feature, extension would need to check if the line above/below doesn't already have a problem. And if it has a problem, what's next: Showing problem in the same line or overwriting the other?

What if the line above/below has more characters (less / no space for the message)? Does it need to get text of the lines from the document and compare them?

It might be better for some problems that are adjacent to empty lines:

import React from 'react';
import './App.css'
                  ^ 🔸 Missing semicolon. 🔸

                  v 🔸 Missing semicolon. 🔸
import './App.css'
import React from 'react';

Right now, extension doesn't care about anything. Just gets diagnostic and prints it. Honestly, I don't see this feature being implemented...

[ItsCubeTime]

Not sure how it would be better. Unless, it was a real inset, created between the lines: microsoft/vscode#85682

To implement this feature, extension would need to check if the line above/below doesn't already have a problem. And if it has a problem, what's next: Showing problem in the same line or overwriting the other?

What if the line above/below has more characters (less / no space for the message)? Does it need to get text of the lines from the document and compare them?

It might be better for some problems that are adjacent to empty lines:

import React from 'react';
import './App.css'
                  ^ 🔸 Missing semicolon. 🔸

                  v 🔸 Missing semicolon. 🔸
import './App.css'
import React from 'react';

Right now, extension doesn't care about anything. Just gets diagnostic and prints it. Honestly, I don't see this feature being implemented...

Idk where exactly the feature is in the extensions API but I know lots of Gitting extensions does this by adding an empty line that is only visible to the user, but is not actually there in the text file.

GitLens does this: https://github.com/eamodio/vscode-gitlens#git-code-lens-

Seems like this is the file where the "ghost inlining" (or whatever one would call it) happens: https://github.com/eamodio/vscode-gitlens/blob/main/src/codelens/codeLensProvider.ts

(Thought I would post here since this is also relevant to my #81 word wrapping request)

[usernamehw]

https://github.com/eamodio/vscode-gitlens/blob/main/src/codelens/codeLensProvider.ts - that's a nice 900 line sample of codeLens api, I'm not doing that. PR is welcome of course.

[ItsCubeTime]

https://github.com/eamodio/vscode-gitlens/blob/main/src/codelens/codeLensProvider.ts - that's a nice 900 line sample of codeLens api, I'm not doing that. PR is welcome of course.

Yes I agree. But the fact that code lens does it shows its possible - and it is at least open source (I bet the developer would share just the basic API calls he used if one was to ask).

[realshovanshah]

+1 for this feature, would be really helpful when the error messages are really long.
Also useful in cases where the work is being done with VsCode in a split window.

[ctf0]

https://github.com/eamodio/vscode-gitlens/blob/main/src/codelens/codeLensProvider.ts - that's a nice 900 line sample of codeLens api, I'm not doing that. PR is welcome of course.

+1 for the option, for anyone up to the task you can use https://github.com/microsoft/vscode-extension-samples/tree/main/codelens-sample

[duncanawoods]

I have a working version of this. I'll make a pull request.

Features

• Shows one or more Code Lens above the diagnostic
• Clicking the Code Lens can be configured to either:
  • show the Problem Window (the vscode api won't let you focus on a specific diagnostic though)
  • open the quick fix menu
  • trigger a web search for the problem
• Supports a message template and filtering like the inline message and the status bar
• Supports a configurable text prefix for an emoji or similar

My Settings

A code lens can't be styled so we are limited to emojis for distinguishing between the types of diagnostic. It's a delicate balancing act. Emojis can make your code painfully ugly... so my preference is to use restrained grey emojis for info/hint but I find I need the red/yellow cue for error/warning. I thought I would like creative choices like flames and monsters... nope, turns out they confuse my tiny over burdened brain.

By keeping the inline message enabled but with a blank message template, we can keep the diagnostic background colour which works nicely. I am also enjoying trying life without the error/warning squiggles. While they can help pin-point the location, they make code harder to read which I find is a pretty bad trade-off. Readability is sacred and should be top priority. An error I had yesterday was a missing underscore in a snake-cased name and I literally could not see the problem because it was obscured by the bloody error squiggle itself!

    "errorLens.messageTemplate": "",
    "workbench.colorCustomizations": {
        "editorWarning.foreground": "#00000000",
        "editorError.foreground": "#00000000",
        "editorInfo.foreground": "#00000000",
    },

It also means linting isn't so painful. A single stray character can cause eslint to put squiggles under your entire file which is not very helpful. Disabling the squiggles and using a code lens is so much nicer:

Rust

My main motivation has been starting to learn rust. Every line I write is creating new baffling error messages! This extension has been a god send but rust gets verbose just trying to access a value with all the

if let Some(mut my_simple_thing) = other_thing.get_mut().unwrap_or_else(|| format!("oh_my_god...

...and then errors about nested algebraic types get super long so that showing them at end of lines just wasn't working. It started to get more annoying than helpful to be teased by the first few character of an error.

When tiling a few windows you really don't have much spare horizontal space at all:

This example is interesting because it shows how with a Code Lens, we can see multiple hints on the same the line which is super helpful because they are tracking the ownership through the function because a rust errors tends to involve a whole function rather just the line where the compiler bails:

[duncanawoods]

I'm pretty happy with it. It can still be defeated by really long multi-line errors or when multiple tools generate diagnostics for the same line. It can create a readable tooltip but that means using a mouse. Blegh!

I have been experimenting with a web-view that tracks the cursor and updates for the closest errors like the current status bar feature. It has the advantage of being dockable where you want, much more legible, doesn't have any styling restrictions and can have some useful buttons.