Hi from the VS Code team - I recently went into detail about why we did this in https://github.com/microsoft/vscode/issues/282268#issuecomme.... We believe it'll be beneficial overall and go a long way in lowering the bar to make the terminal less intimidating for newcomers. Conflicts with muscle memory was always a big concern which is why we made extra effort to be able to turn it off, the comment below that one outlines some steps we're making to make it more easily configurable inline.
On the roll out side, this is what we observed:
- It was enabled in Insiders for several months, generally only very positive reactions
- It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100%
- After hitting 100% of users we did see some backlash like this comment
- Of course telemetry doesn't show the whole story, but we try to determine both whether the completion was modified and whether the command was successful after using it and both numbers stayed relatively stable since shipping in Insiders at what we consider pretty good numbers (both accept without editing and command success rate is ~80%).
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.
Nobody at Microsoft has ever used this with WSL, and doing a "cd /", and getting autocomplete for "$RecycleBin" and other windows paths? It completely breaks bash autocomplete, and every single suggestion is completely wrong, in every single command i type.
I, and probably most uses, just hoped this going away as soon as possible again.
One of the things we should definitely action is hiding it in more places where it doesn't work well, that's one of the key pieces of feedback we got and is tracked in https://github.com/microsoft/vscode/issues/282578
The insane behavior in the post is not that you get fancy completions, but that the completion does not match the preview. If the computer starts doing A when you asked it B, it is equivalent to a trash can.
The feedback you receive is from a selection of people who’re trying new features, not people with existing patterns that is broken one of a sudden with an update while they’re trying to get stuff done.
I appreciate the effort you put into developing this. However, I'm honestly shocked you received only positive reactions. I booted up my system today and found that it made terminal nearly unusable. The old tab-complete behavior gets you to the branch point you want fast, minimizing typing time. The new behavior quickly shoots past the relevant branch point, meaning I spend considerable effort going back to edit commands.
Also, speaking as an educator, I think there might be a misunderstanding about what makes things intimidating for new users. Systems that make specific decisions without being able to easily control them makes things more intimidating, not less. And if I'm reading your post correctly, it sounds like you are trying to introduce a feature on newcomers, but your internal testing was done on insiders and stable users -- a different population.
Frankly, at this point I may strongly discourage all of my students from using VSCode.
This a byproduct of metric-driven development. The result is a creepy manifestation of force-fed features backed by "telemetry" (action and result logging, and sometimes keystroke or string logging), but I don't place any blame on this developer; this is the way it has been at that company for a while and that horse has long since left the barn.
Certainly this may not even be intended gesture, but it will result in unknowable metric of users being insulted by the half-baked forced nature of these product changes.
First of all, I appreciate and respect you coming here and defending your choices. That said:
I think that bar-lowering is not really something that Terminal users want, if they wanted simplicity they wouldn't be in a terminal in the first place, at least that holds true for a large portion of the Terminal users.
Sure there are always the new users, who may benefit from some hand-holding. But why don't you ask first if people want their hand held? Normal terminal users are looking for a way to control their computer in a more direct fashion, which makes them faster. They seek a more predictable interface, by moving closer to the true language of the computer itself, by learning a bit about how it works inside and subsequently adapting oneself to it.
You have chosen to alienate a large group of highly knowledgeable users for a user group that may be mostly a myth.
What would make more sense is to provide a switch for "noob mode", while leaving the core experience alone. I for one already hate the difference between my normal terminal when it comes to ctrl-c/ctrl-v and pasting with select/middle-click. This current change feels like a slap in my face.
There's plenty that can be said about Google, but investing in education and testing around web performance was one of their stand out achievements imo.
I work on VS Code. We have a feature for this exact problem that enforces a minimum contrast ratio of 4.5:1 via shifting the luminance of the foreground text by default https://code.visualstudio.com/docs/terminal/appearance#_mini... . This feature's in xterm.js so any terminal based on xterm.js can leverage this.
We actually got a bit of push back when this was released but I haven't heard anything for quite a while now that some time has passed and we have a FAQ for colors not being "correct".
Smooth scrolling in VS Code is primarily about animating scroll events such that scrolling with a mouse wheel doesn't just scroll an increment immediately but over a fixed time, updating at a high refresh rate. This is supported in both the editor and the terminal.
The other part of smooth scroll is being able to render lines offset on the y-axis which is supported by Monaco (the editor part), but not xterm.js (the terminal part). I can't actually seem to find the issue for this, but I've been wanting to implement it for a while. It's quite simple to offset the text, the slightly harder part is to render an additional row so you can see a partially rendered line on the top/bottom.
> Smooth scrolling in VS Code is primarily about animating scroll events such that scrolling with a mouse wheel doesn't just scroll an increment immediately but over a fixed time, updating at a high refresh rate. This is supported in both the editor and the terminal.
Should I submit a feature request to add smoothness to the scrolling that happens when the cursor moves off-screen (e.g. by using the cursor-down key)?
I'm on the VS Code team and maintain xterm.js which is what Hyper's frontend is based on. There are actually multiple developments happening in this area.
First, there's a contribution from the author of DomTerm which adds grapheme cluster support to xterm.js, which will correctly merge and size things like emoji that are called out in the post. This is currently based on Unicode 15. See https://github.com/xtermjs/xterm.js/pull/4519
Second, while Windows Terminal does seem to work with emoji sometimes, it doesn't all the time. I'm not 100% sure, but I think it may only work on Windows ptys, not in WSL for example. Last time I spoke with the team they said they're working on a rewrite which could lead to proper emoji support.
I'm the author of DomTerm and the above-mentioned xterm.js PR. Both use the full UnicodeGrapheme Cluster Boundaries algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundarie...). However, I haven't seen any specifications for how wide the resulting clusters should be in a mono-space context. So unless we enhance terminals to handle variable-width fonts (which I've been thinking about), we need to took at other terminals and make judgement calls. Generally, the width of a cluster is the width of the widest codepoint. Also, I decided that a "normal" character followed by emoji-presentation makes it 2 columns wide.
In your linked-to article, you suggest 2-em dash and 3-em dash should be 3 and 4 columns respectively. That might be reasonable, but it is explicitly contrary to the EastAsianWidths specification. You also suggest that Pictographics fullowed by text-presentation should have width 1. That seems reasonable, though I don't implement that.
To my knowledge, there is no specification for monospace width. Applying the East Asian Width attribute as a proxy does not work reliably. So in my opinion, it is all a matter of agreeing on what's reasonable while keeping it simple. I.e. if allocating text-presentation Pictographics to a width of 1 is reasonable, that's what renderers should do. It's what users would expect.
For many games, idle games are a special case though, I don't think anyone who plays an idle game would want the logic loop to pause. They typically take a long time to play so minimizing and checking back every now and then is a very common thing.
VS Code team member here. The diagram in the article is a little wrong, but the basics of it are:
- The "main process" which manages the windows (renderer processes)
- The renderer process" contains the UI thread for each window, the renderer process can have its own worker threads
- The extension host loads extensions in proc, extensions are free to create their own threads/processes. The separate process for extensions protects extensions from freezing the renderer
- Various other processes that live off either the main process or the "shared process", such as the pty host for terminals which enables the terminal reconnection feature when reloading a window (also file watcher, search process)
We've been shuffling where processes are launched from recently but the actual processes and their purpose probably won't change. You can view a process tree via Help > Open Process Explorer to help understand this better.
Off topic: Is there a document/blog/article somewhere about the plugin architecture of VS Code? I'm less interested in developing a plugin (which google results usually yield) and more interested in, say, how VS Code determines the order in which plugins are called.
You could look up activation events on the website, I don't think we guarantee anything relating to order other than that. Generally the order in which they're activated shouldn't matter in practice.
On the roll out side, this is what we observed:
- It was enabled in Insiders for several months, generally only very positive reactions - It was surprising to me that we shipped this to 25% of our stable users and basically no one complained for 2 weeks before we rolled out to 100% - After hitting 100% of users we did see some backlash like this comment - Of course telemetry doesn't show the whole story, but we try to determine both whether the completion was modified and whether the command was successful after using it and both numbers stayed relatively stable since shipping in Insiders at what we consider pretty good numbers (both accept without editing and command success rate is ~80%).
reply