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.

Sign up for GitHub

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

Jump to bottom

Bulb menu should open immediately after clicking on the info icon in the problems view #98618

Open
bsutton opened this issue May 26, 2020 · 22 comments
Open

Bulb menu should open immediately after clicking on the info icon in the problems view #98618

bsutton opened this issue May 26, 2020 · 22 comments
Assignees
@sandy081
Labels
error-list Problems view feature-request Request for new features or functionality
Milestone
Backlog Candidates

Comments

@bsutton
Copy link

bsutton commented May 26, 2020 •
edited

When working through large no.s of lints in the 'problems' pane I use the quick fix bulb to rapidly fix many trivial errors.

This process is slowed down by how the 'quick fix bulb' appears and then disappears.
The process I used to apply these fixes is:
Open the 'problems pane'.
click on the line
wait for the bulb to appear
click the bulb
select the action.

The problem is that the bulb will appear and then disappear before re-appearing.
It also changes color from white to yellow (which I'm sure indicates something but I've not worked it out as yet).
My preferred operation would be:
click line
click 'info' icon.
The code then looks for quick fixes and displays the menu.

This would eliminate the slight delay in having to wait for the bulb to appear.

May-26-2020 14-38-21
@bsutton bsutton mentioned this issue May 26, 2020
Closed
@sandy081
Copy link
Member

My preferred operation would be:
click line
click 'info' icon.
The code then looks for quick fixes and displays the menu.

I think this works. Did you try clicking on line and wait until lightbulb is available?

@sandy081 sandy081 added the info-needed Issue requires more information from poster label May 27, 2020
@bsutton
Copy link
Author

bsutton commented May 27, 2020 via email

@sandy081
Copy link
Member

sandy081 commented Jun 2, 2020

I do not think delaying the context menu on click is not a good user interaction model. Also clicking on icon to show the quick fixes might be less discoverable. We have a command that you can run to show quick fixes for the selected item in problems view.

image

@bsutton
Copy link
Author

bsutton commented Jun 2, 2020 via email

@bsutton
Copy link
Author

bsutton commented Jun 2, 2020 via email

@DanTup
Copy link
Contributor

DanTup commented Jun 2, 2020

I think an issue here might be that VS Code doesn't know a problem has quick-fixes unless it sends an async request? So you click on the problem, then there's an async request, then VS Code knows there are fixes and shows a lightbulb, which you need to click again?

If so, would a reasonable fix be for an extension to be able to set a flag on a Diagnostic that there are fixes and VS code can show the lightbulb in the problems view in advance? (there would still be a delay in it appearing when you click it, but it's better to click+wait for menu than click+wait for bulb+click+wait for menu).

In Dart, the server already computes this info. We have a hasFix boolean on all errors, but it's not mappable to anything in VS Code.

@sandy081
Copy link
Member

sandy081 commented Jun 2, 2020

Rather that if I click the info icon it immediately displays the context menu.

Yes we do not know upfront if we have quick fixes upfront and needs to ask extension to provide them. Hence this delay is unavoidable.

I do not want to drag this request into a separate discussion asking for API change. If API change is needed for this, I do not think it is worth considering.

@DanTup
Copy link
Contributor

DanTup commented Jun 2, 2020 •
edited

It might be possible without an API change, eg. by using a DiagnosticTag? I think it would be a fairly nice improvement if VS code knew which problems had quick-fixes from the problems view. Imagine something like enabling a new lint which generates a lot of issues - it would be much nicer to work through them if the bulb was visible/clickable in the list.

@sandy081
Copy link
Member

sandy081 commented Jun 2, 2020

cc @mjbvz if you want to consider this request as you own code actions and from problems perspective I would want to align with the editor code actions.

@bsutton
Copy link
Author

bsutton commented Jun 2, 2020 via email

@bsutton
Copy link
Author

bsutton commented Jun 2, 2020

cc @mjbvz if you want to consider this request as you own code actions and from problems perspective I would want to align with the editor code actions.

I don't understand this statement?

@sandy081
Copy link
Member

sandy081 commented Jun 3, 2020

I do not think this is a good user interaction to show context menu after some delay.

@bsutton
Copy link
Author

bsutton commented Jun 3, 2020 via email

@sandy081
Copy link
Member

sandy081 commented Jun 3, 2020

The delay should be fairly minor.

Depends and we cannot rely on that.

Well, I see the request but I do not think it meet the priorities. So I have to tag this as out of scope and we would revisit this when there is a demand.

@sandy081 sandy081 added *out-of-scope Posted issue is not in scope of VS Code error-list Problems view feature-request Request for new features or functionality and removed info-needed Issue requires more information from poster labels Jun 3, 2020
@DanTup
Copy link
Contributor

DanTup commented Jun 3, 2020

@sandy081 any reason why this couldn't be done using a DiagnosticTag or something as suggested above? It removes any delay between clicking/menu opening, and would be a nice usability improvement showing which problems have quickfixes in the problem list without having to click (the current behaviour already feels kinda awkward).

@sandy081
Copy link
Member

sandy081 commented Jun 3, 2020

any reason why this couldn't be done using a DiagnosticTag or something as suggested above?

Can be done but not in priorities as mentioned above.

@bsutton
Copy link
Author

bsutton commented Jun 3, 2020

I can't say that I'm happy with the concept of closing issues out.

Even if you aren't going to do this now, having an open ticket lets other users find and vote on this ticket.

@bsutton
Copy link
Author

bsutton commented Jun 4, 2020

I also disagree with the priority position on this one.
Quick fixes are one of the most common elements that people interact with with in the UI.
Whilst it is a minor announce it is a high use work flow and as such I would suggest that it needs greater priority.
It falls in to the category which is often referred to as a paper cut. Its small and hurts a little bit, but when you are covered in them its a real pain.

@sandy081 sandy081 removed the *out-of-scope Posted issue is not in scope of VS Code label Jun 4, 2020
@sandy081 sandy081 added this to the Backlog Candidates milestone Jun 4, 2020
@sandy081
Copy link
Member

sandy081 commented Jun 4, 2020

Even if you aren't going to do this now, having an open ticket lets other users find and vote on this ticket.

Sorry for closing this. Reopened it and moved to backlog candidates.

@bsutton
Copy link
Author

bsutton commented Jun 4, 2020

It's still showing up as closed.

@sandy081 sandy081 reopened this Jun 4, 2020
@DanTup
Copy link
Contributor

DanTup commented Apr 7, 2021

A similar request came up at Dart-Code/Dart-Code#3254. The request was to have a single-click icon that would apply the fix. Fixes can already by marked as "preferred" fixes, so if they're populated, it would be nice if you could just work through the problems list clicking the fix buttons without even needing to open the menu (and perform two clicks).

Like this issue, I think it would require fetching the quick-fixes prior to the user clicking on the problem - just since the problems view only generally shows a small number of problems, maybe it would be possible to fetch a few eagerly?

If you had a large number of errors from enabling a new lint (or upgrading an SDK that generates lots of deprecation warnings with quick-fixes), you could get through them a lot faster that way.

@DanTup DanTup mentioned this issue Apr 7, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sandy081 sandy081

Labels
error-list Problems view feature-request Request for new features or functionality
Projects
None yet
Milestone
Backlog Candidates
Development

No branches or pull requests
5 participants
@bsutton @DanTup @jrieken @sandy081 and others