> People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive.
Yes! But asking the user to manually configure the system is a lame way to accomodate those preferences. It's better if the software can learn from the user. For example, if the user runs a certain command frequently, don't wait for the user to define an alias, just suggest it while the user types. Your shell can become more customized to you, with no configuration necessary.
This doesn't work for everything - key bindings for example. But it captures the "no configuration" world view.
> Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization.
Not all configuration options are there to enable user customization. A lot of configuration is just punts on hard problems or decisions. For example, options like zsh's RC_QUOTES or bash's histappend. These don't reflect user preferences. They're just legacy or churn. The shell should just define its own language, and not make the user decide how '' is interpreted.
Every configuration point incurs a cost. The user who moved on to the über-flexible system discovered which plug-ins require which options, and which combinations are incompatible with each other.
This is where a layered approach really shines: have a rigid core with a flexible exterior. Allow the user to set the prompt, colors, key bindings, wrap commands likeΩ `grep` and `ls` to set colors, etc. Prefer open-ended customization (let the user write the function) instead of enumerated configuration (pick from N behaviors), an keep the core consistent so that there's something stable to build on. That's fish's philosophy.
Fair enough. I'm all for having the program do some intelligent prompting of the user, as long as it doesn't become annoying (like Microsoft's "Clippy" :-D).
There is a sweet spot with most software between being buried in a sea of options and having no options you can configure at all. I tend to gravitate toward having a sensible set of defaults and letting the user configure them otherwise if they want. Having options grouped together can be good too (like keybindings -- vim vs emacs style bindings for example).
I also like the idea of customization through functions/scripting rather than just giving the user a choice between N options. That's another area where a set of sensible defaults can be good -- defaults in that case, which can be programmed around.
BTW, thanks for responding here. Always nice to get feedback from the developers of a piece of software directly. I really haven't looked at fish for years (though I'm certain I checked it out a while back). I'll give it another look to see if there's something there to catch my interest.
Sorry I didn't see your response until today, I was busy the last couple of days and just got back to it.
I appreciate that you call out keybindings as a likely exception, but particularly in the shell, keybindings are 90% of my configuration! For some settings I'm sure there are sane defaults, but if programs don't know whether I prefer vim or emacs then they're going to have a bad time.
> People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive.
Yes! But asking the user to manually configure the system is a lame way to accomodate those preferences. It's better if the software can learn from the user. For example, if the user runs a certain command frequently, don't wait for the user to define an alias, just suggest it while the user types. Your shell can become more customized to you, with no configuration necessary.
This doesn't work for everything - key bindings for example. But it captures the "no configuration" world view.
> Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization.
Not all configuration options are there to enable user customization. A lot of configuration is just punts on hard problems or decisions. For example, options like zsh's RC_QUOTES or bash's histappend. These don't reflect user preferences. They're just legacy or churn. The shell should just define its own language, and not make the user decide how '' is interpreted.
Every configuration point incurs a cost. The user who moved on to the über-flexible system discovered which plug-ins require which options, and which combinations are incompatible with each other.
This is where a layered approach really shines: have a rigid core with a flexible exterior. Allow the user to set the prompt, colors, key bindings, wrap commands likeΩ `grep` and `ls` to set colors, etc. Prefer open-ended customization (let the user write the function) instead of enumerated configuration (pick from N behaviors), an keep the core consistent so that there's something stable to build on. That's fish's philosophy.