Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Show error above/below the line #74

Open
suchcodemuchwow opened this issue Feb 25, 2021 · 8 comments
Open

Feature: Show error above/below the line #74

suchcodemuchwow opened this issue Feb 25, 2021 · 8 comments

Comments

@suchcodemuchwow
Copy link

suchcodemuchwow commented Feb 25, 2021

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
Copy link
Owner

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
Copy link

ItsCubeTime commented Apr 5, 2021

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
Copy link
Owner

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
Copy link

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
Copy link

+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
Copy link

ctf0 commented Apr 17, 2023

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
Copy link

duncanawoods commented Apr 6, 2024

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

image

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

image

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:

image

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:

image

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:

image

@duncanawoods
Copy link

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!

Screenshot from 2024-04-09 14-28-22

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.

Screenshot from 2024-04-09 14-33-08

image

usernamehw added a commit that referenced this issue Apr 14, 2024
Feature: Support a Code Lens to show the error above the line (#74 )
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants