2017-07-02 23:46 GMT+03:00 Bram Moolenaar <[email protected]>: > > 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. > > 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. > > 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 > 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.
Debugging and tests can actually be easy to achive if you take libvterm and Python with pexpect, I did that for powerline. (Though Neovim with a “remote UI” based on msgpack is far more convenient setup for most tests, excluding testing specifically terminal UI and not just a supposed screen state, we have some of them which use Neovim run inside a :terminal inside a Neovim which exports screen state via its RPC API.) 4 also, but there is a big difference between making Python “build time dependency needed for a subset of tests” and “runtime dependency needed for a set of plugins”. The interesting thing is that despite Neovim has built-in terminal emulator which allows creating special terminal buffers (I do hope you will look at that before implementing your own variant), support has never gone far enough to use it for `:!`, though after `:!` in Neovim started to work through pipes and stopped displaying colors or working with interactive apps correctly this feature started to be rather desired. Scripting interaction with such buffers is possible both via “switch to buffer and do :normal” and “use jobsend()” (obviously, second variant is best practice most of time). > > -- > "Oh, no! NOT the Spanish Inquisition!" > "NOBODY expects the Spanish Inquisition!!!" > -- Monty Python sketch -- > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
