I've had to take a beat to find the right words as all the frustration in the issue ticket impacted me too which has left a very bad taste in my mouth after being initially curious and open to the new feature.
I think you're doing a disservice to newcomers by creating a new method of autocompletion. And I say that as somebody who has mentored a lot of newcomers in high school, University, and now professionally. Very often, including just yesterday, I'll hear something like "I don't really know how to use [very standard thing], we had [esoteric helper] instead." Yesterday it was for makefiles. Their school just abstracted it away to make it easier for them, so they don't know how to make a simple makefile to compile a few source files together. Or literally any other build system, including cmake. So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Where it might come in handy, and I haven't tested this, is programs that haven't registered their completions. For example, I'm often cross compiling, and it would be nice if it knew that ...-objcopy had the same completion as the host objcopy. But I am not going to take the hit of the bad pathing just for that.
I'll conclude with a lesson in biases: your insiders are biased. You need to recognize that only egregious errors might be statistically significant. Not only are they more power users, they're new feature hunters, and more than that, they want new VSCode features. Also, that's very creepy y'all are looking at my command success rate even though I'm not an insider. And if you look at the issue ticket, you'll see that a lot of the issues wouldn't cause failure. `Git add` on the wrong file isn't a negative return code, and they might just muscle memory press enter before seeing they need to edit. A possibly better metric is how many times did the user run the same command up to the completion point. But please don't collect that data, that's creepy. I'm going to have to look through my settings to try and turn that all off.
> So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Thanks for the insights. Something I've learned here is that the vast majority of users don't change their defaults or seek out features they may find very useful. Discoverability vs simplicity/bloat is a hard problem and that's essentially the issue here.
I made a note on the issue that with the planned changes to make it easier to configure, we should consider not overriding tab by default anymore. That would mean that only down arrow is bound by default which would then put focus into the widget.
> I'm going to have to look through my settings to try and turn that all off.
Full details at https://code.visualstudio.com/docs/configure/telemetry, but setting `"telemetry.telemetryLevel": "off"` will disable usage/crash/error telemetry for the VS Code core. Just keep in mind extensions may or may not respect that.
I agree with the point that making the VS Code terminal behave in a special manner without opt-in is going to be disruptive to newer engineers. Why not make it a shell plugin instead and offer to install/customize the shell the first time someone launches a new shell in VS Code instead? Then it changes it system wide, like oh-my-zsh or something would.
While I agree that new feature adoption is hard, changing tab completion is a bit hardcore. I agree that a different key bind, maybe right arrow key, or shift tab, or something would have been better.
Here's a suggestion: maybe you could not track all of our activity extremely invasively by default, and allow those who would like to provide feedback and tracking to enable it on their own. Crazy thought, I know.
No, it's really not that good a feature and turning it off improves my experience so I don't care if they're the only ones with it. That said, if it's part of the open source, when better. And even if it was, I can't complain that a business made a program has a unique feature to attract users.
I think you're doing a disservice to newcomers by creating a new method of autocompletion. And I say that as somebody who has mentored a lot of newcomers in high school, University, and now professionally. Very often, including just yesterday, I'll hear something like "I don't really know how to use [very standard thing], we had [esoteric helper] instead." Yesterday it was for makefiles. Their school just abstracted it away to make it easier for them, so they don't know how to make a simple makefile to compile a few source files together. Or literally any other build system, including cmake. So, Lord have mercy on my soul if I have a new hire tell me "I don't know how to use the regular terminals. All I can use is VSCode's terminal." I think sometimes things should be hard, but I don't think terminal autocomplete is very hard. Just hit tab a few times and it'll do its thing or -h.
Where it might come in handy, and I haven't tested this, is programs that haven't registered their completions. For example, I'm often cross compiling, and it would be nice if it knew that ...-objcopy had the same completion as the host objcopy. But I am not going to take the hit of the bad pathing just for that.
I'll conclude with a lesson in biases: your insiders are biased. You need to recognize that only egregious errors might be statistically significant. Not only are they more power users, they're new feature hunters, and more than that, they want new VSCode features. Also, that's very creepy y'all are looking at my command success rate even though I'm not an insider. And if you look at the issue ticket, you'll see that a lot of the issues wouldn't cause failure. `Git add` on the wrong file isn't a negative return code, and they might just muscle memory press enter before seeing they need to edit. A possibly better metric is how many times did the user run the same command up to the completion point. But please don't collect that data, that's creepy. I'm going to have to look through my settings to try and turn that all off.