Home

🔍🐟 fzf.fish wiki ✏️📘

Welcome to the Wiki, where you can read the Q&A style help or learn about the vision of this project!

Bear in mind that while I update the Wiki in lockstep with the main branch, I do not keep around documentation pertaining only to previous versions. Therefore, consider updating fzf.fish before reading the Wiki.

Why are new issues, pull requests, and discussions disabled?

First off, fzf.fish is not abandoned. The truth is I'm burnt out with fzf.fish. I love adding new features, but responding to the messages I get has been distracting, frustrating and time consuming. Sometimes it's helping users debug issues that often turn out to be user error has been. Sometimes it's heart-wrenchingly declining a PR someone put a lot of work into but is a bad fit. Sometimes, it's saying no to new ideas that several people want but are costly to implement and I just don't have the time anymore. Rarely, thankfully--but it has happened--it's defending my product or design decisions from condescending accusers.

It has reached a point where I am demotivated to add new features because I dread the long flood of messages that come after. Of course, sometimes I get bug reports and ideas, but many are out.

I considered disabling notifications and not checking fzf.fish but it's hard not to. Plus, it's rude to the those who ask questions and wait indefinitely for a reply. So instead, this is my new plan to balance feedback with my own energy levels:

• By default, interactions are disabled with the repository.
• When I add new features, I will re-enable interactions for a time to gather feedback and bug reports for a few weeks. In this short period, I can be fully available and reply to issues.
• Once I believe fzf.fish is stable, I will disable it.
• I will occasionally pull for feedback from trusted collaborators.

I believe that in the long run, this is better for everyone because I will have more energy to work on fzf.fish.

Why did I move documentation from the readme to the Wiki?

Much of the content of the Wiki originally lived in the readme. Initially, it made sense to consolidate all the documentation on the readme as the readme is easily accessible and can be updated alongside the code. However, this became burdensome and counterproductive as the plugin grew:

• There is a tension between providing comprehensive documentation and keeping the readme easy to scroll through. It requires a lot of effort to balance that.
• No matter how succinct I tried to be, the readme was becoming very long, such that it was intimidating for prospective users and hard to navigate for existing users.
• People reading the git log for the latest changes likely find non-feature-related diffs and commits changes distracting.
• Making updates to the front page of the repo is anxiety-ridden for me, but updating Wiki much less so.
• Having multiple pages and a sidebar at my disposal makes organizing the content easier.
• Much of what I wanted to explain to users is not documentation per se (e.g. FAQ and design philosophy).
• Finally, I obsess over my words and find myself writing and rewriting every sentence again and again.