Opening blank file second time about nnn.vim HOT 26 CLOSED

I see the following error at the bottom after third step:

!/bin/bash
nnn exited with -1

Both nnn and nnn.vim are latest master.

from nnn.vim.

Have the following in my .vimrc:

let g:nnn#set_default_mappings = 0
nnoremap <leader>n :NnnPicker '%:p:h'<CR>

from nnn.vim.

Please check if this issue is due to the exit code from the first instance of nnn.

from nnn.vim.

Even without the override in .vimrc (#30 (comment)) I am seeing this issue.

from nnn.vim.

@mcchrish any lead on this one?

from nnn.vim.

@jarun seems to be related to #17 and I'm actually experiencing it now. It maybe a related issue. It has something to do with the curwin: 1 option of vim and the default nnn#layout enew.

let s:term_buff = term_start([&shell, &shellcmdflag, l:cmd], {'curwin': 1, 'exit_cb': function(l:On_exit)})

The issue doesn't appear if it is set other than enew:

let g:nnn#layout = 'tabedit' " or others

So I think a work around for now is to change g:nnn#layout to tabedit as the default for vim (or topleft 80vnew seems to be more convenient). I'm not getting this issue in neovim.

However the above may not be related to your issue, as I unfortunately can't reproduce it. But can you try setting g:nnn#layout to something else if it fixes to you?

from nnn.vim.

If I remove all my plugins, I see the following behaviour:

I have file1 open in vim. On opening file2 using nnn.vim, when I close it, vim quits. I was expecting file1 to be left open. Is this the expected behaviour?

from nnn.vim.

If it's the correct behaviour, how do I keep the earlier file (file1) open?

from nnn.vim.

OK. You can reproduce the issue with https://www.vim.org/scripts/script.php?script_id=159.

This retains the earlier buffer/file1 and then I see the issue.

Please check.

from nnn.vim.

The plugin won't interfere with other buffers and always open a file as a new buffer. No buffers will be deleted. Running :buffers should list file1 and file2 in your use case.

from nnn.vim.

Did you face the issue with the plugin?

from nnn.vim.

It should not error out the second time I press leader n and open nnn in picker mode.

maybe the problem is there is no file open in the buffer and the plugin can't determine the dir to open?

from nnn.vim.

Didn't face the issue with the plugin. The only thing I can reproduce is #30 (comment). The second time I press <leader>n it doesn't open the nnn window. But when I change the value of g:nnn#layout to something else and seems to work as expected.

from nnn.vim.

Here's what I see: https://asciinema.org/a/219024

from nnn.vim.

My .vimrc:

let g:nnn#set_default_mappings = 0
let g:nnn#layout = 'tabedit'
nnoremap <leader>n :NnnPicker '%:p:h'<CR>

Output from messages:

:NnnPicker '%:p:h'
E79: Cannot expand wildcards
nnn exited with -1
Messages maintainer: Bram Moolenaar <[email protected]>
"src/nnn.c" 3770L, 87774C
E79: Cannot expand wildcards
"~/GitHub/nnn/src/nnn.h" 232L, 6434C
"src/nnn.c" 3770L, 87774C
E79: Cannot expand wildcards

from nnn.vim.

@mcchrish please let me know if there's anything else I can help you with. I understand you can't reproduce but please try to analyze what's going wrong so we can have a solution. The problem exists.

from nnn.vim.

I see this scenario working properly on Linux subsystem for Windows with vim 8.1. I will update the vim version on my de and confirm it.

from nnn.vim.

I update to v8.1 on Ubuntu. The issue still exists.

from nnn.vim.

OK, I am confirmed, nnn isn't even called the second time (first time is - file picked using nnn and quit) and somehow the plugin gets a -1 return value which is not from nnn.

I confirmed this by modifying nnn before calling it second time to return -5 immediately on open. The plugin still shows nnn returns -1.

@mcchrish please analyze this and see from where the plugin gets the value of -1 which is not from nnn (which is not even invoked the second time). If you need more details, please let me know when we can have a chat.

from nnn.vim.

This issue makes the plugin unusable for me.

from nnn.vim.

Thanks for the detailed information above. Sorry that the plugin is not working for you. I will be taking a look. I'd like to know more about some details of your system:

• OS: [e.g. macOS 10.14.2]
• Terminal: [e.g. iterm2 3.2.7beta2]
• Shell: [e.g. zsh 5.2.1, bash 4.1]
• Vim version: [e.g. neovim 0.3.2, vim 8.1 1-239]
• Plugin manager: [e.g. vim-plug, pathogen]
• Plugin version: master
• Nnn version: master

Do you see the issue with the nnn.vim plugin with or without minibufexpl installed?

from nnn.vim.

I'm able to replicate the issue with minibuffer 6.3.2 from vim.org.

I'm not sure how minibufexpl works but is there a particular reason you are using an outdated version? There is a forked and improved version here https://github.com/fholgado/minibufexpl.vim that seems to be working and I don't get the error.

Minimum vimrc that works:

set nocompatible

call plug#begin('~/.config/nvim/plugged')
Plug 'mcchrish/nnn.vim'
Plug 'fholgado/minibufexpl.vim'
call plug#end()

let g:nnn#set_default_mappings = 0
let g:nnn#layout = 'tabedit'
nnoremap <leader>n :NnnPicker '%:p:h'<CR>

from nnn.vim.

With this version, when I close the picked file using nnn, vim quits. Is this expected? I would expect the earlier file to be opened instead of vim quitting.

from nnn.vim.

I think that's expected with that version of minibufexpl. It seems to use only one window and doesn't override the :q command. To close a buffer without quitting vim run :bdelete or :bd.

from nnn.vim.

OK. Thanks!

from nnn.vim.

@mcchrish nnn v2.2 is released. If you think the plugin is stable enough please consider making the first release.

from nnn.vim.