Hey so I'm a developer on the Windows Console/Terminal team - I can answer any questions people might have :)
All GPU based terminal emulators I tried so far make latency worse. You have to do away with double buffering and V-Sync for small changes (or on key-press-events) to get in the sub 1ms range.
This is an absolutely epic post you've linked, I'll make sure to share with the team.
Disabling quick edit helps, but now I can’t select text at all.
Is this behavior changed in the new terminal?
The new Terminal fortunately gives us much more flexibility for customizing it's behavior with user settings, so we'll be able to support either pausing output or not, depending on what the user prefers.
I'm not sure which side is misrepresented, but it sounds mad from the outside!
> The first preview of the new Windows Terminal is now available.
But does not provide a link. Would you be able to provide one? Or is it part of the Insider preview?
Also, I assume this uses ConPTY, which implies better compatibility with TTY/VT?
We don't have a link to share quite yet. The first preview builds that will be available from the store will be coming soon(tm). The "now available" part seems to be referencing a part of Jha's keynote that I don't want to spoil quite yet :)
Yes it's using ConPTY as a backend, which means all Windows commandline apps will work in it out of the box.
Lol I should have updated that issue - in the most recent Windows release, we added a feature to conhost to actually disable the overscroll (under Properties... Terminal... Disable Scroll-Forward). See [this blog post](https://devblogs.microsoft.com/commandline/new-experimental-...)
Question - I see in the Techcrunch article that tabs will be supported. Do you know if split windows (like iTerm2!) will be supported?
A. I'm not sure if I'm doing it right. B. If I am doing it right, where does the compiled binary (or is it an installer?) get put?
Thank you for your work!!
I'd say the vast majority of the codebase is pure C++, without the C++/winrt magic.
The renderer we're using is DX-based, which provides a pretty substantial perf improvement over the old GDI-based one conhost uses.
(I only say this because I see a lot of undeserved bad blood around C++/CX and UWP. The legit criticisms of UWP is that if you go to the Microsoft Store and search for any app, you'll get seven apps and ebooks trying to mislead me into buying them and probably not actually the one you want - but that's not a technical issue at all.)
As far as bidi text, the underlying console implementation isn't quite there yet, though it it high up on our radar of things to work on.
Does this new terminal support Unix/Linux style shortcuts? Another unrelated thing I’d love to see for WSL is windows-XDG integration, so for example the XDG Browser variable would be set to open the default Windows web browser.
The best part of working on the Terminal is that we can feel free to add new features to it's codebase without breaking backwards compatibility, which why such a feature was never added to conhost in the first place
- sudo for editing protected files (using nano to edit the hosts file in system32 for example)
- Good copy/paste functionality, something robust, maybe like linux with the middle click or normal shortcuts is ok
- Non blocking stdio when scrolling out of focus (not sure if this still exists)
- Split screens like iterm2 or terminator. Adjustable, with different colors for each, with the ability to save profiles so they get restored every time the terminal starts up.
- Smart notifications. If a compile/transpile finishes, our scripts could emit an event to the terminal similar to the bell, to produce a gentle notification. Right now the bell results into the taskbar item becoming orange, but it doesn't go away on its own.
- In Cmder when I have multiple split screens, they register as multiple windows, when I hover over the application on the task bar. Split screens should register as one window in my opinion.
- Right clicking on the application's taskbar icon should give an option to launch a new terminal or a new terminal from a saved profile.
Thank you for your efforts!
Not directly related to the terminal, but any updates on the file system slowness issues?
I believe they have a big announcement later today that I don't want to spoil quite yet :)
Exciting! :)
Will cmd, PowerShell and WSL all use the new terminal by default?
Powershell, cmd.exe, WSL, they're all unaffected by this change. They all run the same in the new terminal as they did in the old one, thanks to the powerful magic of [ConPty](https://devblogs.microsoft.com/commandline/windows-command-l...)
Also, how stable/unstable will the preview be?
I don't think we have our release strategy exactly set in stone yet, but I believe the plan is to have a weekly/nightly app users can download that'll be less stable, and an official app, that'll be much more stable.
Curiously, Windows is more secure than linux because it _doesn't_ have a sudo.
In Windows, any application can set messages to another window at the same integrity level with SendMessage/PostMessage.
If you had a `sudo` on windows, you could have a medium-IL terminal window which is talking to a high-IL process (running with the hypothetical sudo), and any other medium-il process could drive the console, effectively creating an escalation of privilege attack vector.
Its very much by design.
Is this open source? Is there a way for me to help contribute back? Thanks for the hard work!
https://github.com/Microsoft/Terminal
Split panes is one of the things I want to see get done next personally!
As far as package managers are concerned, I've had lots of success with Chocolatey. If developers are willing to port their commandline applications to Windows, then I'm sure they'd be welcome additions to Chocolatey
[0] https://blogs.windows.com/buildingapps/2019/05/06/developing...
By using the GPU for text rendering, we can process more text faster on the CPU, without the rendering of the text getting in the way.
If we're not already doing subpixel AA, then I think it's certainly something we could look into. I'm not really our DX guy, but it DX supports it, I think we could use it.
1. Is this based on Terminus or some previous OSS project?
2. Is this using xterm.js for the terminal emulation?
2. I spent a LOT of time looking at using xterm.js, and eventually decided against it. The main factor was that although it would provide us a nearly complete VT implementation, it was critically tied to the JS ecosystem, and no matter how much time we spent engineering it, we'd still be coupled to having a webview render text. So we instead decided to write it in C++, which meant that we'd initially have less VT compatibility, but our perf would be better in the long run.