I try to use most of the tools (linux) as standard as possible without customisation including shortcut keys. The problem is, once you are in remote sever/dev ops boxes, you can't have fancy tools or fancy shortcuts. It's better to train your mind to standard tools as much as possible.
Just because we don't have access to great tools when working in remote server doesn't mean we shouldn't use them locally.
I use Vim with lots of plugins on my personal projects, I use IntelliJ at work. But if I need to ssh and vi, it's ok, I know how to it efficiently.
With Fleet or VSCode you can easily use your dev environment with your tools, plugins, shortcode to work on remote codebase via SSH.
That only really applies at a small scale. At some point you either stop logging into them, or do it just to run some automation. I can't remember the last time I did something non trivial in a remote terminal now. (Apart from my home server which has everything I want)
When I develop tools/real products for others, I try to come up with the best defaults and provide the best experience out of the box, because most people don't ever touch settings. On the other hand, I think it is important to have almost as many settings as technical possible/feasible and try to make them discoverable, and encourage people to customize -- although maybe not spend too much time on that.
One setting that completely changed how I use vim: relative line number (and the "smart" version). I learned about it recently and realized I had wasted a stupid amount of time in the past decade since I used vim. Should that be the default? Probably not. But people do need to customize the editor to make it the most efficient and productive for themselves. I just wish relative line numbers are marketed more, and there is a way to gradually discover settings that people may want to tweak.
I've "riced" Linux machines, Windows machines, different editors, terminals, file browsers, shells, web browsers, even commandline tools, to fully customize my own work machine.
I used to install cool tools, new non-standard programs and made edits to config files.
Now I basically just install Arch (personal machines) or Debian (servers), and leave almost everything at default. I have a handful of necessary tweaks for i3, mostly keybinds (Meta+O for emoji keyboard, a different runner, etc.) which I can reasonably remember, look up, or copy-paste to new machines. I used to have an intricate kickstart.nvim-based neovim setup, but I don't use it anymore.
I like tools which have configs, but I try not to touch them, so I don't have to care about which machine I'm on too much. I can ssh into any Linux or Unix-adjacent machine and just get work done. Visual Studio Code and Zed/Zeditor are wonderful with good defaults, which I don't need to change.
I adjust the font of all my terminals and editors to Fira Code, but that's pretty much it. The defaults are usually sane, and, if they're not, I look for a different program.
This is why I appreciate ArchLinux so much, too; They keep the default configs for most tools, and (almost) only make sane adjustments if any. I've given up on customizing the hell out of my machine(s). If customizing your own machine(s) is your hobby, go for it, but if you want to be productive, consider getting used to default keybinds, default naming, typing out `ls -l` instead of `ll`, and getting the job done. You can own and fully control your machine without exercising this control just because you can, everywhere.
So true. I've done it in the past just to get bitten in the a* by my intricate configs or more the lack of them months or sometimes even years later.
Working with the standards is the way to go, life is to short to work with VI and intricate configs.
I'm a zsh user with a slightly complicated configuration. Fish or something else more modern with sane defaults could lure me away some day.
I want to like helix. I've been using vim for twenty years. I suppose I have to put in some work to make the switch... no time and limited mental capacity (plus muscle memory).
I have looked at Zellij and decided I like my simple tmux workflow better (it's configured to behave like GNU screen because I have twenty years of muscle memory for that too).
Regarding Lazygit, I actually enjoy using standard git. I am pretty good at branches, rebasing, and other things.
agree with you on all fronts there aside from lazygit; I see it as a different tool that makes it a bit easier to inspect change trees with less typing.
I can do it on straight git-cli; but 100 characters typed vs 5 makes my fingers ache thinking. Same reason I have fugutive/diffview installed in nvim.
I don't mind configuration when the configuration is discoverable through a few menu options. But when you have to crawl through man pages and the options are endless like Vim, it starts to get annoying.
I liked that when I was in my teens because it was cool, but not now. Too boring.
That's why I switched from Vim to VS Code with the Vim plugin. It's sane by default.
I believe these config heavy tools happen because they are very old, and changing the default behavior breaks things and makes people mad. So they just add a new config option to enable some convenience feature, and then another and another... Soon new people come and want to use the tool and they're told they have to add a config file turning on a half century of features that seem obvious (cough font-lock-mode)
In web development and app development, user interfaces change constantly, so why don't they fall prey to this as much? I think one thing is many of the tools we're talking about like shells and command line tools are actually APIs as well. Scripts break if you change the interface. If a web interface changes, maybe a scraping script fails, but otherwise nbd.
This is probably the biggest failing of the model of your shell being both a user interface and a programming language you write long-lived and critical scripts in. As a user of the shell you want syntax highlighting and nice features like paging etc, but as a script writer you want the behavior to never change.
In hindsight, maybe the way to do it is similar to apt-get vs apt get, where the former is for scripts and the latter is intended to be a ui that makes no backwards compatibility guarantees.
Charitably, yes: great defaults are indeed great, and we do need more tools to drop the unergonomic awfulness of the defaults made up decades ago.
But literally, no: it's practically impossible for a very wide variety of tools to have great defaults.
Case in point - that you have zero config in fish and helix is just you, there are also people who have plenty of OMF plugins or use a totally different keybinding scheme, so hundreds of lines of config
It's not just defaults though. E.g. fish comes with actual integrations with e.g. git, whoch requires both some code and some configuration. So IMO it goes much further than that: the best tools are the ones that do actually solve most common issues straight of the box, even if it takes more effort from developers.
Sensible defaults are very much appreciated (and I've also adopted the philosophy of trying to avoid depending on elaborate customised configurations), but zero-config is not a good goal in and of itself. Very frequently I've found a configuration option is the difference between a tool that does and doesn't work at all for me.
Too many times I've become very frustrated when an installation doesn't work the first time or it has some dependencies that you haven't installed (or worse, you have a different version). Then you end up in some deep rabbit hole that you can't dig out from. Now for each tool I make, it must have a quick start with a single command.
Zero config tools are quite excellent. I include quite a few of them in https://github.com/hiAndrewQuinn/shell-bling-ubuntu , although I also include high-config stuff in there at well so people can compare and contrast - you've got `hx` right next to a fully decked-out `nvim`, for example.
Another tool that I can't live without, which requires no configuration at all is fzf, you can easily and (fuzz)yly find files in your system, move into directories, search in your command history, search active processes and kill them and a lot more.
Give it a try
fzf (https://github.com/junegunn/fzf) is really great. Very useful for providing a quick and easy user interface. For example, I use it to fuzzy find inside git branches to have an "improved checkout". I do that since at work branches are usually named "<project>-<issue number>", it's faster to search for the issue number.
I don't mind configuring my tools to work for me. For example I'm a polyglot, inevitably I work with a lot of tools, IDEs, and programs. I've rigged everything so I have a lot of continuity; and context switching isn't a nightmare.
For some I use VSCode, IntelliJ, Micro or others. They all have similar(ish) shortcuts. It means I can transition so much quicker without grinding my teeth.
My point is, I don't mind configuring my tools. What I do mind, is having ease of transfer between environments, so that my configuration comes with me.
I love IntelliJ's config to cloud, it somewhat just works. It allows me to change something on the work laptop that will apply at night on my home machines. VSCode does the same now (it used to require a plugin and github).
Micro and other tools use a ~/.config/subfolder which also works, I use git to pass stuff around various computers, with various degrees of success.
My .zhsrc / .profile is carried around and I have all my 2-3 letters aliases that do complex things, so I don't need to remember everything. This is a powerful way to be very productive very easily. And if you forgot how it works, just read the file. The amount of time where I saw a senior professional waste time re-googling the same thing over, or fumbling around their shell history has boggled my mind. ref. [1]*
If you're a professional, chances are you're going to cart your configs and settings with you for many years to come. So make it as portable as possible.
Even my lazygit is configured. One time, I got a new job, I left it as default... and forced push changes by mistake (because it's not turned off by default and very easy to fat finger it), and that caused a lot of grief. So be careful about acting proud in being 'zero config'.
I'd recommend being efficient, not a purist in search of minimalism. It also shields you from upstream software changing their default on a whim.
For managing config files I use yadm https://yadm.io/, which I learned of on HN.
Among other great features, it lets me tailor settings per OS (Windows, Mac, Linux) and per client. And my settings are all in git, so they’re easy to save and copy around, and they’re all in one place, not dependent on each tool to know how to save their settings on some server.
Well, zero-config generally means the tool is "modern", meaning it's defaults are current with the current tech/prefs of the most. Does not mean anything else. The issue here is that people tend to customize so they do not like their customization breaks because someone else have made new defaults.
Aside the real "no config", no need to read a manual etc was tempted, historically the most successful who tried it was Microsoft and we know how bad it is...
My take is that yes, we need sane defaults, but also full customization possible, a thing essentially absent in modern software.
I would love it more open source tools and projects would subscribe to the "Easy to learn, hard to master" / sane defaults / zero config approach.
I used to love the photo editor DarkTable. I would spit out very close to camera Jpeg by default, but I could deep dive into some pictures if I wanted to. I don't know what changed, but with every update it just got harder to get something I liked from the pictures. I stopped using it.
I already use fish (with temux) and will take a look at zellij.
In some cases, the question is: what are sane defaults?
Take emacs or vim. I know a lot of people use them as code editors, and think of them as code editors, but they are really general purpose text editors. It is going to be next to impossible to create a set of defaults that everyone, or even a majority of people, will agree are sane. (That said, they could be easier to configure.)
I think this is a great point that most people forget. If you build something specifically for editing code you can do something cooler than vim/emacs and I've been working on that specific idea: https://youtu.be/owuuFxDBQh4?si=tqYi-RqvFQa6kI8h
I try to use most of the tools (linux) as standard as possible without customisation including shortcut keys. The problem is, once you are in remote sever/dev ops boxes, you can't have fancy tools or fancy shortcuts. It's better to train your mind to standard tools as much as possible.
Just because we don't have access to great tools when working in remote server doesn't mean we shouldn't use them locally. I use Vim with lots of plugins on my personal projects, I use IntelliJ at work. But if I need to ssh and vi, it's ok, I know how to it efficiently. With Fleet or VSCode you can easily use your dev environment with your tools, plugins, shortcode to work on remote codebase via SSH.
That only really applies at a small scale. At some point you either stop logging into them, or do it just to run some automation. I can't remember the last time I did something non trivial in a remote terminal now. (Apart from my home server which has everything I want)
or bring your tools with you. or use them remotely - for example tramp mode in emacs.
there's no need to walk barefoot your entire life just in case some day your shoes break and you have to hobble to the store.
When I develop tools/real products for others, I try to come up with the best defaults and provide the best experience out of the box, because most people don't ever touch settings. On the other hand, I think it is important to have almost as many settings as technical possible/feasible and try to make them discoverable, and encourage people to customize -- although maybe not spend too much time on that.
One setting that completely changed how I use vim: relative line number (and the "smart" version). I learned about it recently and realized I had wasted a stupid amount of time in the past decade since I used vim. Should that be the default? Probably not. But people do need to customize the editor to make it the most efficient and productive for themselves. I just wish relative line numbers are marketed more, and there is a way to gradually discover settings that people may want to tweak.
I've "riced" Linux machines, Windows machines, different editors, terminals, file browsers, shells, web browsers, even commandline tools, to fully customize my own work machine.
I used to install cool tools, new non-standard programs and made edits to config files.
Now I basically just install Arch (personal machines) or Debian (servers), and leave almost everything at default. I have a handful of necessary tweaks for i3, mostly keybinds (Meta+O for emoji keyboard, a different runner, etc.) which I can reasonably remember, look up, or copy-paste to new machines. I used to have an intricate kickstart.nvim-based neovim setup, but I don't use it anymore.
I like tools which have configs, but I try not to touch them, so I don't have to care about which machine I'm on too much. I can ssh into any Linux or Unix-adjacent machine and just get work done. Visual Studio Code and Zed/Zeditor are wonderful with good defaults, which I don't need to change.
I adjust the font of all my terminals and editors to Fira Code, but that's pretty much it. The defaults are usually sane, and, if they're not, I look for a different program.
This is why I appreciate ArchLinux so much, too; They keep the default configs for most tools, and (almost) only make sane adjustments if any. I've given up on customizing the hell out of my machine(s). If customizing your own machine(s) is your hobby, go for it, but if you want to be productive, consider getting used to default keybinds, default naming, typing out `ls -l` instead of `ll`, and getting the job done. You can own and fully control your machine without exercising this control just because you can, everywhere.
So true. I've done it in the past just to get bitten in the a* by my intricate configs or more the lack of them months or sometimes even years later. Working with the standards is the way to go, life is to short to work with VI and intricate configs.
I feel called out.
I'm a zsh user with a slightly complicated configuration. Fish or something else more modern with sane defaults could lure me away some day.
I want to like helix. I've been using vim for twenty years. I suppose I have to put in some work to make the switch... no time and limited mental capacity (plus muscle memory).
I have looked at Zellij and decided I like my simple tmux workflow better (it's configured to behave like GNU screen because I have twenty years of muscle memory for that too).
Regarding Lazygit, I actually enjoy using standard git. I am pretty good at branches, rebasing, and other things.
agree with you on all fronts there aside from lazygit; I see it as a different tool that makes it a bit easier to inspect change trees with less typing.
I can do it on straight git-cli; but 100 characters typed vs 5 makes my fingers ache thinking. Same reason I have fugutive/diffview installed in nvim.
I don't mind configuration when the configuration is discoverable through a few menu options. But when you have to crawl through man pages and the options are endless like Vim, it starts to get annoying.
I liked that when I was in my teens because it was cool, but not now. Too boring.
That's why I switched from Vim to VS Code with the Vim plugin. It's sane by default.
Article links to Julia Evans’ blog post on fish as well, which is a good read. https://jvns.ca/blog/2024/09/12/reasons-i--still--love-fish/
I believe these config heavy tools happen because they are very old, and changing the default behavior breaks things and makes people mad. So they just add a new config option to enable some convenience feature, and then another and another... Soon new people come and want to use the tool and they're told they have to add a config file turning on a half century of features that seem obvious (cough font-lock-mode)
In web development and app development, user interfaces change constantly, so why don't they fall prey to this as much? I think one thing is many of the tools we're talking about like shells and command line tools are actually APIs as well. Scripts break if you change the interface. If a web interface changes, maybe a scraping script fails, but otherwise nbd.
This is probably the biggest failing of the model of your shell being both a user interface and a programming language you write long-lived and critical scripts in. As a user of the shell you want syntax highlighting and nice features like paging etc, but as a script writer you want the behavior to never change.
In hindsight, maybe the way to do it is similar to apt-get vs apt get, where the former is for scripts and the latter is intended to be a ui that makes no backwards compatibility guarantees.
> In web development and app development, user interfaces change constantly, so why don't they fall prey to this as much?
Because they're happy to just break things and let the user deal with it. Which is (one of the reasons) why I prefer the CLI tools:)
Though I also agree that there's an element of mixing UI/API.
> where the former is for scripts and the latter is intended to be a ui that makes no backwards compatibility guarantees.
Also known as plumbing vs porcelain commands.
Charitably, yes: great defaults are indeed great, and we do need more tools to drop the unergonomic awfulness of the defaults made up decades ago.
But literally, no: it's practically impossible for a very wide variety of tools to have great defaults.
Case in point - that you have zero config in fish and helix is just you, there are also people who have plenty of OMF plugins or use a totally different keybinding scheme, so hundreds of lines of config
So essentially we need more sane defaults?
I've read about sane defaults before, it used to be a best practice haha.
It's not just defaults though. E.g. fish comes with actual integrations with e.g. git, whoch requires both some code and some configuration. So IMO it goes much further than that: the best tools are the ones that do actually solve most common issues straight of the box, even if it takes more effort from developers.
Sensible defaults are very much appreciated (and I've also adopted the philosophy of trying to avoid depending on elaborate customised configurations), but zero-config is not a good goal in and of itself. Very frequently I've found a configuration option is the difference between a tool that does and doesn't work at all for me.
but on the flip side not all tools need to work for all people
This was also my philosophy behind creating insta-infra (https://github.com/data-catering/insta-infra). Single command to run any service. No additional thinking required.
Too many times I've become very frustrated when an installation doesn't work the first time or it has some dependencies that you haven't installed (or worse, you have a different version). Then you end up in some deep rabbit hole that you can't dig out from. Now for each tool I make, it must have a quick start with a single command.
Zero config tools are quite excellent. I include quite a few of them in https://github.com/hiAndrewQuinn/shell-bling-ubuntu , although I also include high-config stuff in there at well so people can compare and contrast - you've got `hx` right next to a fully decked-out `nvim`, for example.
Another tool that I can't live without, which requires no configuration at all is fzf, you can easily and (fuzz)yly find files in your system, move into directories, search in your command history, search active processes and kill them and a lot more. Give it a try
fzf (https://github.com/junegunn/fzf) is really great. Very useful for providing a quick and easy user interface. For example, I use it to fuzzy find inside git branches to have an "improved checkout". I do that since at work branches are usually named "<project>-<issue number>", it's faster to search for the issue number.
I don't mind configuring my tools to work for me. For example I'm a polyglot, inevitably I work with a lot of tools, IDEs, and programs. I've rigged everything so I have a lot of continuity; and context switching isn't a nightmare.
For some I use VSCode, IntelliJ, Micro or others. They all have similar(ish) shortcuts. It means I can transition so much quicker without grinding my teeth.
My point is, I don't mind configuring my tools. What I do mind, is having ease of transfer between environments, so that my configuration comes with me.
I love IntelliJ's config to cloud, it somewhat just works. It allows me to change something on the work laptop that will apply at night on my home machines. VSCode does the same now (it used to require a plugin and github).
Micro and other tools use a ~/.config/subfolder which also works, I use git to pass stuff around various computers, with various degrees of success.
My .zhsrc / .profile is carried around and I have all my 2-3 letters aliases that do complex things, so I don't need to remember everything. This is a powerful way to be very productive very easily. And if you forgot how it works, just read the file. The amount of time where I saw a senior professional waste time re-googling the same thing over, or fumbling around their shell history has boggled my mind. ref. [1]*
If you're a professional, chances are you're going to cart your configs and settings with you for many years to come. So make it as portable as possible.
Even my lazygit is configured. One time, I got a new job, I left it as default... and forced push changes by mistake (because it's not turned off by default and very easy to fat finger it), and that caused a lot of grief. So be careful about acting proud in being 'zero config'.
I'd recommend being efficient, not a purist in search of minimalism. It also shields you from upstream software changing their default on a whim.
[1] https://xkcd.com/1205/
For managing config files I use yadm https://yadm.io/, which I learned of on HN.
Among other great features, it lets me tailor settings per OS (Windows, Mac, Linux) and per client. And my settings are all in git, so they’re easy to save and copy around, and they’re all in one place, not dependent on each tool to know how to save their settings on some server.
Well, zero-config generally means the tool is "modern", meaning it's defaults are current with the current tech/prefs of the most. Does not mean anything else. The issue here is that people tend to customize so they do not like their customization breaks because someone else have made new defaults.
Aside the real "no config", no need to read a manual etc was tempted, historically the most successful who tried it was Microsoft and we know how bad it is...
My take is that yes, we need sane defaults, but also full customization possible, a thing essentially absent in modern software.
I would love it more open source tools and projects would subscribe to the "Easy to learn, hard to master" / sane defaults / zero config approach.
I used to love the photo editor DarkTable. I would spit out very close to camera Jpeg by default, but I could deep dive into some pictures if I wanted to. I don't know what changed, but with every update it just got harder to get something I liked from the pictures. I stopped using it.
I already use fish (with temux) and will take a look at zellij.
I have some problem with DarkTable too. What are you using now instead?
In some cases, the question is: what are sane defaults?
Take emacs or vim. I know a lot of people use them as code editors, and think of them as code editors, but they are really general purpose text editors. It is going to be next to impossible to create a set of defaults that everyone, or even a majority of people, will agree are sane. (That said, they could be easier to configure.)
I think this is a great point that most people forget. If you build something specifically for editing code you can do something cooler than vim/emacs and I've been working on that specific idea: https://youtu.be/owuuFxDBQh4?si=tqYi-RqvFQa6kI8h