Checklist

• I have read through the manual page (man fzf)
• I have searched through the existing issues
• For bug reports, I have checked if the bug is reproducible in the latest version of fzf

Output of fzf --version

0.60 (devel)

OS

• Linux
• macOS
• Windows
• Etc.

Shell

• bash
• zsh
• fish

Problem / Steps to reproduce

I realize that a similar issue was already opened and closed ~7 years ago in #1312. At the time, the reasoning for not allowing queries longer than 300 made sense.

I don't think it's worth the effort. What would be the point of allowing exceptionally long query strings? Also, the time complexity of the search algorithm of fzf is proportional to the length of the query, so having some limit makes sense in that regard as well.

From what I can see the --disabled option did not exist at this time. Because all queries were used for fuzzy finding having super long queries did not make much sense. Now that queries can be used for basically anything, this limit seems arbitrary in some scenarios.

For example when using fzfrepl as a live preview for an ffmpeg filtergraph: #1312 (comment)

Recently, I also hit the 300 character limit when trying to search through all the files owned by a package on my system. I use fzf as a front-end to ripgrep like many others. With my rg-fzf script I specify the files to be searched as command-line arguments but I can edit the files being searched along with ripgrep options from the fzf query.

For example if I run:

rg-fzf src man

the following query is generated:

Everything before ;; is a python expression that builds the ripgrep command to be run. It's a bit of a hack but it allows me to easily modify everything about the ripgrep command without needing to close fzf.

While trying to debug my system I tried to search through all the files owned by xdg-desktop-portal with this command:

for file in $(pacman -Ql xdg-desktop-portal | cut -d " " -f 2-); do [ -f "$file" ] && echo "$file"; done | xargs rg-fzf

But the query got cut off at 300 characters.

I propose any of the following solutions:

• Add an option for manually specifying the limit.
• Disable the limit if search is disabled. Since the limit only makes sense when search is enabled, only use it then. What would happen if the user had a very long query and then used the enable-search action? Should the query be truncated? That does not seem desirable.
• Remove the limit. Does the user really need to be protected from a long search time?