Comments (21)
I already thought about that. It's seems to be easy to make a mapping buffer → terminal (and construct terminal buffer names dynamically).
Pros:
- You can open any number of terminals painlessly, without sticking to filetype
- It's quite easy to implement and it's intuitive behaviour
Cons:
- You can't use two buffers with one term
- You can't use two terms (e. g.
python
andipython
orclj
andlein 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:
- The first
:Iterm
opens a terminal and links the current buffers to that terminal - subsequent created buffers will link to that terminal too
- A second
:Iterm
command opens a new terminal, linking the current buffer to that. - New buffers will be linked to the most recently opened terminal of the appropriate filetype (or just the most recent if no filetype exists)
- 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:
- Vimteractive will look up for REPL for filetype
python
and will found that it'sipython
. - 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.
Related Issues (20)
- backspace (in insert mode) frozen after having sent lines to interactive program HOT 1
- Send results back HOT 3
- Possible errors in autoload/vimteractive.vim HOT 8
- Send selected text to Ipython console HOT 1
- neovim compatible? HOT 4
- Three issues with respect to user-friendly HOT 3
- Vertical split HOT 3
- Buffer name choice causing error. HOT 2
- The plugin can't recognize existed console HOT 1
- No new line on windows HOT 3
- Can't backspace up to previous line in Insert mode HOT 3
- Can't use ctrl-s in visual mode HOT 2
- +terminal HOT 1
- Prevent automatic scroll on switching splits HOT 3
- feature request: wolfram support HOT 3
- Sending cell of code HOT 2
- Interactive plotting broken
- run vimscript commands interactively
- Filetype recognition shell
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vimteractive.