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).
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
Is IntelliJ IDEA able to detect file changes like this? Maybe share from Linux via CIFS?
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 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....
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.
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 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.
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
> 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.
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.)
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.