Repository navigation
feat: keep nnn open #61
Description
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.
Reacted by Mario Ortiz Manero, Varac, Wesley Rodriguez Kronmiller, Omar Zeghouani and Miroslav Cibulka
Activity
[-]Keep nnn open[/-][+]feat: keep nnn open[/+]mcchrish commentedon May 26, 2020
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 commentedon May 26, 2020
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,
sounds to me like getting the current head (something like
expand('%:p:h')) and using it as thel:directoryinnnn#pick(...), if the command is called without its own directory argument.A little playing around with setting a
g:nnn#last_dirsort of works, but perhaps there's a more suitable scope for this sort of thing. I tried setting it ins: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.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 commentedon Jan 25, 2021
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 commentedon Mar 14, 2021
Still nothing about that. It would be very helpful to have persistent pane.
mizlan commentedon May 18, 2021
Please be patient.
Anyway, taking a look over this, the first thing I question is, when a file is selected from the
nnnfile 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 thennnwindow? And if thennnwindow is the only open window, should it open in a vertical split of some sort?mizlan commentedon May 18, 2021
Since
nnn(notnnn.vim) only writes to the picker file on exit, there is currently no way to use a persistentnnnwindow to navigate files and open corresponding files as buffers. One possibility I can foresee isnnn"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 likekqueuewithin Vim, but I doubt it is doable.mizlan commentedon May 18, 2021
@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 commentedon May 18, 2021
I think what the user is looking for is,
nnnshould not quit when files are picked using Enter and should stay put in the original buffer where it was opened.jarun commentedon May 18, 2021
User provides the picker output file and whenever she acts (presses
Enteron a file),nnnwrites to it. No need to keep watching.mizlan commentedon May 18, 2021
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 commentedon May 18, 2021
Yes, it seems so. We would need to change the behaviour of
nnnclosing when files are picked.So maybe a switch or something.
mcchrish commentedon May 18, 2021
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 commentedon May 18, 2021
I think we would need to use the stdout method since Vim must communicate with nnn first, them nnn communicates back with Vim.
jarun commentedon May 18, 2021
Sure!
mizlan commentedon May 18, 2021
I would love to help make the
-p -feature work, and I am working on getting familiar with thennncodebase. Do you have any ideas on which specific parts of the source code need to be changed?jarun commentedon May 18, 2021
You'll have to follow the
pickervariable. Give me a day, I am getting rid of the other variable.jarun commentedon May 18, 2021
Done with the change at jarun/nnn@2bd72d1.
Now you can follow the
pickerandpickedvariables.pickersaysnnnshould write selection to picker output file/stdout before exit.pickedsays some files were picked by a plugin.mizlan commentedon May 18, 2021
I've tested it on both Vim8 (
out_cb) and Neovim (on_stdout) and the issue is that for both of those, their callback prints a part of the buffer every time I move around thennnbuffer with escape codes and all, not a separate stdout channel like I'd expect.My only change to
nnnwas to comment out line 6290:https://github.com/jarun/nnn/blob/2bd72d1b29d968204421e9a479bc1c159a9dc490/src/nnn.c#L6290
which is probably incorrect for most purposes but was just a test.
My logging output looks like this:
Maybe the help page for
:h job-out_cbfor Vim will be useful:Emphasis mine.
I suspect I may be doing something wrong, but I do not know how to proceed.
mcchrish commentedon May 18, 2021
I'm trying some experiments a bit and see if might be helpful. I'm using neovim 0.4.4 and nnn 4.0.
A small vimscript to test out:
I'm getting the same result:
But if you take a look at the end, the selected files are found in the output:
It just seems like nnn outputs some other UI data/escape codes to stdout.
If I changed
termopencommand with a simple echo:The output is simply:
If I try using ranger, I'm met with a similar output as nnn:
So it looks like this is just how curses programs deal with stdout?
And finally I tried running nnn again but this time with the option
'stdout_buffered': v:true(see::h channel-bufferedin neovim):Where I get a single list as output:
This looks like something that we can parse where the items in the list are the actual selected files outputted by nnn except for the first item. The first item is a string containing escape codes and the first selected item at the end of it.
This could be something that can be work on for now but I hope there is something from the nnn or neovim side that could make it easier.
Note that I have not tried nnn with the jarun/nnn@2bd72d1 patch yet and only tried neovim.
I hope this will be of help.
mizlan commentedon May 18, 2021
Thank you so much! Not sure if we should proceed with the
stdout_bufferedidea since I don't think Vim8 has an equivalent.Have you considered the possibility of having
-poutput to a FIFO (named pipe)? I do not know too much about how this works but I suspect it may be easier.mcchrish commentedon May 30, 2021
I'm not that familiar with named pipes and I look at some usage from other plugins and it looks promising.
https://github.com/vifm/vifm.vim/blob/dbe8050b137341e70ea9cf95194803b674144530/plugin/vifm.vim#L205-L237
We could create a named pipe where nnn picker will pipe the selected files to then vim/nvim runs a job that waits and reads (via stdout callback) from that named pipes.