Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminal becomes a separate (unsplit) buffer after closing a secondary buffer #40

Closed
khughitt opened this issue Mar 18, 2016 · 6 comments

Comments

@khughitt
Copy link
Contributor

I'm not sure if this is an issue that relates more to Nvim-R or Neovim itself, but I thought I would describe here first in case you have some insights.

The problem occurs whenever open a new file after opening an R console is already open. When I then close the buffer associated with the new file, the terminal which was previously split screen becomes a separate buffer and the split goes away altogether.

To reproduce:

  1. Open a file "test.R" in nvim
  2. ,rf
  3. :e test2.R
  4. :bd

Neovim version: NVIM v0.1.3-350-gc94575f

@jalvesaq
Copy link
Owner

After :bd, the terminal becomes the only visible buffer. This is what I expected. If I split the window again (<c-w>s) and open test.R again, I can keep sending lines and other commands to the R buffer. If instead of splitting the window again, I quit R, then test.R is displayed. I think this also is what is described by

:help :bd

If buffer [N] is the current buffer, another buffer will be displayed instead.

@khughitt
Copy link
Contributor Author

In that case, can you think of any work-around to preserve the split even after a buffer is closed?

I would much rather use the native Neovim terminal if possible, but the behavior of tmux with respect to the console is much more ideal: since the console was completely separate from Vim, :bd could be used to close buffers, and switching between buffers did not including the terminal window like it does in Neovim.

@jalvesaq
Copy link
Owner

Sorry, but I don't know how to do what you want. Currently, the terminal buffer is already started as a new buffer and not simply as a split of the script buffer. We have this in R/nvimbuffer.vim:

silent below right new

If you can found a sequence of Vim commands that does what you want, I can implement the procedure in the plugin. For example, to get the current behavior, the sequence of Normal mode commands is:

:below right new
:terminal R

If you can't get the desired behavior, you may want to open an issue in Neovim, requesting the new feature. But if indeed it is necessary to change Neovim, the change will not be trivial.

I like the way that Neovim terminal works, and I guess that if it was exactly like Tmux, Neovim developers would not have been motivated to develop it.

@khughitt
Copy link
Contributor Author

Thanks for the suggestions - I think perhaps I just need some more time to get used to working with the Neovim terminal.

Do you often use multiple buffers along-side of the R console? If so, are there any strategies that work well for you?

In the meantime, I found vim-bufkill which get's me most of the way to the behavior I am used to.

@jalvesaq
Copy link
Owner

When I need to open another buffer, I almost always use :tabnew because I prefer each buffer occupying the whole screen.

@khughitt
Copy link
Contributor Author

Ah okay. In my case I often use knitr child documents to break up analyses into modular chunks, so when I open one of them in a new buffer, I usually still want to run commands from them in the console.

In case anyone else finds it useful, here are a couple other init.vim tweaks which make the terminals behave more like they did in vim-r + tmux:

" Use vim-bufkill to preserve splits when closing buffers
cabbrev bd :BD
map <C-w> :BD<cr>

" Automatically enter insert mode
autocmd BufWinEnter,WinEnter term://* startinsert

" Exclude from buffer list
autocmd TermOpen * set nobuflisted

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants