2017-07-03 1:34 GMT+03:00 R0b0t1 <r03...@gmail.com>: > On Sun, Jul 2, 2017 at 3:46 PM, Bram Moolenaar <b...@moolenaar.net> wrote: >> >> 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 > Vim? > >> 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 >> emulator. >> > > 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 > provides you. > > 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. > > R0b0t1. > > P.S. I'm actually rather startled to learn that neovim has a built in > terminal emulator.
There is a very limited terminal emulator in GVim. AFAIR the main reasoning behind adding terminal emulator into Neovim were exactly GUI and making things more uniform: the “very limited terminal emulator” does not even support colors, it is only as good as “create pty and set $TERM to dumb”. And, BTW, Neovim is planning on making its terminal emulator work on Windows, and this has nothing to do with cygwin. Basically “terminal emulator on Windows” means one of two things or both of them combined: 1. Escape codes interpreter. Easy to achieve, you just work exactly like on linux, the only problem is the differences between starting Windows and linux processes, but that is covered by libuv. Despite the fact that “terminal escape codes ‘language’” is full of legacy, interpreter for it is smaller then interpreter for VimL. 2. Emulator which is able to somehow receive and interpret [Windows console API][winconapi]. This is far harder, totally different from unix escape sequences … and already covered by winpty which is able to do the translation. I am not sure what you would need as a dependency, but [PR which adds support for terminal on Windows][neovimpr] uses no new third-party packages for building and just lays its hands on [winpty-agent.exe][wpty-agent] (711K in [MSVC 0.4.3 release][winpty-0.4.3] which is the largest among the variants) and [winpty.dll][winptydll] which is 625K. This is not much by the modern standards, especially given that you need Qt as second most mature Neovim UI aside from lua UI used for testing is nvim-qt (first is built-in terminal UI which is *nix-specific). And yes, [that PR][neovimpr] means that Windows Neovim is going to have :terminal support. [wpty-agent]: https://github.com/neovim/neovim/pull/6383/files#diff-7abbb8315fea3e74ba20ce24ac297519R429 [winptydll]: https://github.com/neovim/neovim/pull/6383/files#diff-7abbb8315fea3e74ba20ce24ac297519R443 [winpty-0.4.3]: https://github.com/rprichard/winpty/releases/tag/0.4.3 [winconapi]: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx [neovimpr]: https://github.com/neovim/neovim/pull/6383 > > -- > -- > 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 vim_dev+unsubscr...@googlegroups.com. > 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
