Design Philosophy

The design philosophy can be summed up as this (quoting @JorgeBucaran):

Small is beautiful, make each program do one thing well, and use composition.

Small is beautiful

Less functionality

• means less bugs
• correlates with simpler code
• correlates with faster code
• means less documentation that users have to read
• will make this plugin faster to set up, understand, and master
• means less maintenance burden for me
• helps reduce feature cruft

Make each program do one thing well

What fzf.fish focuses on is helping users complete the most common patterns of commands more efficiently and accurately. It does not aim to help users execute their commands. It does not aim to cover 100% of fzf use cases, or even 95%. Following the Pareto Principle, my goal is to cover roughly 80% of use cases with 20% of the required features. This is why all its features have to do with inserting the user's selection into the command line and has no functionality for instant cd or open with $EDITOR.

Use composition

One advantage of focusing on helping users insert entities into their command line each feature can be easily composed into a command to do perform a wide swath of actions. For example, the find file feature can be combined with cd, vim, emacs, code, rmdir, ln--you name it. A command that only cds into a directory cannot have such flexibility.

Criteria for new features

It is better to not have a feature than to have a feature that users don't use, can't trust, dislike, or find confusing. Put positively, new features should

• be helpful for a wide swath of users
• work consistently for all users, no matter how they use it or how they configure their environment
• be performant and have a low-friction UX
• intuitive to use
• be innovative - offer a unique solution not offered by another, readily available tool