Repository navigation
Too many tab stops in method signature completions聽#46588
Description
Bug Report
馃攷 Search Terms
- method signature completions
- completion
- suggestions
馃晽 Version & Regression Information
4.5.0-dev.20211029
Problem
After playing around with method signature completions a bit for a VS Code extension, I found the tab stops to be more of a hinderance than helpful
I suggest that we remove the tab stops and only move the cursor into the correct final location inside the method:
completedMethod(param: type) {
$0
}That is the behavior I almost always want
Activity
andrewbranch commentedon Oct 29, 2021
I suggested this at first, but then I realized the behavior is pretty good if we just make sure the first tab stop is in the method body. Then a user can tab into the parameters if needed, or can hit the escape key to remove those tab stops. There鈥檚 an item open in #46568 to make the method body both the first and the last tab stop as an additional improvement (
$1$0in the body). I agree I don't often want to edit the parameter names/types, but as long as they don't stop me from getting to the method body, they don't bother me. From our conversation in the editor sync, I think Daniel Rosenwasser (@DanielRosenwasser) liked having the tab stops, so this seemed like a good compromise to me.andrewbranch commentedon Oct 29, 2021
Update: open at #46593
mjbvz commentedon Oct 29, 2021
Yes I remember we discussed this. After trying it myself though, I really don't like how all the tab stops get highlighted along with the code I type in the method body:
I end up pressing
escright away to cancel out of the snippet right awaygabritto commentedon Oct 29, 2021
The highlights were pretty much my only concern with placing the tab stops
andrewbranch commentedon Oct 29, 2021
Same, but I find I get easily distracted by completions popping up when I'm trying to think, so I already have a habit of pressing
escquite a lot to get rid of visual noise, so this one doesn't bother me.I really don't have a strong opinion here, but I think the most valuable place to have placeholders is on the
anytype annotations on an overload implementation signature, because a user is pretty likely to want to change that. On the other hand, the fact that we produceanythere is already something we'd like to improve in the future. Daniel Rosenwasser (@DanielRosenwasser)'s biggest concern with decisions around the placeholders was not disrupting users' muscle memory for getting to where they're trying to end up, but I tend to think that concern is mitigated by the fact that we're landing the cursor in the method body right away now. But this is perhaps something we don't want to flip flop on and confuse users, so it would be nice if we can reach a consensus we feel good about before 4.5 stable.DanielRosenwasser commentedon Oct 29, 2021
That was also Andrew Casey (@amcasey)'s concern too, so I'd like his opinion.
Here's a compromise - tab stops on parameters where all of the parameters were
any, no tab stops otherwise.DanielRosenwasser commentedon Oct 29, 2021
Thinking about it some more, I actually don't mind getting a tab-stop into an
anyin TypeScript. But I also specifically took a job to add types on top of JS.gabritto commentedon Oct 29, 2021
I think we should get opinions from people that do use snippets, I feel totally unequipped to give an opinion on this because I pretty much just never use snippets and I click things heh 馃槄
amcasey commentedon Oct 29, 2021
My primary concerns are (1) real-world usefulness and (2) consistency. For me, Matt Bierner (@mjbvz)'s actual user experience trumps most other considerations (barring an opposite opinion from some other user). I'm fine with never having tab-stops; I'd be reluctant to have tab-stops conditionally unless it's really clear when you should expect them.
mjbvz commentedon Oct 30, 2021
Thank you for the quick turn around! I think the tab stops sounded good on paper but weren鈥檛 great with vs code鈥檚 current handing of snippets