default-directory set to "" in fzf buffer

[bcc32]

When fzf-with-command is used and the directory optional argument is not provided, the default-directory buffer-local variable is set to "" (i.e., the empty string) which confuses some hooks. At my site, we have a window-configuration-change-hook which relies on default-directory (and actually reads from the directory) to track statistics on which projects/files are visited most frequently. Of course the empty string is not a valid file path, so this causes errors.

Probably the directory should just be set to whatever default-directory was in the buffer that was current at the time fzf-with-command was invoked?

[pierre-rouleau]

Hi @bcc32 , I have implemented the fix for that inside my fork, https://github.com/pierre-rouleau/fzf.el. My fork is ahead of the repo and I would need to merge it in.
That would take some time to ensure there's no clash and update the docs and I don't have the time for it at the moment. If you try the modified code, please let me know if that solves your issue. I might have some time later to do some cleanup and update the main repo.

[bcc32]

Thanks for taking a look at this, @pierre-rouleau. It seems that this fix has unfortunately uncovered a different bug: https://github.com/bling/fzf.el/blob/641aef33c88df3733f13d559bcb2acc548a4a0c3/fzf.el#L486-L490

fzf--after-term-handle-exit seems to concatenate the directory and the selected option. This is pretty unfortunate---fzf is often used to select from things which are not filenames... (and that is my current use-case) so blindly concatenating the directory is problematic. I did not notice this of course, because default-directory was set to "" 🤦🏼 . One should be able to specify a correct default-directory for the fzf command to run in, without having this postprocessing step applied to the selected item.

[pierre-rouleau]

Hi @bcc32, I'm not sure I understand the way this problem occurs. Can you describe a scenario where you run into the problem?

When, and how, do you run into the default-directory being equal to the empty string?

Also, how would you like to be able to specify the directory from where the fzf executes, if not from the current default directory? Via a prompt?

[bcc32]

Hi @bcc32, I'm not sure I understand the way this problem occurs. Can you describe a scenario where you run into the problem?

Consider this snippet:

(fzf-with-command "seq 1 10" (lambda (number)
                               (with-current-buffer (get-buffer-create "*selected output*")
                                 (erase-buffer)
                                 (insert number)
                                 (newline)
                                 (display-buffer (current-buffer)))))

With the current MELPA version of fzf.el, this displays only the number selected, in the *selected output* buffer. That's the intended behavior, but unfortunately default-directory in the *fzf* buffer is empty and that causes distracting errors.

With your latest fork version, default-directory is set to a sensible value, but unfortunately the *selected output* buffer contains something like ~/3 instead of just 3.

When, and how, do you run into the default-directory being equal to the empty string?

If the directory is not specified, the default-directory in the *fzf* term buffer is equal to the empty string. This is the bug which you fixed in your commit, thank you. Unfortunately, it seems that fzf-with-command relies on this bug for correct behavior in the above snippet.

Also, how would you like to be able to specify the directory from where the fzf executes, if not from the current default directory? Via a prompt?

default-directory is fine.