Invalid directory error when invoking <plug>(dirvish_up) from Vim terminal

[lifepillar]

Possibly related to #127. To reproduce, open Vim, then open a terminal (:terminal), go to Normal mode and type - (or whatever mapping for <plug>(dirvish_up) you have). Instead of opening the file browser, Vim displays:

invalid directory: '!/bin'

NeoVim works as expected under the same circumstances. Using Vim 8.1.0650 under macOS.

[lifepillar]

Forgot to mention: :Dirvish works as expected (and is my current workaround). The issue occurs only when using the plug.

[justinmk]

I think Vim doesn't have the term:// scheme in the buffer name. We could check the 'buftype', I guess ... can you see if that works? Probably requires a few lines of ugly code.

[lifepillar]

echo bufname("%") returns only the command (e.g., !/bin/bash), so expand("%:h") is !/bin; buftype is set to terminal in both Vim and NeoVim, so that likely the way to go (but in older versions of Vim, IIRC, buftype was not set in terminal windows, so there may be backward compatibility to take into account).

I think that Dirvish should open getcwd(): this will do it (in plugin/dirvish.vim):

nnoremap <silent> <Plug>(dirvish_up) :<C-U>exe
  \ 'Dirvish '.(getbufvar('%','&buftype') ==# 'terminal' ? getcwd() : '%:p'.repeat(':h',v:count1))<CR>

I still get the “invalid directory” error (also in NeoVim now), but the file browser is opened. Besides, <plug>(dirvish_up) is defined also in ftplugin/dirvish.vim. And everything should work with counts, too (the above doesn't). So, there is a bit of work to do…

[yzlnew]

Got invalid dir error when starting with gvim . on Winodows.

[CrispyDrone]

I actually get dirvish: E37: No write since last change

[justinmk]

I actually get dirvish: E37: No write since last change

er... what does :echo &modified say?

[CrispyDrone]

I actually get dirvish: E37: No write since last change

er... what does :echo &modified say?

1

But, it makes sense to me because in the vim documentation, it says:

So long as the job is running the window behaves like it contains a modified
buffer.

Just to be clear, this is not something I ever encountered before. I came across an issue where I wanted to use ctrlp from a dirvish buffer. It would preview the previous file instead of start a ctrlp search. In my search, I just happened to stumble on this and I got curious what it was about. I managed to fix my original issue by disabling the filetype mapping (as described in the documentation).