vscode: Error hover semantic information should be rendered separate of error message

From @octref in #62159

This is a regression on the diagnostics display.

1.28:

Insiders:

In both case, the diagnostics returned are:
const diagnostics = {
  code: "unknownProperties",
  source: "css.lint.unknownProperties",
  message: "Unknown property: 'foo1'"
}

If we have access to semantic information we should render it much better. The message should come first. Then the source on a separate line, with a Source: label preceding it and in non-monospace font (since source should be a user-readable string like CSS Lint). Then, the code with the same style, but with monospace, since code is often a library/OS error code. Something like:

Unknown property: 'foo1'

Source: CSS Lint Code: unknownProperties

cc @sandy081 @ramya-rao-a @misolori

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 2
Comments: 36 (33 by maintainers)

Commits related to this issue

#62370 Render source and code less prominent — committed to microsoft/vscode by sandy081 6 years ago
#62370 Improve hover UI — committed to microsoft/vscode by sandy081 6 years ago

Most upvoted comments

I vote for Option 3. Imho a user is not interested in the source and of course not the code. I would always render source and code in the problems panel such that users who are interested in this can go to the view that provides more details. Similar analogy is debug hover, gives you minimalistic information, if you want more please open the debug viewlet.

If we decide to go with option 2 I suggest to right align it so it is less noticable and less space between it and the actual error.

isidorn on Nov 20, 2018

Another idea from (@glen-84) is to have everything in single line and left aligned. Some realtime examples:

Edit: Credits to @glen-84 😃

sandy081 on Nov 23, 2018

Another suggestion from @egamma is to inline the source and code with the message without labels

sandy081 on Nov 28, 2018

I think first we have to decide whether the metadata should be shown at all, or whether it should be configurable to be hidden, etc. Then, if it’s shown, how it should be displayed.

I think it should be shown because if I have multiple extensions contributing diagnostics, I want to know where a message is coming from. The error code is also useful, e.g. if you want to know which rule in a tslint.json is associated with an error message. I prefer option 1.

roblourens on Nov 20, 2018

source and code displayed together in the left, the most prominent & easily-scannable place

While that is true, isn’t the real question what value the code attribute has at all? Usually this is a number and for css its seems to be a close variant of the message. Are people reading/understanding diagnostics like: “Oh error TS33165, I better not assign a boolean to a string” or do they understand the message “Type boolean cannot be assigned to type string” better/faster? For me the code is something I would use when googling a problem I don’t understand by reading the message and therefore the least important piece of information.

jrieken on Nov 5, 2018

Fixes for his have caused regression for https://github.com/rust-lang/rls-vscode. We used backtick-enclosed strings for types and since everything is escaped now to render a custom hover window, the error messages are illegible now, for example:

current output

note: expected type std::option::Option<std::string::String> found type std::option::Option<&std::string::String>

previous output

note: expected type std::option::Option<std::string::String> found type std::option::Option<&std::string::String>

See https://github.com/rust-lang/rls-vscode/issues/479 for more details.

Xanewok on Dec 31, 2018

Another idea is to have everything in single line

I feel so ignored. 😄

glen-84 on Nov 23, 2018

There have been too many iterations done on this and thanks to all for the suggestions. Since it is highly individual opinionated, I would collect more feedback on the current approach before changing and going in circles.

sandy081 on Nov 29, 2018

There’s no consistency. Problems View:

Square bracket for source
Paren for range

Inline View:

Source has no bracket
Paren for code

I also don’t like the code/source appended to the last line’s message. If not on a new line, I hope they can be right-aligned.

octref on Nov 28, 2018

This is how it looks when I align it to right. Not sure right alignment looks good for all. May be it is better to go with left alignment?

sandy081 on Nov 23, 2018

This is what I meant:

Code/Source are displayed but do not command too much attention
code, often the ruleId, should be linkable. That’s https://github.com/Microsoft/vscode/issues/11847 but not https://github.com/Microsoft/vscode/issues/54272.

octref on Nov 21, 2018

Made Hover consistent with Inline and Problems view

This is the best can be done before introducing more UI changes. I would not invest more as the current approach is OKish and do not see complains from users.

sandy081 on Nov 15, 2018