Closed ericsunplus closed 2 years ago
As far as I can tell, the FZF project expects that the Ctrl-T command is literally "insert file name". It is intended to simply insert, not do completion. The clink-fzf script is trying to faithfully port fzf to Clink/CMD, and is not trying to change how fzf works.
fzf_file
is bound to Ctrl-T by default, and inserts a file name.fzf_complete
is the command that does completion, and it sounds like that is what you want -- it is bound to Ctrl-Space by default, but you could bind it to Ctrl-T if desired.If I've misunderstood how fzf works in other shells, please do let me know.
I did try Ctrl
+ Space
, its behavior is just match in the current directory, it won't iterate into its sub directories. So I can not go to "test.txt" directly. For example after I type sub2
and press Ctrl
+ Space
, it only show items in current directory
Just did a try in Ubuntu bash + fzf. The behavior is the same when I use Ctrl
+ T
. But in bash there is another **
+ Tab
which also invokes fuzzy file completion, no such problem there.
Oh, I see, yes. I've added **
support now in fzf_complete
. Thanks for reporting this!
Hi @chrisant996 , it turns out not working on my side (fuzzy finder interface not show up). Also with the new commit the ALT
+ C
stop to work. I am attaching a screen recording as below
Not sure if I am missing something here
Oh. Yes, I didn't think of the case where there is only one normal match completion. For **
to work properly it will have to work quite differently. This weekend I'll work on finishing **
to work when there's only one match in the current directory.
The Alt+C thing was a typo. I've fixed it, and also cleaned up some of the code a little.
Thanks!
Thanks you! clink and fzf really makes life better for me. Will definitely advice them to my collegues
The **
should work recursively now even when there's only 0 or 1 file matches in the typed dir.
@chrisant996 , thanks for the quick fix in weekend. I find it is still not working on my windows cmd (**TAB
don't invoke the fzf selector, like my screen recording in earlier post). As comparison, a Ubuntu screen recording is attached
Don't figure out what might be the root cause.
**TAB
to function correctly). **TAB
is not functioning at windows CMD at all (in fzf repo, the title of fuzzy completion may imply it is only for bash and zsh)So can I know what is the situation on your side on windows CMD? ( I am also attaching my experiment folder clink_fzf.zip )
Have you set up a key binding for Tab to invoke "luafunc:fzf_complete"
?
As documented, the fzf.lua script sets Ctrl-Space as the key for invoking completion with fzf.
If you want another key to invoke it, then you need to set up a key binding.
In your .inputrc file:
TAB: "luafunc:fzf_complete"
For convenience, I've added a default key binding for Tab as well, for similarity with fzf in other shells.
I had avoided that originally, because it didn't seem to me that always using fzf would be very desirable. But maybe it is, and anyway at least this way it works in a more familiar manner "out of the box".
My fault, I was thinking that the key binding is some default setting for fzf
itself.
After your latest commit, the **TAB
can trigger the FZF selector, but after press Enter
, the selection don't goes to the command line
Another thing is now TAB
will default invoke FZF selector, even there is only one choice, this is not the case in Ubuntu bash. In there only **TAB
is recognized as a hotkey, not TAB
itself. I tried to use .inputrc
to use another hotkey like \M-k
, but **
Alt
+k
is not recognized anymore. Maybe is_trigger
function need to be revised for key combination other than TAB
My fault, I was thinking that the key binding is some default setting for
fzf
itself.
Ah, no. Key bindings are always part of the shell. For bash, zsh, etc the fzf package comes with shell scripts that set up key bindings. Just like fzf.lua sets up key bindings.
After your latest commit, the
**TAB
can trigger the FZF selector, but after pressEnter
, the selection don't goes to the command line
Ah. Yes. I might need to add a LUA API in Clink in order for this to fully work. Will investigate.
Another thing is now
TAB
will default invoke FZF selector, even there is only one choice, this is not the case in Ubuntu bash.
Yes. It's an artifact of how the filtering was originally hooked up. I've added a case to prevent fzf from activating when there's only one match.
In there only
**TAB
is recognized as a hotkey, notTAB
itself.
Oh, I see, fzf doesn't replace completion in general. Interesting. I'll adjust it so TAB only invokes the fzf UI when used following **
(by the way the **
is not part of the key binding -- the command examines the text preceding the cursor to see if **
is present, but the **
is not actually part of the key binding -- not in bash, zsh, fish, or Clink).
I tried to use
.inputrc
to use another hotkey like\M-k
, but**
Alt
+k
is not recognized anymore. Maybeis_trigger
function need to be revised for key combination other thanTAB
I don't understand the statement.
It works fine for me. I have several different key bindings for "luafunc:fzf_complete"
, and all of them work the same.
Please show the exact key binding line you added to your .inputrc file. Maybe there is a mistake in how the key binding is written?
(Also, is_trigger
has nothing to do with the key binding. There's no way to revise it for specific key bindings, because it isn't related to key bindings.)
About the duplication of Bug 4
, I experiment again and as you said, it is not related to the key binding. It is just because of a corner case of **
+ fzf_complete
: I have to type some character before **
for fzf selector to show up.
For example currently I am in clink_fzf
directory, If I type cd **TAB
fzf selector is not showing up, If I type cd su**TAB
the selector will show up. In my previous reporting I accidently use the former for my new key combination but use the latter for default **TAB
combination, and misunderstood it as the key combination have a different length
that might need the index in line_state:getline():sub(line_state:getcursor() - 2, line_state:getcursor() - 1)
to adjust accordingly
About the duplication of
Bug 4
, I experiment again and as you said, it is not related to the key binding. It is just because of a corner case of**
+fzf_complete
: I have to type some character before**
for fzf selector to show up.For example currently I am in
clink_fzf
directory, If I typecd **TAB
fzf selector is not showing up,
I don't have to type anything before **
.
**
Tab list gets inserted correctly.**
Tab uses fzf, and Tab does not.cd **
Tab shows the fzf UI.Hi @chrisant996 , I can only duplicate the #4 issue in a previous commit
Everything works fine with your latest commit. I am feeling cmd
overwhelming bash
now :). Thank you again for the continuous help and enhance for clink
and clink-fzf
.
Hi there,
Suppose I have the following directory structure
I now want to edit test.txt in sub2 directory. I first type![image](https://user-images.githubusercontent.com/7379534/172819045-bba951ea-737b-412d-ad46-5c5916bfd3d4.png)
vim sub2\
and then useCtrl
+T
to list possible filesI then type![image](https://user-images.githubusercontent.com/7379534/172819483-c6c7e730-22a5-4052-881d-a9150c64a91f.png)
test
to narrow down the entriesIt locate the desired path. I then press
Enter
. The absolute path shows on command line. However, thetest
I typed before is still thereBecause of this redundant part the command line becomes an invalid one
I noticed that this don't happen for
Alt
+C
subdirectory selector, the already typed part can be merged with the selection. Is it possible the file selector behavior get aligned?