-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'complete-common-prefix' option. #384
Conversation
TL;DRNice work, but I've think I've identified a few issues with this PR. Hopefully they can be resolved because I too would kill for the target behavior to be implemented into DetailsAfter trying out your branch, I've found two problems. @Aloxaf I encourage you to weigh in if you can. Problem 1: Slashes after directoriesThis is somewhat of a corner case, but does degrade the UX, so should still probably be dealt with. Given a directory containing the following $ ls
foo # directory
foo.sh # file
$ ls foo/ The appended slash effectively prevents Problem 2: Cross-platform variationI've found that the behavior varies on different platforms. I attempted to reproduce what you stated in the PR's description:
To that end, after setting up the file tree that you described
I tested the latest commit ( $ zsh --version
zsh 5.8.1 (x86_64-amazon-linux-gnu)
$ zsh --version
zsh 5.9 (x86_64-apple-darwin23.0) On Amazon Linux, it worked exactly as advertised, with But on MacOS, I'm not a zsh expert, but after comparing line-by-line the |
This option automatically completes to a common prefix of all options instead of starting fzf if such a prefix exists.
This happens if the user types 'ab'<TAB> while there exists files like 'abc' and 'aBC'. In that case, the prefix shrinks to 'a'.
8ecee14
to
4b37ea7
Compare
Thank you very much for your detailed feedback! I observed problem no 1, too. But I was not aware that my PR introduced this behavior. I was able to fix it by removing the After I "fixed" the first problem, I tried to reproduce problem no 2. I have a debian oldstable (zsh 5.8) and an ubuntu linux (zsh 5.9). With both, I was not able to reproduce your problem. I guess, my zsh knowledge is not good enough :) |
@jochenwierum And thank you for the prompt attention! I've just tested the changes you forced pushed (using commit However, in testing I did notice two other regressions. Not sure if they existed before as I don't think I tested for this specific case. If all files in a directory contain the same prefix - which is definitely something everyone's bound to encounter from time to time, e.g. log files - tab completion actually "eats" the path. I'm curious to see if you're able to reproduce this. Run this command to set up the test: TMPDIR=$(mktemp -dp.) && touch $TMPDIR/prefix.{1..5} You should now see the following: $ ls -1 $TMPDIR
prefix.1
prefix.2
prefix.3
prefix.4
prefix.5 Now try this: ls $TMPDIR/<TAB> For me, nothing happens. I expected the prompt to complete to Next, and much stranger, start entering the common prefix and re-attempt the tab completion: ls $TMPDIR/p<TAB> For me, This same behavior happens for any of ls $TMPDIR/p<TAB>
ls $TMPDIR/pr<TAB>
ls $TMPDIR/pre<TAB>
ls $TMPDIR/pref<TAB>
ls $TMPDIR/prefi<TAB>
ls $TMPDIR/prefix<TAB> But strangely, when I do ls $TMPDIR/prefix.<TAB>
In my mind, these observations suggest that whatever these regressions stem from, it resides in the "all options share a common prefix" branch of the conditional tree. I wish I could assist further e.g., patching your code, but my grasp of zsh is even weaker than yours (which seems quite good btw!). |
Removing those flags unconditionally may not be a good idea, it causes the bug addressed in #384 (comment). |
I think this may be because |
Thanks for pointing me to the tests. Indeed, it is enough to remove I added a test for completion with prefix-completion and without prefix-completion. They both work now. But there is still a problem with nested directories, as the tests point out. mkdir -p abc/def/hij abc/dfe/hij
./a/d/h<TAB> My normal zsh behaviour is, that the prompt changes to With my common-prefix implementation, the prompt changes to Disabling the common-prefix implementation keeps I added tests for both implementations (they are red) and pushed my current version. |
@jochenwierum Following up - Your most recent patch resolves all issues for me in my own testing (except I guess the nested dir thing you mentioned - I didn't even know I love it and hope you can get this merged soon. Keep it up! |
I finally managed to get it to work. Could you please try #413 ? |
Closed by #413. Thanks for your contribution anyway! |
Great work! It does exactly what I tried to achieve! Thank you very much for your work! |
This option automatically completes to a common prefix of all options instead of starting fzf if such a prefix exists.I had the same problem as FunctionalHacker in #8
Let's assume there is the following directory:
When typing
ls 2<TAB>
I expect that my prompt changes to "ls 234d". When typingls 123<TAB>
I expect to see fzf with three alternatives (123a-123c). When typingls <TAB>
I expect to see fzf with all files. However, when typingls 1<TAB>
I don't expect fzf to appear at all. Instead, I like to see a completion tols 123
first.I was able to hack this behavior into fzf-tab. It can be disabled by setting the zstyle parameter
complete-common-prefix
tofalse
. However, the solution feels hacky and I'm not an expert on zsh or its completion system. While it works for my scenarios, I have no idea if it breaks something else.So please review this PR very very carefully!