ap / vim-buftabline

Forget Vim tabs – now you can have buffer tabs
http://www.vim.org/scripts/script.php?script_id=5057
MIT License
782 stars 75 forks source link

Fix dictionary error #23

Closed joshuarubin closed 7 years ago

joshuarubin commented 7 years ago

tab.tail was empty in an edge case with vimfiler where I was opening a directory that was a symlink and pwd was unrelated to bufname.

ap commented 7 years ago

Thank you for reporting this and attempting a fix. I’m afraid I can’t apply the patch though, because it just suppresses the error without fixing the problem. (The problematic buffer is left without a label and does not participate in disambiguation.)

Looking at the code again, I don’t know why I have fnamemodify() make it relative to the working directory. If you make the following change, does it correct the problem you’re encountering?

-           let bufpath = substitute(fnamemodify(bufpath, ':p:~:.'), '^$', '.', '')
+           let bufpath = fnamemodify(bufpath, ':p:~')
joshuarubin commented 7 years ago

Unfortunately that does not fix the issue. It happens with commands for editing directories when vimfiler is enabled (not for netrw) :e ~/.vim/

:echo fnamemodify('~/.vim/', ':t') returns an empty string for example

as a result, the following sets tab.tail to an empty string let tab.tail = fnamemodify(bufpath, ':t')

ap commented 7 years ago

But if the buffer name is an actual path to a directory on disk – meaning that isdirectory(bufpath) yields true –, then suf will be set, and the following line will chop off the trailing directory separator, which will then prevent an empty tail string:

if strlen(suf) | let bufpath = fnamemodify(bufpath, ':h') | endif

That’s what should be happening. Which of these assumptions is breaking down in your case?

(Is this 100% reproducible with vimfiler? If not, what steps do I take to reproduce it?)

joshuarubin commented 7 years ago

The problem is that bufpath at this point in my example is ~/.vim/ and isdirectory("~/.vim/") returns an empty string due to the ~, only the fully expanded path works.

ap commented 7 years ago

Aha! OK, things make more sense now.

So… does bufname() return a full path? (I think it always does… but am not certain.) I.e. does applying this patch fix your problem?

        if strlen(bufpath)
+           let suf = isdirectory(bufpath) ? '/' : ''
            let bufpath = substitute(fnamemodify(bufpath, ':p:~:.'), '^$', '.', '')
-           let suf = isdirectory(bufpath) ? '/' : ''
            if strlen(suf) | let bufpath = fnamemodify(bufpath, ':h') | endif
joshuarubin commented 7 years ago

Yes, that fixes it. Thanks!

ap commented 7 years ago

Great! I’ll be pushing a commit with an equivalent change soon.

joshuarubin commented 7 years ago

Great thanks!

ap commented 7 years ago

There you go, plus a whole bunch of other small fixes and optimisations coming along for the ride. Share and enjoy. 😊