On Sun, Jul 2, 2017 at 3:46 PM, Bram Moolenaar <Br...@moolenaar.net
> For a long time I have been wondering whether it would be a good idea to
> add a terminal emulator inside Vim. It's a dangerous thing, it can
> easily grow out of proportions and be a maintenance nightmare. At the
> same time, it can be very, very useful.
> The reason I've wanted this is to debug Vim over an ssh connection. I
> have a nice setup locally, but when I'm not at home I always suffer from
> many limitations, which usually means I postpone the debugging until I'm
> home again. There are plugins that offer some of this, but debugging
> Vim requires running it in a terminal.
> Another reason... wait: TWO reasons to want a terminal emulater are:
> 1. For debugging.
This doesn't seem like a very good reason. You should be able to debug
a program remotely, but you'll still be running the debugger on the
machine running the debugged program. How are you currently debugging
> 2. Properly be able to run external commands in the GUI. This has been
> in the todo list for a long time. Even ":!less file.txt" doesn't
> work properly.
This is a fairly good thing to want but I'm not sure adding a terminal
emulator to Vim is the way to accomplish this. It's possible to rather
accurately detect the terminal emulator in use on Linux and then
launch it (if not, it could be a variable). On Windows, it might be a
good idea to call AllocConsole and then write to it.
While potentially more annoying than some alternatives it seems like
it might be okay if they were expecting the new window.
> Also,... wait, wait, wait; THREE reaons for a terminal emulator are:
> 1. For debugging.
> 2. For running external commands in the GUI..
> 3. For running tests with a remote controlled Vim. The current test
> setup allows for a lot, but there are still tests where the test
> script and the test itself interfere. With a terminal window the
> test is able to run Vim, send it keystrokes and check for the
> expected output. This is only possible with a built-in terminal
I know quite a bit about UI automation. What is it that the tests need
to do and how do they currently do that? I only ask because I don't
understand how the setup you described is prevented from doing what it
needs to do by the lack of a terminal emulator, although something may
need to be done differently for the GUI version (as it doesn't run in
a terminal emulator).
> And it fits in with.... WAIT! Among the reasons to add a terminal
> emulator window are such reasons as:
> 1. For debugging.
> 2. For running external commands in the GUI.
> 3. For running tests with a remote controlled Vim.
> 4. Run a job conveniently on all platforms and interact with it. Allows
> for jobs that prompt the user, keeping an eye on progress, etc.,
> without the need to start another xterm or console window.
> Some may say that this invites users to run a shell in a Vim window,
> which is not what an editor should be doing. That's true. But one can
> actually already do this with a job that is connected to a buffer. I
> haven't heard much complaints about that. We do need to set priorities,
> supporting the above mentioned reasons is the most important.
> I am currently exploring using libvterm for the implementation. It
> looks like this will work. Still a lot of stuff to implement, which
> might not work that well, we'll have to see. I hope to send out an
> initial patch soon, we can discuss more then.
Most of the very bad reasons I could give are mitigated by using
libvterm, so as far as I know there's no grave reason you should
completely avoid adding terminal emulation to Vim. I can, however,
attest that it will be quite a bit of work even with what libvterm
If adding a terminal emulator solves all of the reasons given in an
elegant enough fashion then it makes sense to go forward with it
despite the issues I brought up. Unfortunately, things like #2 and #4
when on Windows seem like "pretend to be Cygwin" which sounds like
project creep so massive it is actually impossible to accomplish.
Getting around those two issues seems like it is generally
accomplished by installing Cygwin. I'm not sure how that solution
interacts with gVim, but it sounds like it is avoided - throughout my
use of Vim there have been many suggestions to use it inside of Cygwin
when on Windows.
My conservative response to points #1 and #3 is likely due to my
background with Linux. I see no reason why those things should be
added to Vim merely because they exist elsewhere and adding them would
take effort which could be spent doing something else. On Windows the
situation may be different (I currently know of no way to do those
things without using Cygwin), but on some level I think it needs to be
acknowledged that there will be operating system differences that may
not be reconcilable inside of Vim.
P.S. I'm actually rather startled to learn that neovim has a built in