Hacker News Reader

Hyper 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

Alacritty 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

[2] https://github.com/alacritty/alacritty/issues/607

I 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.

Just recently switched from alacrity to kitty for the ligatures, works great and also has a premium on performance

Kitty doesn't seem to be available for Windows though, right?

Would 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?

Linux 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).

+1

I also tried WSL 1 with Ubuntu and was hugely disappointed by the speed. Even a simle agt-get install would take forever.

WSL 2 improved the Linux filesystem speed A LOT. I think it's a sane approach:

* keep all your dev stuff in WSL (The Visual Studio Code "Remote - WSL" plugin is amazing!)

* use Windows for GUI tools only

Interesting. Is it possible to use something like Visual Studio Code (my main editor due to a lot of TypeScript focused work) with the Linux filesystem? I think I tried this and couldn't get it to work but I can't remember and maybe I did it wrong and am just incompetent.

The "Remote - WSL" extension allows you to open a folder inside WSL but keep writing code inside VS Code running as a Windows process. It's available at https://github.com/Microsoft/vscode-remote-release.git

> shifting all your relevant stuff onto the Linux side and still working with Windows tools where desirable is quite feasible.

Is IntelliJ IDEA able to detect file changes like this? Maybe share from Linux via CIFS?

The WSL filesystem is already exposed at \\wsl$\distro-name (that landed in the Windows build from 6 or 12 months ago, so you can try it now on a release channel WSL 1 distro). I doubt that’s enough for file watching (certainly things like file locking aren’t supported), and I don’t believe CIFS would allow that either.

For watching file changes specifically, I imagine that you’d need a helper that could run on the Linux side and do any inotify or similar stuff there. I have no idea what IntelliJ might or might not support along these lines. I get the impression that VS Code is generally the tool with the best support, though again I have no concrete knowledge about file watching in particular.

I 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....

What is annoying about WSL is the hyperv windows features it needs to be enabled cause virtualbox to not work There is an experimental feature in virtualbox that works around that but supposedly caused vb to be slow (didn’t work for me)

Check out multipass as alternative to wsl2 https://multipass.run/

WSL 2 is what finally made WSL usable for me. On WSL 1, build times were significantly slower for large compiles due to file i/o but WSL 2 is basically at parity with native Linux.

it's still not fixed yet. `npm install` would take forever.

> 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/

[2] https://tomlankhorst.nl/iterm-tmux-vim-true-color/

> 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.

I'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.

You 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.

Hey 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.

I'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.

These are mine:

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.)

The global keys are actually not generally customizable, unfortunately. I would encourage you to file feedback in feedback hub asking for this.

I'd be curious about performance vs gnome-terminal on X on WSL.