search

tpope / vim-obsession

obsession.vim: continuously updated session files
http://www.vim.org/scripts/script.php?script_id=4472
1.76k stars 70 forks source link

Fixed an issue occurring when the path passed to :Obsession contains a symlink #9

Closed monokrome closed 10 years ago

monokrome commented 11 years ago

When passed a path including a symlink to obsession, expand will "fail" and return empty. To avoid this, you can check if the result file is empty and pass the result through fnamemodify instead.

This seems to have solved the problem.

tpope commented 11 years ago

I can't reproduce. Can you tell me an exact symlink structure that demonstrates the problem?

monokrome commented 11 years ago

After more investigation in #vim, I have figured out that it actually wasn't because of the symlink. However, I'm not sure why the problem exists. I can explain my current structure, however.

My configuration repository sets up a ton of my configurations as symlinks into itself. So, my $HOME/.vim folder is symlinked to $HOME/.c-old/lib/.vim where my configurations are. When I tried to do:

escape("~/.vim/sessions")

Since escape ended up failing, it therefore returning an empty result, which in turn caused :Obsession to think that it wasn't called without any arguments. However, this fix solves the problem and now the result ends up being the expected value of /Users/monokrome/.c-old/lib/.vim/sessions with it.

I tried fixing the issue with:

escape(resolve("~/.vim/sessions"))

The call to resolve solved the issue of resolving the symlinked path, but calling escape still resulted in an empty result.

Another instance of this issue being fixed can be found here if it helps at all.

mhinz commented 11 years ago

Apparently other people have the same problem and fix it by checking if a:file is empty, just after calling expand() on it:

https://github.com/chrisbra/SudoEdit.vim/issues/17

The help page says: "If the expansion fails, the result is an empty string". I never experiened that myself, though. The string he gave on IRC didn't contain anything that could be expanded, and just running :echo expand('string he gave') worked without problems, so I wonder why expansion would fail in this case.

expand() doesn't really look at the path it expands, so it shouldn't matter if it's a symlink or not. In sheer desparation we tried to copy(a:file) before expanding it, but it was no use.

To put it in a nutshell, I have no idea why the expansions fails and think that checking if the outcome of expand() is empty would be the best approach.

monokrome commented 11 years ago

@mhinz Are you saying that I did something differently than the best approach in my pull request? I don't mind fixing any issues that anyone has with it.

monokrome commented 11 years ago

Any updates on this?

monokrome commented 10 years ago

This problem seems to have been fixed sometime around 6 months ago, as I haven't seen it recently. Possibly in a Vim update? I'm closing the issue in regard to that.