integrated terminal #372
This is a feature request/discussion.
I'm wondering what the opinion is on an integrated terminal in Oni? I'm using neovim at the moment and the
Are you planning on supporting terminal integration, and if so, how do you plan on integrating this? I'm not sure how the terminal on windows works for example.
To my knowledge, it works almost the same as neovim, though I've found it a little difficult compared to the neovim one (though I've been using that one for years, so any change is noticeable).
The only real difference in launch is that for whatever reason,
if has("windows") && ! has('nvim') set shell=C:\Windows\Sysnative\wsl.exe set shellpipe=| set shellredir=> set shellcmdflag= endif
Thanks for starting this discussion here, @tcoopman ! Had some thoughts on this - it's a good time to share them out and get some feedback.
I agree, it's a useful and critical feature to have!
There were three high-level pieces I was thinking about in relation to this:
VSCode and Vim/Neovim have different user experiences when it comes to managing terminals.
In Vim/Neovim, the terminal is essentially a buffer in a window split - and can be arranged in relation to other splits. This is part of why it can be a replacement for tmux.
My preference for the user experience would be to keep the Vim/Neovim model of terminals-in-splits, because I believe this is more flexible and allows the same metaphors for navigating between. But open to ideas.
Implementing a terminal emulator is tricky! There are so many termcodes that you need to recognize and handle. Both neovim and Vim use a library called
Having an abstraction where you can send the raw terminal output to a library like
VSCode, on the other hand, uses
For our implementation, we'd want to use a native library like
However, an open question at the moment is how much can we leverage the
The question that remains to be figured out is - what is the right layer to hook in?
At one extreme - we could use as much of Vim's architecture for
Still some time needed to investigate the best strategy for hooking this feature up. It'd be nice to reuse as much as possible from
As a tangent - one project I would be interested to see - and would be a great fit for Revery today - would be a stand-alone terminal (like Hyper, but built with Reason/Revery) - could have a fast, cross-platform terminal on this stack IMO. Might help answer some of these questions!
Lastly, even though my plan would be to use
This API is documented here:
The API basically lets the extensions listen to events about the terminal (when a terminal is opened, closed, resized, takes input, etc), and also allows the extensions to spawn processes against a terminal. I believe this API would map to our implementation - even if we put the terminals in splits vs VSCode's model of terminals-in-the-bottom-pane.
It's very nice to see you have thought this through in detail already. I don't have that much feedback at the moment about the technical parts, but here is what I think about this:
I agree 100%. The terminal placement in vscode is very limited. Having them as buffers in whatever place you like is really powerful.
Well, seeing that it's a goal to be compatible with VSCode plugins this will be important indeed. Looking at the API it doesn't seem that hard though to support most/all of those things.