vifm.vim icon indicating copy to clipboard operation
vifm.vim copied to clipboard

Vifm.vim remains opened in a hidden buffer after running `vim <DIR>` and picking a file

Open intelfx opened this issue 1 year ago • 2 comments

Description

There seems to be a usability issue with vifm.vim w/embedding + netrw replacement.

When vim is started as vim <DIR> directly into a vifm.vim buffer, after picking a file vifm.vim does not terminate and remains in a hidden buffer. Thus, when I edit the file and attempt to exit Vim via :q, I get an error:

E947: Job still running in buffer "vifm: edit"

If I then pick another file, the embedded instance does terminate. ISTM that it should do so in the beginning as well.

Environment

intelfx avatar Jun 22 '24 12:06 intelfx

Thanks for the report. There is clearly an issue. Vifm does terminate after picking a file, otherwise nothing would get opened in Vim, but Vifm is started again in a new buffer right after that.

xaizek avatar Jun 28 '24 08:06 xaizek

Vifm does terminate after picking a file, otherwise nothing would get opened in Vim, but Vifm is started again in a new buffer right after that.

Ah, right. I described the user-visible effects :-)

intelfx avatar Jun 28 '24 10:06 intelfx

Hi. Similar issue here. I noticed the same: vifm does keep a hidden buffer opened (although i do not experience the same problem as op).

Ive tried to troubleshoot and this is all ive got:

function! data.on_exit(id, code, event) abort

"-------------------------------------------------TROUBLESHOOT
            let term_buf_to_delete = bufnr('%')
            echomsg term_buf_to_delete
"-------------------------------------------------------------------

            if (bufnr('%') == bufnr('#') || !bufexists(0)) && !self.split
                enew
            else
                echomsg 'Before swaping: ' . bufnr('#')
                silent! buffer #
            endif
          echomsg 'After swapping, before deleting: ' . bufnr('#')
            silent! bdelete! #
            echomsg 'After deleting: ' . bufnr('#')
            if self.split
                silent! close
            endif
            if self.cwdjob != 0
                call jobstop(self.cwdjob)
            endif
            call s:HandleRunResults(a:code, self.listf, self.typef, self.editcmd,
                                  \ self.snapshot)

"----------------------------------------------TROUBLESHOOT
            if bufexists(term_buf_to_delete)
                "echomsg term_buf_to_delete
                echomsg 'The buffer keeps existing. Its number is ' . term_buf_to_delete
                bdelete! term_buf_to_delete
            else
                echomsg 'Buffer does not exist. Number: ' . term_buf_to_delete
            endif
        endfunction
"-----------------------------------------------------------------------------------------

In the last function, the silent! from delete is removed. It's kinda weird because I enter the if statement and I even get the message 'the buffer keeps existing' but then I receive the error of the non silent bdelete.

Any updates on this? I really like this plugin.

pascualpobil avatar Sep 26 '25 16:09 pascualpobil

I think I've figured it out. Try using bwipeout instead of bdelete. Since :bdelete doesn't actually remove the buffer, but just makes it harder to access, it probably remains recorded as an alternative buffer and closing the first instance of Vifm ends up processing the same paths again (because directories are handled on BufEnter event).

xaizek avatar Sep 26 '25 17:09 xaizek

I've tried with bwipeout but it behaved the same.

Im so mad i cant fix it cause this is the best file manager by far.

pascualpobil avatar Sep 26 '25 21:09 pascualpobil

Updates. I managed to get terminal vifm inside a floaterm wrapper.

With these settings ive got it exactly as i had it before:

autocmd FileType floaterm setlocal nonumber norelativenumber
let g:floaterm_opener = 'drop'
let g:floaterm_wintype = 'split'
let g:floaterm_position = 'botright'
let g:floaterm_height = 0.7

command! Ffm silent! FloatermNew vifm 
nnoremap <leader>vh :Ffm<CR>

The issue of buffer replication does not happen this way.

pascualpobil avatar Sep 27 '25 00:09 pascualpobil

Sorry, I wasn't clear enough, the place where bwipeout makes difference over bdelete is in https://github.com/vifm/vifm.vim/blob/91d50ba57da96e0bd467ecb768914573d09d770d/plugin/vifm.vim#L496-L503

xaizek avatar Sep 27 '25 08:09 xaizek

I let the previous chunk as it was originally and modified just the one line 503 of the snippet you referred to.

I don't know if i'm misunderstanding again, for it does not work for me.

pascualpobil avatar Sep 27 '25 11:09 pascualpobil

Weird, for me using bwipeout makes :ls! print only a single buffer in both Vim and neovim and the OP's issue is completely resolved. I'll push the fix and close this, feel free to create a separate issue if the problem won't go away for you after that.

xaizek avatar Sep 27 '25 16:09 xaizek