gennaro-tedesco / nvim-possession

📌 the no-nonsense session manager
MIT License
215 stars 7 forks source link

Bad filepath error (No such file or directory) #24

Closed EmreDogann closed 1 year ago

EmreDogann commented 1 year ago

I created the sessions/ directory and used the default binding \sn to create a new session. However, when I go to load that same session file from the session list (\sl) then I get this error: image

It looks like to me that there is some junk characters at the beginning of entry_str messing up the file path. They are not regular whitespace it seems as a vim.trim(entry_str) did not work. If I strip the beginning characters via a substring, it works fine with no errors: image

Why is there whitespace at the start of entry_str?

EDIT: I just noticed that my possession.list() window looks very different from the list menu in the README gif. Maybe a change with fzf?

Versions

fzf-lua: Main branch, commit 2670983 (most recent version as of posting) nvim-possession: Main branch, commit 27f7535 (most recent version as of posting)

NVIM v0.9.2-dev-25+g470017c9a Build type: Release (Built from source) Using lazy.nvim

EmreDogann commented 1 year ago

Update:

It seems that when I set the fzf-lua preset to "telescope" it works with no errors. Below is how I'm loading fzf-lua (my copy-paste to clipboard is broken right now so I apologise for the screenshots):

image

image

With that being said, it still looks very different from the gif in the README.

gennaro-tedesco commented 1 year ago

Let us try and understand under what circumstances the error can be reproduced:

I created the sessions/ directory

does this mean the error occurs when setting a custom

sessions = {
  sessions_path = ...
  ...
}

rather than vim.fn.stdpath("data") .. "/sessions/" or do you still see the error with default configuration? Moreover I see that in your example you are explicitly setting a fzf-lua previewer: would it still occur if using the default configuration for both nvim-possession and fzf-lua, namely just using

{
  "gennaro-tedesco/nvim-possession",   
  dependencies = {
     "ibhagwan/fzf-lua",
  },
  config = true,
}

? I am running the default configuration with latest commits as of now and cannot reproduce it.

EmreDogann commented 1 year ago

So I've stripped everything down to the code snippet you provided and unfortunately, it's the same error. I uninstalled all my other plugins in case of conflicts but that didn't help. I also tried reinstalling fzf through apt but same result. nvim checkhealth also says everything is ok.

does this mean the error occurs when setting a custom

Sorry, that was bad wording on my part, when I first installed the plugin it was giving me errors about how it couldn't find the /sessions/ folder in the default path. So I created that manually.

gennaro-tedesco commented 1 year ago

So if I understand correctly:

  1. you created the session folder manually on your computer
  2. you indicated the path to said session folder in
    sessions = {
    sessions_path = ...
    ...
    }
  3. though the path is correct, you see an exception "No such file or directory"
  4. such exception in 3. occurs because of extra white spaces that aren't stripped correctly
  5. if you use the fzf-lua setup "Telescope" the error disappears

correct?

What is your fzf-lua setup? I cannot reproduce the error by using a default fzf-lua configuration, so I suspect there may be some previewers options that you may be setting that for some reasons artificially add the extra spaces (and they happen to disappear when using the "Telescope" setup). In particular the plugin uses the in-built previewer, so do not manually set bat as one.

P. S. Do you maybe have some particular fzf options, for separators, inline arguments or such? fzf-lua inherits the general fzf shell options and parses them into the preview, so that may cause some additional characters to appear.

EmreDogann commented 1 year ago

you created the session folder manually on your computer you indicated the path to said session folder in

I created the folder manually in the default location (i.e. vim.fn.stdpath("data") .. "/sessions/"). I did not change the sessions_path field. Apart from that all the other points are correct.

What is your fzf-lua setup?

My setup is the default, in this case it is loading fzf-lua as a dependency through nvim-possession.

P. S. Do you maybe have some particular fzf options, for separators, inline arguments or such? fzf-lua inherits the general fzf shell options and parses them into the preview, so that may cause some additional characters to appear.

I do have a .zshrc where I set some fzf arguments like separators and such, but I've commented those out and reloaded to make sure they weren't conflicting. Maybe there is some cache somewhere that fzf might be using?

gennaro-tedesco commented 1 year ago

Could you show me (perhaps with a small recording) the following steps:

  1. create a new session with nvim-possession
  2. go to the location of said session on your computer, check if the name/path is correct
  3. load the session (which should allegedly result in an error)

What are the characters ~/.d/l/s/n/s/ that are displayed in your screenshot, at the fzf-lua prompt? Might it be they are references to other directories and perhaps something on your computer isn't resolving the ~/ correctly?

EmreDogann commented 1 year ago

What are the characters ~/.d/l/s/n/s/

This is the short path to my vim.fn.stdpath("data") folder which in my case is ~/.dotfiles/local/share/nvim/. To be honest I don't know why fzf is showing it as this short path I don't recall settings anything like that. It follows what I set for my XDG paths:

# Inside .zshenv
export XDG_CONFIG_HOME = $HOME/.dotfiles
export XDG_DATA_HOME = $XDG_CONFIG_HOME/local/share
export XDG_CACHE_HOME = $XDG_CONFIG_HOME/cache

What I did was clear my vim.fn.stdpath("data") folder and tried it again. But when I now go to call require('nvim-possession').new() I get a different error saying sessions_path does not exist:

https://github.com/gennaro-tedesco/nvim-possession/assets/48212096/46e906eb-b118-4e85-b443-9398b60cc5a8

If I mkdir create the sessions/ folder at ~/.dotfiles/local/share/nvim/ then this error goes away.

But then I run into the error from earlier:

https://github.com/gennaro-tedesco/nvim-possession/assets/48212096/b8868326-c02f-4d17-8c40-9f1eeb95f028

EDIT: Apologies I forgot step 2. Here is a screenshot of the session file from the path it saved to: image

gennaro-tedesco commented 1 year ago

Hmm, may I ask what operating system you are on? I have repeated all your steps above and I could not reproduce the exception, so I am led to believe that the extra spaces you see may be a representation of the fzf prompt that is specific to your machine. In particular you can see from your recording above that, when nvim-possession saves the session, the path is correctly indicated to be exactly the location where the session exists (with no extra spaces). The exception occurs when the entry string is fed via the fzf-prompt.

What happens when you just invoke fzf (either fzf-lua per sé in neovim or fzf in the terminal)? My guess is that you would see the additional extra spaces there as well.

EmreDogann commented 1 year ago

Hmm, may I ask what operating system you are on?

I'm on Windows 11 using WSL 2 Ubuntu via Windows Terminal.

Invoking fzf in the terminal seems to be working fine: image

Invoking it in nvim using :lua require('fzf-lua').files({cwd = '~/.dotfiles', cmd = "fd --no-ignore --hidden"}) seems to be fine as well: image

I'm not sure, maybe somewhere fzf settings are being overridden? I did migrate from regular vim where I was using fzf.vim so maybe some weird stuff is going on there? The fzf.vim files and the previous vim install+config are still on the system.

gennaro-tedesco commented 1 year ago

Invoking it in nvim using

isn't there an additional white space between the icon and the first character of your first entry (local)? Anyway: I didn't try on Windows (as I don't have a Windows computer at hand), only on MacOs and Linux.

I will continue investigating, but unless I come across a Windows computer I cannot guarantee to resolve this quickly, unfortunately; apologies for that, I am trying to reproduce it but it just doesn't manifest on my machines. As a workaround you could use the "Telescope" setup (what of it didn't convince you? But also, I don't understand why it works in that case...), in the meantime I will try to ask the maintainer of fzf-lua to see if he is aware of a specific Windows behaviour that prompts extra white spaces.

EmreDogann commented 1 year ago

There's nothing wrong with the telescope preset, I just prefer the layout of the fzf/default preset. But thanks for the help, I will continue investigating and will provide updates here if I find anything.

gennaro-tedesco commented 1 year ago

Sorry that we couldn't resolve this yet - I will keep the issue open and keep you updated as well!

EmreDogann commented 1 year ago

Update:

I think your hunch about the whitespace and icons might be correct. I just tested it out with some of the other presets:

https://github.com/gennaro-tedesco/nvim-possession/assets/48212096/29f0e054-c062-45e6-9143-cbb0d198a09c

It seems that the telescope and max-perf presets work fine.

Looking at the fzf-lua README it seems that the icons might be the issue here:


Profiles

Conviniently, fzf-lua comes with a set of preconfigured profiles, notably: Profile Details
default fzf-lua defaults, uses neovim "builtin" previewer and devicons (if available) for git/files/buffers
fzf-native utilizes fzf's native previewing ability in the terminal where possible using bat for previews
fzf-tmux similar to fzf-native and opens in a tmux popup (requires tmux > 3.2)
max-perf similar to fzf-native and disables icons globally for max performance
telescope closest match to telescope defaults in look and feel and keybinds
skim uses skim as an fzf alternative, (requires the sk binary)
gennaro-tedesco commented 1 year ago

Ah, so probably both max-perf and telescope silently remove the space allocated to devicons, whereas the other defaults force a white space when icons are explicitly removed!

I would still expect it to work if you choose any other preset but manually set icons to false in your fzf-lua setup configuration. This said, great that we could make it work at the end!

EmreDogann commented 1 year ago

So it's not only file_icons in fzf-lua but also git_icons. Once i set those both to false in the fzf-lua config, it seems to work. With that being said, is there no way to set file and git icons to false only in nvim-possesion windows? It would be nice to have an option to display these icons in other windows. If not, then maybe this deserves an issue thread over on the fzf-lua repo?

gennaro-tedesco commented 1 year ago

With that being said, is there no way to set file and git icons to false only in nvim-possesion windows?

I do have such setup, have a look here: essentially you have to explicitly enable the git/file icons for the pickers you want instead of using presets; nvim-possession sets icons to false automatically, so you wouldn't have problems there. I presume that by using presets they somehow take over whatever other fzf-lua prompt there is, which is the reason why we saw those extra spaces in your example, and this shouldn't happen if you just configure the single pickers by themselves.

If you use (modifying at your will) my dotfiles as per link above you will exactly reproduce the setup as in the README :)

EmreDogann commented 1 year ago

Ok so modifying M.list() inside nvim-possession/init.lua to also disable git_icons like so:

---list all existing sessions and their files
    ---return fzf picker
    M.list = function()
        local iter = vim.loop.fs_scandir(user_config.sessions.sessions_path)
        if iter == nil then
            print("session folder " .. user_config.sessions.sessions_path .. " does not exist")
            return
        end
        local next = vim.loop.fs_scandir_next(iter)
        if next == nil then
            print("no saved sessions")
            return
        end

        return fzf.files({
            user_config = user_config,
            prompt = user_config.sessions.sessions_icon .. "sessions:",
            file_icons = false,
            git_icons = false,      <-------- Adding this fixed the issue
            show_cwd_header = false,
            preview_opts = "nohidden",

            previewer = ui.session_previewer,
            winopts = user_config.fzf_winopts,
            cwd = user_config.sessions.sessions_path,
            actions = {
                ["default"] = M.load,
                ["ctrl-x"] = { M.delete_selected, fzf.actions.resume },
            },
        })
    end

Fixes the issue for me, without having to disable any icons in my fzf-lua config.

If you use (modifying at your will) my dotfiles as per link above you will exactly reproduce the setup as in the README :)

Yeah I will definitely steal some stuff from there haha. I really like the look of your setup

gennaro-tedesco commented 1 year ago

...what if you open a PR with that fix, so that I can include it and we fix this once and for all? :)

EmreDogann commented 1 year ago

Sure thing!

Let me just finish up my nvim-possession setup to make sure nothing else comes up before the PR.

gennaro-tedesco commented 1 year ago

I have released a new version after merging the PR: updating the plugin via your plugin manager of choice should do and you should be able to see the error solved!

Thank you for your contribution!

EmreDogann commented 1 year ago

Yep just tried it out and everything is working as expected, thanks a lot!

By the way, it would be nice if you put in the README a link to the config to get nvim-possession looking like the gif in the README. I was a bit confused at first because my one looked vastly different.

gennaro-tedesco commented 1 year ago

By the way, it would be nice if you linked the config to get nvim-possession looking like the gif in the README. I was a bit confused at first because my one looked vastly different.

Do you mean the configuration to be found in my dotfiles?

EmreDogann commented 1 year ago

Yeah that could work

gennaro-tedesco commented 1 year ago

That is a good idea: I will try to clean it up a little and link the relevant bits! :)