Skip to content

Error hover semantic information should be rendered separate of error message #62370

Closed
#66171
Closed
Error hover semantic information should be rendered separate of error message#62370
#66171
Assignees
sandy081
Labels
feature-requestRequest for new features or functionalityuxUser experience issuesverification-neededVerification of issue is requestedverifiedVerification succeeded
Milestone
December/January 2019

Description

@joaomoreno
João Moreno (joaomoreno)
opened on Nov 1, 2018

From Pine (@octref) in #62159

This is a regression on the diagnostics display.

1.28:

image

Insiders:

image

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 Sandeep Somavarapu (@sandy081) Ramya Rao (@ramya-rao-a) @misolori

Activity

  1. João Moreno (joaomoreno)
    assigned
    Johannes Rieken (jrieken)
    on Nov 1, 2018
  2. Sandeep Somavarapu (sandy081)
    self-assigned this
    on Nov 1, 2018
  3. Sandeep Somavarapu (sandy081)
    added
    uxUser experience issues
    on Nov 1, 2018
  4. Sandeep Somavarapu (sandy081)
    added this to the November 2018 milestone on Nov 1, 2018

  5. octref commented on Nov 2, 2018

    @octref
    Pine (octref)
    on Nov 2, 2018
    Contributor

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

    image

    Now I get:

    image

    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

  6. jrieken commented on Nov 5, 2018

    @jrieken
    Johannes Rieken (jrieken)
    on Nov 5, 2018
    Contributor

    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.

  7. Johannes Rieken (jrieken)
    added
    feature-requestRequest for new features or functionality
    on Nov 5, 2018

  8. octref commented on Nov 5, 2018

    @octref
    Pine (octref)
    on Nov 5, 2018
    Contributor

    Johannes Rieken (@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...

  9. jrieken commented on Nov 5, 2018

    @jrieken
    Johannes Rieken (jrieken)
    on Nov 5, 2018
    Contributor

    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)

  10. sandy081 commented on Nov 13, 2018

    @sandy081
    Sandeep Somavarapu (sandy081)
    on Nov 13, 2018
    Member

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

    Example 1:

    image

    Example 2:

    image

    Johannes Rieken (@jrieken) João Moreno (@joaomoreno) @misolori Feedback is welcome.

  11. Johannes Rieken (jrieken)
    removed their assignment
    on Nov 13, 2018

  12. jrieken commented on Nov 13, 2018

    @jrieken
    Johannes Rieken (jrieken)
    on Nov 13, 2018
    Contributor

    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?

  13. sandy081 commented on Nov 13, 2018

    @sandy081
    Sandeep Somavarapu (sandy081)
    on Nov 13, 2018
    Member

    Since it is a suggestion from João Moreno (@joaomoreno) I would request him to reply for above comment.

  14. sandy081 commented on Nov 13, 2018

    @sandy081
    Sandeep Somavarapu (sandy081)
    on Nov 13, 2018
    Member

    Pushed changes in inline view - made source and code less prominent just like in problems view.

  15. Sandeep Somavarapu (sandy081)
    added a commit that references this issue on Nov 13, 2018

    #62370 Render source and code less prominent

    c4d753a

  16. 28 remaining items

  17. miguelsolorio commented on Nov 29, 2018

    @miguelsolorio
    Miguel Solorio (miguelsolorio)
    on Nov 29, 2018
    Contributor

    In the UX call yesterday we discussed both of those options and even though we all liked both versions, we all agreed that we liked the cleaner look of last one (the one that's now on insiders).

  18. mattacosta commented on Nov 29, 2018

    @mattacosta
    Matt Acosta (mattacosta)
    on Nov 29, 2018
    Contributor

    Pine (@octref) To be fair, the option to not show any additional information is actually the one with the most likes and it is what Visual Studio does too.

    #62370 (comment)

    vs_tooltip

    roblourens #62370 (comment)

    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.

    Note that the hovers in vscode are clickable. If said information is not shown, what about clicking the hover and having it shift focus to the full diagnostic in the problems view? Personally, I think it would make sense as most people eventually get an idea of where a diagnostic is coming from an no longer need that data.

  19. Sandeep Somavarapu (sandy081)
    added
    verification-foundIssue verification failed
    verification-neededVerification of issue is requested
    and removed
    verification-foundIssue verification failed
    on Dec 3, 2018
  20. roblourens
    added
    verifiedVerification succeeded
    on Dec 5, 2018

  21. Xanewok commented on Dec 31, 2018

    @Xanewok
    Igor Matuszewski (Xanewok)
    on Dec 31, 2018
    Contributor

    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 rust-lang/vscode-rust#479 for more details.

  22. nwolverson commented on Jan 2, 2019

    @nwolverson
    Nicholas Wolverson (nwolverson)
    on Jan 2, 2019

    Suffering the same issue as Igor Matuszewski (@Xanewok) in nwolverson/vscode-ide-purescript#115 - diagnostics are rendering fine in problems and tooltip but replaced by displayed HTML entities in the hover

  23. Sandeep Somavarapu (sandy081)
    modified the milestones: November 2018, December/January 2019 on Jan 7, 2019
  24. Sandeep Somavarapu (sandy081)
    removed
    verifiedVerification succeeded
    on Jan 7, 2019
  25. Sandeep Somavarapu (sandy081)
    reopened this on Jan 7, 2019
  26. Sandeep Somavarapu (sandy081)
    closed this as completedin #66171on Jan 8, 2019
  27. roblourens
    added
    verifiedVerification succeeded
    on Jan 30, 2019
  28. vscodebot
    locked and limited conversation to collaborators on Feb 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

feature-requestRequest for new features or functionalityuxUser experience issuesverification-neededVerification of issue is requestedverifiedVerification succeeded

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions