My shinning development setup - from terminal emulators to code editors

I started to boost my terminal setup this month(again!). I’ve used my new setup for a week, and I became more productive MENTALLY!

No matter what you think, I will show off my setup here. 🤣

Terminal Emulator: WezTerm

I use WezTerm as my terminal emulator.

I’ve tried a lot of terminal emulators before, like:

• iTerm2(2014 - 2019): It was used throughout my junior years since I bought first my Macbook Air.
• Kitty(2019 - 2021): When everything becomes so slow on my old laptop, I started to try something new. This rust-based gem is what I found work best at that time. While iTerm is not getting new rendering engine yet.
• Hyper (2015-2015): xterm.js is fast in VSCode, but I don’t want another electron app aka memory monster to eat my memory. That Pikachu theme is the only reason I use Hyper for.
• Other electron-based terminals: Tried but forgotten. They all lag in my old hardware.
• Alacritty: I’m not geeky enough to use tiling window manager. I need tabs and builtin layout spliting.
• Warp: TOO fancy to use. The AI completion is great, but for now I’m using copilot-cli and BingAI to help me with that.

Overall, Wezterm covers all my needs for a terminal emulator, like tabs/splitting panels. You can also write configuration in lua language, which means you can refactor your configs whatever you want.

Wezterm recently added bunch of menu items(from NOTHING to SOME), which make it works better with Raycast’s Menu Items command. You won’t need to remember or customize your keyboard shortcuts anymore.

I’ve used the nightly version of WezTerm in the past two years. The update only crash for one time, and was fixed in one day or two. The release note of WezTerm is always dedicated and clear, making me willing to enable new features to try.

So here’s my choice, WezTerm.

Shell: Fish shell

I use fish shell as my primary shell, and fisher as its plugin manager.

What I mean by the word primary, is that I don’t chsh(change shell) to fish. I keep the macOS default shell, zsh. Since fish shell was not POSIX compatible enough, sometimes when script doesn’t run well, I need to run it with zsh or bash temporarily, but that’s acceptable for me.

Fish shell already is a nice looking and usable shell out of the box. If you want more, it’s time for the plugin manager. Oh-my-fish(omf) and fisher are the main players in the ecosystem. I don’t remember why I chose fisher over omf, maybe just because a random guy’s article. But looking at the latest release date of these two, omf is 2020 and fisher is August 2022. I think it’s the reason for now. Or somebody can tell me there’s a new alternative out there?

Fish shell also changed a lot these years, some folks even started to rewrite it in Rust.

Prompt customization: oh-my-posh

Let’s move on to the prompt customization. People made shell specific customization, like powerline, powerlevel10k, and all the great zsh themes. People even made powerline fonts(and Nerd fonts) to make it fancier for displaying rich git or package manager states. But sometimes shell specific customization get slow easily, thanks to the limitation of expressiveness of those crappy scripting languages(ignites the fires 🤘).

So that’s one reason why shell agnostic and static languages built prompt customizations become quite popular these days. Tools like starship, oh-my-posh came into places. And of course, they are built for speed. starship is written Rust, and oh-my-posh is written in Go.

These two are really great replacements for your old unmaintained shell themes. No matter you use bash/zsh/fish/powershell, you can apply your awesome theme.

And the reason why I choose oh-my-posh over starship? The config file format in starship is TOML, whereas oh-my-posh is in JSON. At the time I discovered oh-my-posh new rewrite(Yeah there’s a story, you can find it on the GitHub repo), oh-my-posh comes with JSON schema. With the autocompletions and type checking support editor like VSCode, you can easily modify and develop your own oh-my-posh theme without reading doc and fixing errors back and forth. Developer experience(DX) REALLY matters for such developer tools.

Code editor: NeoVim

I’ve used VSCode as my primary editor since 2016. One year after it came out publicly.

Why 2016? After VSCode got 1.0, the team started working on some basic editor features, like tabs, extensions, and integrated terminal. You can find these updates under vsocde-docs/release-notes directory. I still remember during those months, I was excited enough to refresh the iteration plan doc every couple of days, go through newly created or merged pull requests to see what new features is added.

The amount of new features and bug fixes VSCode introduced every month is so unbelievable. And it always keep improving and evolving, from user interface to performance.

And since the extension marketplace is introduced, thanks to the vibrant JavaScript ecosystem and community, every new extension excites me. I even wrote a crawler to see when will the amount of VSCode extensions surpass Atom and SublimeText.

If VSCode is so great, why would me switch to NeoVim? The biggest value VSCode it brings is the abstraction of an IDE, Language Server Protocol(LSP). While sometimes not being that performant, it surely help editor developers get feature rich quicker.

I use Vim-inspired keybindings in every editor I’ve used. In VSCode, I even use the NeoVim extension to have a better performance Vim experience.

NeoVim got official LSP support recently, and the Lua-based configuration looks great. So I think now is the time to go back to the origin. (Okay don’t argue that NeoVim is not the origin but Vim is, why not stay using vi or ed? 😑)

You can find my NeoVim config on my GitHub repo. I use AstroNvim as base config. My friend recommended it to me just two weeks ago. It hugely cut off my setup time, though I still spent a lot of time reading various documentations. Oh BTW, GitHub Copilot also works on NeoVim!

I’ll keep using NeoVim until I get the access of GitHub Copilot X on VSCode. 😂

Bonus: JavaScript toolchain management

Let’s finish this in one paragraph.

TL;DR: I use volta and fnm at the same time. volta is for global Node.js toolchains, like pnpm, yarn, pm2 and other cool npm distributed CLIs. fnm is for project-specific Node.js version management, since it can be a in-place replacement for nvm, and it’s faster.