Error hover semantic information should be rendered separate of error message

[joaomoreno]

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

[octref]

Another problem: changing source back to css is not nice in problems view. Previously I get:

Now I get:

Good things I miss from previous one:

• source and code displayed together in the left, the most prominent & easily-scannable place
• I'm able to see the code even in half screen, whereas if the message is long, I lose the code at the end

[jrieken]

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.

[octref]

@jrieken
I see your point, but there are also cases when, say, a user is enforcing some new linter rules throughout a codebase. He would want to see which errors/warnings are caused by exactly these rules. He might also add pragmas to disable certain rules for some lines, when the rulename is useful.

From an extension author point of view, he doesn't care about passing in semantically correct info. He only knows the messages displayed on hover and problems are ${code} ${message} ${source} ${range}, and he tries to make best use of that format. We see that with HTML all the time, don't we...

[jrieken]

which errors/warnings are caused by exactly these rules.

That sounds a little artificial but if that is the case, then I would probably search for that specific error code using the filter box on the upper right. (actually I wouldn't use the UI at all but I'd use the command line)

[sandy081]

Inline widget renders the source and code similar to Problems view.
Hover renders the source and code as suggested in description

Example 1:

Example 2:

@jrieken @joaomoreno @misolori Feedback is welcome.

[jrieken]

I think having source and code on separate lines gives them way more attention than they should have. And to my eyes it also looks ugly. What again is wrong about the inline rendering and why is it only wrong in the hover?