Prefix completion conflicts with fuzzy match

[Barbaross93]

Hello again!

I was trying to use the prefix-completion patch and it wasn't working. I figured it was a conflict with another patch somewhere, so with a clean build I went through and enabled each patch individually to see which was the culprit. None were. It turns out, installing dmenu with sudo make install the prefix command doesn't work; i.e., it removes what was entered so far. If I just run make and run dmenu in the same directory, so something like echo -e "test\ninput" | ./dmenu" the completion works. I have no idea what would cause this. Do you have any ideas @bakkeby?

[bakkeby]

That doesn't make much sense, the binary is the same so it shouldn't matter where you run it from.

Do a

$ which dmenu

and check if the binary is the same.

If you also installed dmenu via your package manager for example then that might be placed in a directory other than the place where the Makefile places it.

[Barbaross93]

In the screenshot, the top half is the flexipatch build and the bottom half is dmenu installed through the repos on Arch linux. It looks to me that the file locations are correct. If I uninstall dmenu, which dmenu returns dmenu not found. Since I use a custom PKGBUILD to install dmenu-flexipatch, I can check the directory where the built binary is placed. It behaves as expected when ran in that directory, but from the installed directory I have this problem. At first I thought maybe the prefix patch depends on something in the original directory but that cant be the case if the built pkg binary works as expected. The only other thing I cant think of would be permissions, but I have no idea why that would matter

[Barbaross93]

Scratch that bit about permissions, they're the same. I'm clueless

[Barbaross93]

Ok, so perhaps this is a bug with the patch. So it does work from the installed directory, but it only completes when there is a match. If there are multiple possibilities it seems, it just wipes what I have entered when I believe it should be completing to the point where it cant differentiate. Is this expected behavior?

Further, it only seems to complete when there are only a couple possibilities. Any more than 2 possibilities I then see the potentially buggy behavior

[bakkeby]

Just to make sure, is the sha1 sum the same for both binaries?

$ sha1sum $(which dmenu)
$ sha1sum ./dmenu

[Barbaross93]

Yes, looks like they are the same

[bakkeby]

Then it should be fine. I can't say that I am able to replicate any completion issues.

Can you give me a list of the patches you have enabled?

[Barbaross93]

I have enabled:

Center
Ctrl v to paste
Fuzzy highlight
Fuzzy match
Line height
Managed
More Color
Navhistory
Numbers
Password
Prefix completion
Symbols
XYW

Huh, that's more than I thought I had...

[bakkeby]

So the PREFIXCOMPLETION_PATCH makes it so that the tab completion only works the matched text starts with whatever you have typed in dmenu.

That the input blanks when you hit tab has to do with that FUZZYMATCH_PATCH is also enabled, which allows for fuzzy matching of the input string. It seems that there is some sort of conflict between the two.

What is actually the expectation here with regards to the behaviour of the prefix completion patch in this context?

I'd have thought that the normal tab completion that you have when the patch is not enabled is better suited.

[Barbaross93]

I had a hunch that the fuzzymatch patch might had something to do with it. When I enabled both with the simple test command it wasn't an issue and now using a much longer list of options the problem becomes apparent.

I suppose I would expect (with having both of these patches enabled) that the prefix completion would work as it always has, complete to the next prefix, ignoring the fuzzy possibilities. E.g. if foobar, fobar, and foobr where possibilities, then by typing 'f' and then tab, I'd expect to see 'fo' and if I type 'foo' I'd expect 'foob' to be completed.

When you say 'patch not enabled' do you mean not the fuzzy match patch enabled? If so, I should probably do that, but a few of my scripts either start with icons or a numbering system and thus make having the fuzzy patch useful

[bakkeby]

No I meant having the PREFIXCOMPLETION_PATCH disabled.

[Barbaross93]

Oh, looks like it works works without the patch! I thought I needed it to have tab completion. Thanks you so much!

[bakkeby]

I may still look into that compatibility issue when you have both the fuzzy match patch and the prefix completion patch enabled.

[Barbaross93]

I'll reopen and rename the issue for you then

[bakkeby]

I think the above change should be fine.

To test this enable both:

• PREFIXCOMPLETION_PATCH and
• FUZZYMATCH_PATCH

compile, then run this in the directory of dmenu-flexipatch:

$ ls | dmenu

Type "u", this should match several options:

• util.c
• util.h
• dmenu.1
• dmenu.c
• dmenu_path
• dmenu_run

Try hitting tab to perform tab completion for the text input.

Nothing should be happening because not all matches start with the prefix of "u", that being the restriction and idea of the prefix completion patch.

Now try typing in "co" instead, this should give three options:

• config.def.h
• config.h
• config.mk

Try hitting tab to perform tab completion for the text input.

The expected behaviour is that the text input completes to "config".