34 ms·
It's faster than any Bash terminal I've tried so far on WSL. Tried ConEmu and Hyper. ConEmu glitches out for me on tmux. Hyper can be a bit slow, but is most a
by tony 7y ago
It's faster than any Bash terminal I've tried so far on WSL. Tried ConEmu and Hyper.
ConEmu glitches out for me on tmux. Hyper can be a bit slow, but is most accurate for me.
I'm doing tmux + vim with 256 colors. So a lot of stuff has to come together and "just work"
Windows Terminal over the past months fixed glitches. It's update-able via Windows Store.
Oh, and the font "Cascadia Code" is one of my favorites. Very clean. Actually, I'm using it on Linux now in my terminal [1].
The other thing is Windows Terminal works great on a huge monitor, too. No lag when rendering. Feels lite. I compare its snappiness to rxvt-unicode. Faster than iTerm2.
Just my perception, never benchmarked.
And this goes along with WSL 2, which is worth reinstalling Win 10 for if you left because of WSL 1 problems. This stuff is fast. I can throw multiple multiple beefy node projects, python flask/django apps, building C++ projects, importing postgres DB (4gB import with a lot of indexes), all at the same time.
[1] I dual boot still. There is a shortcut on Windows 10 minimizes all windows that I can't disable easily. It loses my workspace positioning and isn't recoverable. I hope this gets changed - it'd be a dream.
- zenexer 7y agoYou can probable disable Win + M with something like AutoHotkey, which you may already even have installed as a dependency. Alternative, if you're talking about Win + D, you can reverse it by pressing Win + D again.
- tony 7y agoHey thank you for bringing that up. I tried AutoHotkey for the firs time yesterday. Am I correct in saying a text file has to be edited to disable the key? What would it look like? I also heard about Win + D, which could be what I'm hitting a % of the time. Correct me if I'm wrong: but positioning any window after minimization (possibly including the bottom show-desktop / taskbar area) will make it so the window settings can't be reverse back? My dream scenario would be something in Windows 10 settings where shortcuts can be remapped (or disabled) one-by-one, without registry/group policies.
- zenexer 7y agoI've never actually used AutoHotkey much; I've always just interfaced with the Windows hotkey API directly. Since it's installed on my computer as a dependency for something else, I gave it a quick look-through to see if I could figure out how to disable Win + M and Win + D. It seems pretty straightforward: 1. Right-click on your desktop (or any other folder) and choose New -> AutoHotkey Script. 2. Name the file something like DisableMinimize.ahk. 3. Right-click the file and choose Edit Script; alternatively, open it in your text editor of choice. 4. Keep the existing text that's in the file, but add the following to the end: #d:: return #m:: return This script will work just like a program. Double-click it to run it, or put it in your Startup folder. You can even right-click -> Compile Script to generate a standalone EXE. > I also heard about Win + D, which could be what I'm hitting a % of the time. Both Win + D and Win + M seem like pretty obscure shortcuts to be hitting by accident. Some touchpads and mice have gestures or buttons that minimize all windows, though; in particular, on lower-quality laptops, I've found that the "minimize-everything-and-interrupt-whatever-I'm-doing" gesture likes to fire randomly. It even used to happen a lot on some older Surface devices. Is it possible that's the issue? > Correct me if I'm wrong: but positioning any window after minimization (possibly including the bottom show-desktop / taskbar area) will make it so the window settings can't be reverse back? You'll lose the memory of which windows were visible, but with both Win + M and Win + D, their positions and sizing should be preserved. If a window doesn't restore to its same position and sizing when you restore it, that's most likely a bug in the individual application.
- binarycrusader 7y agoThe global keys are actually not generally customizable, unfortunately. I would encourage you to file feedback in feedback hub asking for this.
- lukeschlather 7y agoThese are mine: https://github.com/lukeschlather/dotfiles/blob/master/src/autohotkey/ljfs.ahk https://github.com/lukeschlather/dotfiles/blob/master/src/au... I actually rebind #m:WinMaximize A (Win-M Maximize active window.) One notable shortcoming is that you have to run Autohotkey as administrator if you want it to work perfectly. Otherwise if you have an active window with admin privileges the system hotkeys will reassert themselves. (I don't run it as admin, so this is a constant annoyance when I start an admin powershell prompt and try to maximize it.)
- cercatrova 7y agoHyper is slow because it is an Electron app built with web technologies. Try alacritty [0], a terminal written in Rust. It is supposedly the fastest terminal. [0] https://github.com/alacritty/alacritty https://github.com/alacritty/alacritty
- xvilka 7y agoAlacritty is great but has two annoying problems: lack of the ligatures[1] support and lack of multiwindows[2] feature. [1] https://github.com/alacritty/alacritty/issues/50 https://github.com/alacritty/alacritty/issues/50 [2] https://github.com/alacritty/alacritty/issues/607 https://github.com/alacritty/alacritty/issues/607
- shaklee3 7y agoI second that, and it just seemed to be lacking features overall, and that was the direction the author wanted the project to go. It was great, but too many things missing for me.
- th0ma5 7y agoI'd be curious about performance vs gnome-terminal on X on WSL.
- xvilka 7y ago> vim with 256 colors I recommend to check out the 16 million colors; Windows Terminal, tmux, and [neo]vim - all support it out of the box (assuming you use versions recent enough). See more at my infamous "truecolor" list[1]. Or an example[2] of such a condiguration. [1] https://github.com/termstandard/colors/ https://github.com/termstandard/colors/ [2] https://tomlankhorst.nl/iterm-tmux-vim-true-color/ https://tomlankhorst.nl/iterm-tmux-vim-true-color/
- khalilravanna 7y agoWould you recommend WSL 2? I updated it and regretted it immediately due to a bug where accessing the Windows filesystem through the ubtuntu shell is something like 10-100x slower. Running ‘git status’ takes > 10 seconds to return. Do you stick exclusively to the Linux filesystem?
- Gene_Parmesan 7y agoI really enjoy WSL 2. I mostly use it on my ThinkPad; my workplace is mostly .NET + Angular, so I kind of need Windows as my primary OS, but I'm personally more used to dev work via Linux. (There are coworkers who get away with using Macbooks but some of the tooling we use is difficult for them to run.) I dual boot at home, but for work dual book isn't really the tool I need. What I want is to be able to use bash and the *nix tools I know best as an interface to the Windows-based projects I work on. I'm much faster navigating the FS, even the Windows FS, using bash commands than the nightmare that is cmd, and Powershell just feels like too much -- like Java in the shell. So WSL has been exactly what I need. Working on projects within the Windows directories does feel slower, but I haven't noticed anything like 100x slowdowns. NPM installs are essentially the only part of my regular workflow that feels painful. Also it lets me work on my pet roguelike project during slow meetings, but that's our little secret....
- tuananh 7y agoit's still not fixed yet. `npm install` would take forever.
- chrismorgan 7y agoLinux accessing Windows is indeed way slower under WSL 2, and I get the impression from what I’ve heard that this is unlikely to ever be improved much. But working the other way round is a bit faster than it used to be, if I recall correctly, and working purely within ext4 is enormously faster than under WSL 1. Combined with the steady improvements to being able to access the Linux side from Windows (under \\wsl$\machine-name), and being able to mount that to a drive letter (I have my ~/.zprofile run `/mnt/c/WINDOWS/system32/subst.exe A: '\\wsl$\arch' > /dev/null`, which delays subsequent login shell startups by 30–40ms, but that’s not too bad), shifting all your relevant stuff onto the Linux side and still working with Windows tools where desirable is quite feasible. I moved all my files (including a >700MB Git repository) from C: to A: after upgrading to WSL 2. Well worth it. I do most of my work in a terminal (the Linux side) or in gVim (the Windows side).
- svnpenn 7y ago> I'm doing tmux + vim with 256 colors. So a lot of stuff has to come together and "just work" Very true. I eventually gave up on that because some computers I use still have Windows 7, so it was just easier to use gVim, than mess with installing and configuring a terminal (and PTY?) too.
- comment_out 7y agoI've been using kitty running through WSL/VcXsrv. Which has been an overall better experience than any native windows terminal I've used. Had to setup a few scripts to get everything working 'quake' style, but it works.