Support for multiple terminals at once about vimteractive HOT 21 CLOSED

I already thought about that. It's seems to be easy to make a mapping buffer → terminal (and construct terminal buffer names dynamically).
Pros:

1. You can open any number of terminals painlessly, without sticking to filetype
2. It's quite easy to implement and it's intuitive behaviour

Cons:

1. You can't use two buffers with one term
2. You can't use two terms (e. g. python and ipython or clj and lein repl) with one buffer

from vimteractive.

The dynamic construction could also be made quite intuitive, e.g. it pins a buffer to the last terminal of the appropriate type that was opened.

It all depends on how much one thinks that cons 1 and 2 would actually affect users in practice. One could supply commands that allow users to change the terminal that a given buffer points to

from vimteractive.

I don't want to remember commands that allows me to change the terminal. Solution without sticking to types and instead with opening one terminal for a buffer maintains simplicity.

from vimteractive.

I do often want to send text from multiple buffers to the same terminal though (e.g. when I'm testing the combining of code from two different projects)

from vimteractive.

Maybe open a new terminal when doing :Iterm and provide some other way (:Iconn mb?) to connect buffer and terminal?
Mapping approach would handle that easily, but I'm not sure how one would specify buffer/terminal to connect. Using buffer names is easy to implement, but quite painful for user.

from vimteractive.

I quite like the idea of an :Iconn command, and given that switching connections is a pretty niche thing to want to do, I'm not too bothered about it being a bit clunky on account of using the terminal buffer name. Perhaps a better automatic naming scheme of terminals would make this easier (e.g. calling them something like python_1 python_2, clojure_1 etc.

The functionality that I think we're describing could best be summarised like this:

1. The first :Iterm opens a terminal and links the current buffers to that terminal
2. subsequent created buffers will link to that terminal too
3. A second :Iterm command opens a new terminal, linking the current buffer to that.
4. New buffers will be linked to the most recently opened terminal of the appropriate filetype (or just the most recent if no filetype exists)
5. You can change the terminal that the current buffer is pointing to by using an :Iconn <terminal_name> command

from vimteractive.

I don't like the idea of sticking to filetypes. E. g. I have my Python filetype bound to ipython and I explicitly started plain Python REPL with :Ipython. Then, when I open new Python file:

1. Vimteractive will look up for REPL for filetype python and will found that it's ipython.
2. There's no ipython REPL, so ^S will not work in new buffer.

This is quite unintuitive.

I suggest modify second step to be "subsequent created buffers will not be linked to terminal until explicitly linked" and think about convenient way to link them.

May be command! -nargs=1 -complete=buffer Iconn will be enough, but I'm thinking about some keybinding way, like entering :Iconn and then pressing j as in ^Wj. Or allowing both ways: explicitly pass buffer name as argument or running :Iconn without arguments and awaiting for key after it.

from vimteractive.

I agree regarding the unintuitiveness of having it autodetect terminals. In that regard we should also modify the first step so that it only links the present buffer.

It would be very neat to have the :Iconn command have autocompletion. I guess the intuition behind the ^Wj-esque approach would be that it's as if you're moving to the terminal buffer that's currently visible (and above the current buffer), although you could just have Iconn without any arguments link to the terminal that's currently visible.

from vimteractive.

I can have more than one terminal buffer visible, ^W-like chooser will work in this case.

from vimteractive.

OK, although for it to be intuitive you'd only be able to connect terminals that you could switch to with that motion e.g. it would make sense if you had a window split with two terminals open (e.g. here, normal buffer, Ipython buffer and python buffer):

so k would link the present buffer to the upper terminal and l to the right terminal

from vimteractive.

I think switching connections may not be that niche a thing to want to do - I'd use it and would not like to type entire buffer names. Autocompletion / ^W navigation sounds like a great idea!

from vimteractive.

Ok, I'll implement :Iconn with autocompletion and will think about ^W-navigation. I see possible implementation like this:

function! vimteractive#conn(terminal_buffer = 0)
    if !a:terminal_buffer
        augroup vimteractive_comm
            au!
            autocmd BufEnter term_* call vimteractive#cw_conn()
        augroup END
        execute! "normal! \<c-w>"
        return
    endif

    " really switching connections
endfunction

function vimteractive#cw_conn()
    augroup vimteractive_comm
        au!
    augroup END
    call vimteractive#conn(bufname('%'))
    wincmd p
endfunction

from vimteractive.

That sounds great @GoldsteinE . Many thanks for offering to do this, and your insightful comments in the discussion above. It's great to see other people making use of this package (which is integral to much of my research).

from vimteractive.

I encountered a problem.
We have this layout:

test.py is linked with term_python. When we starting :Iterm from test2.py, it becames this:

This is quite ugly, but I have no idea how to tell Vim «please, now make vertical split primary instead of horizontal split»

from vimteractive.

Are you able to graphically represent what you would prefer? I can see why vim would think that was what wanted to do, but I'm not sure what you would rather it look like. :help botright might be helpful

from vimteractive.

This layout would be much better, I suppose.

from vimteractive.

That layout can be generated if you start from a split window (test.py and test2.py), and then open terminals in each of the splits. I guess the issue arises if you have test.py and a terminal, then split test.py into test.py and test2.py before trying to create a new terminal.

I think this is an idiosyncrasy of the generic window splitting management of vim, rather than this package.

from vimteractive.

Yeah, it works that way, but it possibly would be cool if we could manage that.
Anyway, I do not see any way to do it.

from vimteractive.

I think we should stick to the 'natural', if undesirable behaviour of vim in this regard, and leave it to the pros who are able to manage windows effectively. Are we able to piggy back on the commands that create vertical and horizontal windows splits, so that the semantics are preserved?

from vimteractive.

We already using :split to create terminal windows and possibly we can let user choose between split and vsplit somehow.

Also, while working on this issue I added little new feature: when ^S pressed when term is not opened, a new term is created automatically for user. This can be disabled in .vimrc.

from vimteractive.

Also, while working on this issue I added little new feature: when ^S pressed when term is not opened, a new term is created automatically for user. This can be disabled in .vimrc.

That's a very nice touch. Happy for that to be the default.

from vimteractive.