feat: keep nnn open

[PartyLich]

Is your feature request related to a problem? Please describe.
Coming from more graphical editors and IDEs, I'm used to having a file explorer open all the time.

Describe the solution you'd like

Using netrw in nvim I can get roughly equivalent behavior:

Is it possible to do this with nnn instead?

Describe alternatives you've considered
Seems feasible to pass the file list back to vimscript on some bindable keypress and then process it as usual. I dont have the familiarity with nnn or vimscript to implement it myself atm.

[mcchrish]

Seems to be a popular request to have a nerdtree like persistent session/window. #55
#43

It might be possible to implement this features by communicating with nnn via stdout. I don't have much free time to implement it, but I welcome anyone who wants to submit a PR.

[PartyLich]

I think #43 and #55 are different from my request in that they expect nnn to close, but want the open directory to persist/be remembered.

• Naively, if we have access to the path currently visible in nnn, perhaps it could be stored in a script variable (again, im not versed in vimscript).
  For Use one instance for nnn or remember nnn paths #43,

  "When i reopen nnn in those buffers. It should open the current path of that buffer."

  sounds to me like getting the current head (something like expand('%:p:h')) and using it as the l:directory in nnn#pick(...), if the command is called without its own directory argument.
  A little playing around with setting a g:nnn#last_dir sort of works, but perhaps there's a more suitable scope for this sort of thing. I tried setting it in s:eval_temp_file, and that setup causes nnn to open to the dir of whichever file is opened, which in my brief test was the last item selected. That approach doesn't really involve nnn at all, so I imagine there's some case(s) where it doesnt behave as desired.
  I also just realized that this wasnt default behavior; my vim config is set to change the cwd to the open buffer (autocmd BufEnter * lcd %:p:h), so nnn always opens to the buffer directory for me without any plugin modification.

  "remember path of each context [1][2][3][4], it's the best."

  sounds like Persistent nnn session for a vim session #55 and using nnn's session options as that issue's poster suggests.

My personal desire is to have nnn stay open and visible. I'm not asking the plugin to store session data at all, so as I understand the requests in those other two issues implementing them wouldn't give me the behavior I want.

Perhaps I'm just not (yet) adapted to a vim-centric workflow. When I can see the dir tree, i tend to structure around that tree. As I've been using nvim primarily the past few weeks, I've found myself creating a lot more gigantic files and trying to navigate within files instead of between files.

In any case, I understand that your time constrained, and I'll continue looking for other solutions/workflows/etc

[vhristev]

Im also interested in NNN persistant pane. You describe it very well like NerdTREE no matter if you open the file the File Browser do not close after opening the file.

[vhristev]

Still nothing about that. It would be very helpful to have persistent pane.

[mizlan]

Please be patient.

Anyway, taking a look over this, the first thing I question is, when a file is selected from the nnn file explorer, which existing window should it replace in case there are multiple? Should it be the window that was in focus before focus transferred to the nnn window? And if the nnn window is the only open window, should it open in a vertical split of some sort?

[mizlan]

Since nnn (not nnn.vim) only writes to the picker file on exit, there is currently no way to use a persistent nnn window to navigate files and open corresponding files as buffers. One possibility I can foresee is nnn "flushing" to the picker file on some event/keypress, or some variation where there is an option where <Enter> can flush to the file without quitting the process. The issue, however, is that you would need to poll the file at a very quick interval (not optimal) or, if possible, something like kqueue within Vim, but I doubt it is doable.

[mizlan]

It might be possible to implement this features by communicating with nnn via stdout. I don't have much free time to implement it, but I welcome anyone who wants to submit a PR.

@mcchrish This is an interesting idea, but could you elaborate a tad more? I have never quite thought about a curses process communicating via stdout. I guess it would be an alternative to the picker file, maybe -p - with Vim waiting for input.

[jarun]

I think what the user is looking for is, nnn should not quit when files are picked using Enter and should stay put in the original buffer where it was opened.

[jarun]

User provides the picker output file and whenever she acts (presses Enter on a file), nnn writes to it. No need to keep watching.

[mizlan]

I guess we can have some keybind that is intercepted before it reaches nnn. But this would not interact with the picker file. Or if it would, Vim, would essentially act as a middle-man for the keybind.

[jarun]

Yes, it seems so. We would need to change the behaviour of nnn closing when files are picked.

So maybe a switch or something.

[mcchrish]

It might be possible to implement this features by communicating with nnn via stdout. I don't have much free time to implement it, but I welcome anyone who wants to submit a PR.

@mcchrish This is an interesting idea, but could you elaborate a tad more? I have never quite thought about a curses process communicating via stdout. I guess it would be an alternative to the picker file, maybe -p - with Vim waiting for input.

Exactly -p - will output the selected files to stdout. And aside from exit callback, vim/nvim also accepts stdout callback that can handle stdout events, :h termopen().

However, nnn -p - exits after selection. nnn probably should have an option to not exit and just rather clear the selection after pushing them to stdout.

[mizlan]

I think we would need to use the stdout method since Vim must communicate with nnn first, them nnn communicates back with Vim.