I sort of get the appeal of fine-tuning the terminal environment to perfection but after fiddling with such things for many years - decades - I ended up using mostly stock settings with a very few changes. The advantage of that approach is that I feel at home just about anywhere instead of just on my one or few customised systems. My customisations mostly consist of a local /bin directory with a few hundred scripts (wc -l now shows 263) I made over the years which I dump in a new environment plus a few additions to .bashrc (yes, bash, not one of the fancy replacements (zsh, fish, oil, ...) which are supposed to be better but in reality just end up being different) to set custom paths etc.
Besides cleanliness which is more a preference I agree, separating config, data, and cache makes it easy to know what can/should be backed up, what can be synced across machines, etc.
I sort of get the appeal of fine-tuning the terminal environment to perfection but after fiddling with such things for many years - decades - I ended up using mostly stock settings with a very few changes. The advantage of that approach is that I feel at home just about anywhere instead of just on my one or few customised systems. My customisations mostly consist of a local /bin directory with a few hundred scripts (wc -l now shows 263) I made over the years which I dump in a new environment plus a few additions to .bashrc (yes, bash, not one of the fancy replacements (zsh, fish, oil, ...) which are supposed to be better but in reality just end up being different) to set custom paths etc.
And then you get friends like Claude - dozens of them - which prefer to crap all over $HOME.
The app ‘Conductor’ does this, and I had to uninstall it; I just can’t crack my ‘ls ~/.co<TAB>’ habit, and “nd” is juuuuuust ahead of “nf”.
It *used to* be ‘~/c<TAB>’ before .claude crapped itself into existence..
I feel you. My solution is leaning into `z` ("frecency" heuristic), and selective use of "extra" zshrc aliases.
I’m moving slowly in the direction of Guix home for dotfile management, but until it covers all my bases, I’m fond of the gnu stow method
Never understood the point of having a dotfile for all of config when config is the point of dotfiles.
Besides cleanliness which is more a preference I agree, separating config, data, and cache makes it easy to know what can/should be backed up, what can be synced across machines, etc.
I find that there is a tendency to make too many things hidden. I just assume I'll have to show hidden items by default in all contexts now.