fzf is not working on remote directory.

[tttuuu888]

fzf only shows the result of local directory. I think it is necessary to update the part of (make-term "fzf" "sh" nil "-c" sh-cmd) but couldn't figure out how yet. I'll appreciate for any thoughts or hint. Thanks.

[anschwa]

I looked into a solution for this but it seems like something emacs has a hard time accommodating.

Instead, I'm connecting to my emacs session with X11 forwarding, so it's as if I'm editing on the remote machine directly.

ssh -X $MY_HOST  -f emacsclient -nc

On macOS using XQuartz, you can open an XQuartz terminal and run ssh -X $MY_HOST followed by emacsclient -nc to open a new graphical emacs frame on the mac.

[tttuuu888]

@anschwa Thanks for your suggestion.

I quickly test it but it failed with a message of "X11 forwarding request failed on channel 0". I guess it's because the server is without GUI.

Well, As it's been quite a while since I opened this issue, I already found 'counsel-fzf' as an alternative. It works almost identical with 'fzf'. But it doesn't use CPU resource over 100%. Mostly it's fine but sometimes it's annoying when I have to use fzf in a folder with numerous files.

Anyway, thank you for your idea again.

[anschwa]

I think it would be possible to open a remote connection within the make-term invocation. There are a few functions that we could use to get the connection info:

(file-remote-p default-directory)

(when (tramp-tramp-file-p default-directory)
  (tramp-dissect-file-name default-directory))

I imagine this would let us do something like:

(make-term "fzf" "ssh" nil ssh-cmd "-f" fzf-cmd)

[tttuuu888]

@anschwa Thanks for further idea! I will also check this more.

[ssnnoo]

I tried this in a super hacky way in fzf-directory (see below) and it works to open a file; but I think the issues that arises (afaics) are:

• there is no way to to attach it to a tramp session as such with make-term, i.e. to open the term via ssh one needs to authenticate again (passwords / keys etc.)
• it is very cumbersome to construct the ssh command from the tramp session, and it would only work for some sessions anyway.

counsel-fzf (ivy) works via tramp ; I am not sure how but my guess is that it starts a remote async process and restarts it after new user input?

(when (file-remote-p directory)
  (let ((sh-cmd) (zmeth (nth 1 (tramp-dissect-file-name directory)))
    (zuser (nth 2 (tramp-dissect-file-name directory)))
    (zdomain (nth 3 (tramp-dissect-file-name directory)))
    (zhost (nth 4 (tramp-dissect-file-name directory)))
    (zport (nth 5 (tramp-dissect-file-name directory)))
    (zdir (file-name-directory (nth 6 (tramp-dissect-file-name directory))))
    (zhop (nth 7 (tramp-dissect-file-name directory)))
    (fzf-cmd "fzf")
    (fzf/args "-x --color bw --print-query --margin=1,0 --no-hscroll"))
    (setq sh-cmd (format "%s %s -q -t \"cd %s && %s %s\"" zmeth zhost zdir fzf-cmd fzf/args))
    (make-term fzf/executable "sh" nil "-c" sh-cmd)))

[tttuuu888]

It's been quite a while since I've been back here.

As @ssnnoo mentioned, counsel-fzf works on tramp, so I compared the two and found out the difference between fzf and counsel-fzf. In deep inside, counsel-fzf uses start-file-process and fzf uses start-process. In case of counsel-fzf, start-file-process is called in counsel--async-command-1 function, which is still a part of counsel pacakge. On the other hand, for fzf, start-process is called from the term-exec-1 function inside the term package. So, in the current structure, it seems that this issue cannot be solved simply by updating the fzf package internally.

When I changed start-process of the term-exec-1 function to start-file-process and tested it, fzf actually somehow works on tramp.(although it could break something else but for only testing) However, it does not work properly right away, such as the file list is not displayed properly and the enter key does not work. On remote, start-file-process eventually falls into tramp-file-name-handler but I didn't look into it more.

This is all I found today. I hope that one day, fzf will work properly in remote as well.

+Additionally, I tried to get fzf to operate normally without the above abnormal behavior, and by chance it was successful. However, I can't confirm exactly how to reproduce it, so I'm just posting it like this.