-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Provide a generic code fixer for navigating the URL of a diagnostic #42103
Comments
Tagging folks who have an interest in this space: @mikadumont @mavasani @CyrusNajmabadi |
Any chance we could prioritize this for .NET 5? This is part of the better obsoletion work.
My concern is that the hyperlink in the error list isn't discoverable enough. |
Any way we could get data on that? it seems pretty clear to me. it's blue. it's got an underline. i know my mouse has gone over it many times and seen it light up. So i'm totally biased, but even not being at all part of the design there, it was immediately obvious to me what that was. |
We have implemented said fixer in our platform-compat tool because based on customer interactions it was quite clear that many didn't realize that the guidance was available by clicking on the error code in the error list. Can I quantify that? No. Could we have done a user study? Yes, but implementing the fixer was tremendously cheaper than that... |
The problem is that we may have many items in that list. It's common to have 10 or more fixes offered for a variety of issues that may be on that line. I'm really hesitant to have this item here as it would effectively double the size of those lists. We already have feedback that we even have too many items already, and we spent a ton of timing getting down to even the set we do offer. Adding more seems not great. I think this is the standard discoverability/intrusiveness problem. We can make things more discoverable by putting them more in hte user's face. But once they're discovered, now what does that do the rest of the experience? How does htat impact users who don't necessarily want these? etc. etc. Maybe we should rename the bottom bucket and make it a general catch-all for this sort of thing. i.e. if you want more info you go into this: And you can suppress/config/about/report-issue. |
Could we collapse them into a single menu item with sub items, like
|
@terrajobst @CyrusNajmabadi I can implement this as per Immo's suggestion. I prefer keeping "Help Link/Guidance" menu separate from "Suppress/Configure issues" - they seems separate actions. @mikadumont for her views. |
I agree with Cyrus that the hyperlink is visible enough. |
I'm ok with a new item in the list if it's a single item at the bottom (likely below suppress/configure). But my gut goes with: i would prefer to do nothing. |
I think at this point we clearly need more customer data to move forward on this... |
It's blue, but in its own column, so I think the color doesn't stand out as much as it would e.g. inside a paragraph of text. And it's got an underline only when you hover over it or when it's selected. But most importantly, you can't quickly differentiate between a link that will send you to the actual official documentation from a link that will just google the error for you (and it doesn't even use Google for that). And since the latter is the case for many errors, I suspect many developers become "blind" to those links, after trying them a few times and finding them not useful. So I think it makes sense to have a more obvious way of providing a link that is actually useful. |
Note: this issue is not about providing a different link. The link is actually not controlled by the error list or the editor - it is provided by the diagnostic provider (compiler or analyzer that produced the diagnostic also provides the help link). This issue is about making whatever link that was provided to the IDE more discoverable. We already have separate issues tracking improving the help links for compiler diagnostic and IDE analyzer diagnostics. See #40863 and #41324 |
Design review conclusion: We should add a hyperlinked diagnostic IDE to the Quick Info popup for the messages presented by diagnostics. At the time diagnostics were first added to the error list, we did not have the ability to hyperlink items in Quick Info. That has since changed, so we can leverage the new functionality to serve two purposes:
|
Closing this issue in favor of #43728. This issue is marked as Won't Fix as presented, but the desired end goal should be achieved through the alternative proposal. |
The
DiagnosticDescriptor
has aHelpLinkUri
property which is used by the IDE to render a hyperlink in the error list:However, this is quite subtle and I've seen many people not noticing this. In my own analyzer, I've added a code fixer that offers to browse to the location:
However, my code fixer is specific to my own diagnostics. It might help to provide a built-in code fixer that offers this capability for all diagnostics. Especially because the priority of this fixer should probably be lower than other code fixers but the ability to tweak priorities wasn't exposed last time I checked.
The text was updated successfully, but these errors were encountered: