I LOVE Kakoune’s default “fuzzy” searching of files in the prompt completions. However, I find opening the suggested file completely counter-intuitive.
The feature:
Let’s say I have open buffers called some.component.ts and some.component.html (and others). I can type :b somehtml and it will filter down to some.component.html, with that file showing as selected. The prompt in this case still shows :b somehtml. When I press <ret> it opens the some.component.html buffer. Perfect, just what I’d expect.
The “problem”:
Let’s say now I need to edit another file called some.component.spec.ts that is not currently open in a buffer. I now type :e somespec, see the list filter down to my file (which is NOT selected this time), but because of the :b behavior, I just press <ret> without thinking. It then creates a NEW buffer called somespec.
What I would expect:
I would expect the :e be consistent with :b, that is, as I’m tying it automatically selects the top file in the list and when I press <ret> it opens that file rather than just creating a new buffer.
If I’m actually creating a new file, since it has to be unique, there should be no suggestions remaining by the time I’m done typing. In that case, I would expect a new buffer.
The question:
Is there a reason for this inconsistency? Are there any examples that prove my above assertion untrue? Is there, or would it be possible to have a plugin to implement this behavior or is this something that can only be done in Kakoune itself?
If only this did not happen to me every single day.
I think one solution is to add to the list of suggestions what you have currently typed as first item.
Then you can select that, but if you select anything else, even if youd don’t press tab, you will open it.
Yes but the behaviour would be consistent visually: opening what you have selected.
For me at least, one major problem is that I may see a single suggestion and think that it is what is going to be opened.
The reason for this behaviour is that the buffer command tags its completion with the menu flag, indicating that arbitrary values are invalid and only the ones in the completion menu makes sense, which triggers that auto-complete on space/enter behaviour.
For edit any valid filename is acceptable, except with the -existing switch, so we cannot auto select the best suggested completion, you could for example want to edit file when file.txt exists.
Kakoune tries to hint at that by showing the completion selected when it will be applied, and unselected when it wont. Its a tough design space because the smarter we try to make this system, the less predictible it becomes.
That’s indeed true, and something I had noticed.
However, in my case, this visual hint is not enough. I would prefer to have the option being written and selected by default, instead of no option selected. Just like when an autocomplete menu displays while writing inside a buffer. In fact, these two things should act the same but they are incoherent.
I was hoping maybe with the -existing switch it would have the behavior I wanted, since there is no longer a question of opening vs. creating. However, it seems that completions don’t work at all with the switch? Why does that happen?
If it had completions, and had the behavior of automatically selecting the top suggestion in the list, then I could create a custom command like :open that does this and my problem would be solved.
Maybe I’m misunderstanding you here, but this does not sound like the right behavior. Most of the time what I’m tying in the prompt is essentially gibberish for fuzzy searching. I would never want to create a file called somespe when I want to edit some.spec.ts. This sounds to me like another form of the exact problem I’m trying to solve with this thread. Or am I misunderstanding your suggestion?
No, you are not misunderstanding. If you do it automatically with muscle memory, then it does not help you at all. The only thing that changes is the visual aspect, which for me at least should help a little bit. But as I say, for muscle memory, it gives exactly the same problem.
OMG, that’s perfect, thank you! I made it a little simpler, since I use fd (an easier-to-use replacement for find) I replaced the entire ag command with fd .. Seems to work, we’ll see how it goes today, but so far it does exactly what I wanted! @mawww How dare you hold out on me like that (kidding of course).
. I grabbed and adapted this from maww’s kakrc.
get on board. cya.
(kidding of course).