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.
Const enums specifically are great, since they disappear on compile you can use them to internally document strings/numbers with verbose names/comments without the cost of a const variable that would appear after compilation.
As for the fact that types cannot simply be stripped out, I've found building using plain tsc and have the bundler target tsc's output directory. This separation is needed since most tools don't support TypeScript project references anyway which I find extremely useful for organizing internal modules.
Before that from v1.17 (~October 2017) it was using a 2d canvas context: https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...