Closed kdvolder closed 5 years ago
Afterthought on the afterthought: selecting a marker that is so far away that its not even visible on the screen is probably a bad idea. So probably should have some kind of sensible limit on how far is 'too far'. The line above / below still seems like a reasonable interpretation of 'not too far'. Anything more than that I'm not so sure.
Visual Studio also works like that; it is much more quicker than having to position the cursor before hitting CTRL+.
Is there another issue tracking this one? This would probably be my # 1 feature for Code -- just so i don't have to back cursor every time i'm adding something new.
typically I'm adding a new Typescript or C# property and i don't want to initialize the property until i've written the whole line and the type can be inferred.
it seems like it's a hot button topic, so maybe this is something that can be turned on via configuration??
The go to next error
command (F8) seems like it addresses the root idea behind this request: quickly jumping to and fixing errors.
If you would still prefer having quick fixes available for the entire line, I believe that an extension could implement this by doing the following:
CodeActionProvider
CodeActionProvider
, get all code actions for the entire line using the vscode.executeCodeActionProvider
command. Return these (this may require a bit of de-duplication too)If the provider works properly, the lightbulb should show up whenever the cursor is on a line that has quick fixes available. Instead of using a provider, you could alternatively create a new command that tries to get all code actions on a line
The go to next error command (F8) seems like it addresses the root idea behind this request: quickly jumping to and fixing errors.
I respectfully disagree. Please consider re-opening this and implementing it so that invoking quickfix action doesn't require me to move cursor into precise location of the error. Going to the next error doesn't fulfil this need. Especially because your cursor will tend to be at or near the end of the line if you typed some stuff and so you'd actually have to fix the 'previous' error not the next one.
E.g. see what @cmeyertons said:
This would probably be my # 1 feature for Code -- just so i don't have to back cursor every time i'm adding something new.
If you disagree, I've laid out you can implement this as an extension. This issue has had 3 upvotes over two years
For what it's worth, quick fixes in IntelliJ also seem a bit more relaxed in this regard:
However, this is slightly different than what's suggested here - there seem to be a few specific quick fixes (maybe just for non-imported classes?) that trigger this popup if you leave the editor alone for second:
If that popup isn't open, invoking the shortcut doesn't do anything unless the cursor is on the TestCase
token specifically. This seems like something that couldn't be done with extensions right now due to limitations around UI extensibility.
Something like that popup might actually play well with the new "auto fix" command and preferred code actions?
Seriously? An extension for some tiny little thing like this? To be honest I don't care enough to go through the trouble. And it doesn't personally affect me as I mostly still use Eclipse anyway.
Moreover the path you laid out sounds like a terrible and fragile hack and it will probably have funky side effects. Like showing the same quickfixes multiple times depending on where the cursor is placed.
This issue has had 3 upvotes over two years
I think this shows that it's something several people have at least felt strongly enough about it to raise an issue (or find that one already exists). So isn't that something?
Anyhow... I guess its your call. But no... I won't be making a 'micro extension' for this. And I think I don't like the idea of having to install a bunch micro-extensions to fix little ui nitpicks. I'd rather have vscode just works nicely without this.
To be fair, 3 upvotes is indeed negligible when you consider how many upvotes other issues get. Even the last issue on the first page of most upvoted issues has 245 right now (!).
Fair enough. But it also does seem like this 'little nitpick' issue here would take a lot less effort to actually implement... compared to some of issues I see on that first page which seems like huge amounts of work. Anyhow... I've made my point of view clear. If it is just not important enough to bother with little nitpicks like this, then so be it.
This is something I'm used to from Eclipse. When you invoke a quickfix, and your carret/cursor is not currently inside a problem marker, then Eclipse looks inside the whole line for problem markers and uses those to determine the applicable quickfixes.
It would be nice if vscode could do the same. I find it slightly annoying to have to navigate my cursor into the exact position of the quickfix before hitting the
CTRL+.
shortcut. Kind of defeats the purpose of the quick fix. Cursoring around slows things down too much.Together with this that would really help to make the quickfixes a real productivity booster (Just hit
CTRL+.
and then immediatelyENTER
).Afterthought: We could even extend this idea a little further and look for 'markers that are not far away' when there are also no markers on the current line. Not far away could mean the line above / below, or even just find the closest marker in the file, no matter how far away it is.