Just so you know, the fact that you indented your link to make it be monospace font also means it's not clickable.

"having non-standard configuration is inherently more complex"

I disagree. It can be more complex, but it is not at all inherent. If I configure my shell, my editor, my whatever software to work more like other software I use (keybindings, etc), I can actually make it less complex for me, because copying over a few config files on those rare occassions I need to is much faster than trying to learn a whole new set of keybindings/behaviors (and trying to keep all of the different ones in my head).

Yes it is possible to tinker yourself into oblivion (especially if you change the same items frequently, and never come to a stable state), but that is by no means the inevitible outcome.

I also very much disagree with this line from the fish shell design page:

"Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it."

Now I understand what they are getting at, and if they didn't start that sentence with "Every" I would not disagree so much. Yes your program should make it as easy as possible for you to figure out how to do what you want to do. However, not everyone in this world is the same. People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive. So every configuration option is most definitly NOT a failure of the program and the programmer who implemented it.

Granted there are programs out there that were seemingly made to purposefully obfuscate how they work (like the dev who wrote them gets some kind of sick pleasure out of making users' lives difficult :-D ). Obviously you should do your best to avoid that outcome (which almost aways comes not out of programmer malice, but other factors, I'm sure).

There is a place, I think, for a really good set of defaults that are consistent and easy for users to follow. I do not agree, however, that it must come at the price of forbidding users to customize their software. 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. If someone finds your program useful enough to want to customize it to their tastes, you risk losing a valuable customer/user who will move on to something that lets them shape it to work they want it to.

[edited to remove unintentional indent -- can't seem to break that habit of putting spaces at the beginning of the first line of a paragraph :D ]

fish shell dev here.

> 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.