Use one instance for nnn or remember nnn paths

[kyoz]

Is your feature request related to a problem? Please describe.

After select a file with Enter. nnn close and everything is reset when we reopen nnn again, everything is reset to default current path, see below gif:

Describe the solution you'd like

It's more convenient if nnn.vim can use one instance for nnn. Or at least remember the current path of nnn.

Like i have 2 buffer which splited

| buffer 1 | buffer 2 |

When i was in buffer 1, open nnn and goes to folder test/buffer1/test1.js
And in buffer 2, open nnn and goes to folder test/buffer2/test2.js

When i reopen nnn in those buffers. It should open the current path of that buffer. If it can remember path of each context [1][2][3][4], it's the best.

That's just my idea. How do you guys thinks. I'v just a lots of files manager for vim. nnn is the fasted but it lack some convenient features.

Minimal vimrc

call plug#begin('~/.config/nvim/plugged') "---------------------- Start vim plug

Plug 'mcchrish/nnn.vim'

call plug#end() "---------------------------------------- End of Vim-Plug define```

Versions

OS: macOS Mojave 10.14.1
Terminal: Alacritty
Neovim: Latest
nnn: Latest
nnn.vim: Latest

[hujianxin]

it will be wonderful if there is a nnn buffer and it keeps everything I have entered

[jarun]

If it's possible, it has to be done in the plugin. nnn itself doesn't track any user details.

[hujianxin]

@jarun thanks for you replying, I got your meaning

[khuedoan]

I'm using this key binding which opens nnn in the current buffer's directory, not a replacement for remembering path but may fit your use case:

nnoremap <C-n> :NnnPicker %<CR>

[kyoz]

@khuedoan ya. Sometime when i need to use nnn, i have call command with some args my self too 😄

[jarun]

nnn now supports sessions. See options -s/-S. Option -s is probably better suited to have a specific session for the plugin.

@mcchrish @mizlan it this doable now, perhaps with an nnn.vim flag/setting that says enable session management?

[mizlan]

Sure! I'll work on this. Also, this seems like an approach we can use to simulate a classic directory viewer. That would entail reopening an nnn process with the session every time a file is chosen. We can probably do better with some change in nnn later but that's a workaround for now I guess.

[mcchrish]

https://github.com/mcchrish/nnn.vim/blob/master/doc/nnn.txt#L149-L159 with this option, it should be possible to make use of sessions right away. They can pass any file they want for example:

" create a session that is tied to the current vim session
let g:nnn#command = 'nnn -s ' . tempname()

Another possibility is to tweak nnn#pick() to accept a command option, example:

call nnn#pick('~/some-files', { 'command': 'nnn -s '. tempname() })

Which is probably the most flexible direction.

[mcchrish]

Also, this seems like an approach we can use to simulate a classic directory viewer. That would entail reopening an nnn process with the session every time a file is chosen.

Seems like a possible direction if stdout option doesn't work out #43.

[mizlan]

There are some annoying things with the way sessions currently work in upstream nnn. Namely, you cannot load a non-existent session name and have it created with nnn -s <new_session_name>. I am currently fixing this (was this behavior intentional?) and will push to nnn soon.

Please let me know if you do not happen to experience this issue. To be specific, you will see an open failed message in the nnn echo area for 1 second after opening nnn with a nonexistent session.

[mizlan]

Actually, I am understanding sessions incorrectly. I think it would be less suitable to call them "sessions" since they are more like "snapshots" that can be arbitrarily loaded and saved. What we would need is an option for named sessions to be saved on quit. All that needs to be done is to take the existing code for auto-saving the @ default session and modify it for named sessions. However, we'd also have to either:

1. introduce a new program option to specify whether sessions should be "replaced" on quit.
2. make a breaking change that changes the meaning of sessions from "snapshots" to more like real "sessions".
3. (this is the one I think makes the most sense) modify the behavior of -S so that if both -s <name> and -S are provided, then it will persist (auto-save on quit) to the named session. If only -s <name> is provided, then load session initially but do not save on quit. If only -S is provided then use the default @ session. Edit: However, the drawback of this approach is that you cannot load a session and then persist to @ session later on...

I am currently working on making the third choice here work.