Neovim now has builtin terminal emulation via libvterm | Hacker News Reader

Neovim now has builtin terminal emulation via libvterm

github.com

195 pointsgrimgrin48 comments

This will be used for :! and :shell commands.

* :term [prog/args] will open a new special buffer "connected" to a pseudo terminal running prog/args

* any command that would enter insert mode will focus the terminal buffer instead.

* when focused a new mode is entered where all keys are passed directly to the program. The <c-g><esc> combination will return to normal mode.

* new terminal-only mappings can be added with the "t" prefix(eg: tnoremap <c-a> <c-g><esc> exit terminal focus using ctrl+a)

Someone asked: "I really don't know how I would use this feature but it's impressive how well it works."

tarruda replies: "With time, the numerous use cases for this feature will be clear, but here's one idea: This allows another level of integration between text mode programs and Neovim. For example, we'll be able to make gdb respond to nvim mappings and change file/line numbers when a breakpoint is hit(Technically this might be possible with tmux but not without numerous hacks)"

If you want to try this out yourself and have installed neovim with brew, do this:

  brew tap neovim/homebrew-neovim
  brew edit neovim

At the top of the recipe, change the head:

  #head "https://github.com/neovim/neovim.git"
  head "https://github.com/tarruda/neovim.git", :branch => "builtin-terminal-emulation"

And then:

  brew install --HEAD neovim
  -or-
  brew reinstall neovim

On debugging, traditional vimmers might want to try Conque GDB: http://vim.sourceforge.net/scripts/script.php?script_id=4582

But honestly, even though I've kept this installed, it still feels foreign enough that I usually just run gdb (or cgdb) in a separate terminal anyway. If I ever make the jump to neovim, I'll be curious to see how much of a native feel can be given to things like this.

> when focused a new mode is entered where all keys are passed directly to the program. The <c-g><esc> combination will return to normal mode.

Is there a mode (planned) that would have local line editing? Something like having a buffer where you can compose your line and then send it to running program. Or can you do that already?

Not neovim tested (I'm an nvi user), but:

[editeditedit]; # <--- on an empty line

<command-mode on your crafted line> 0"ay$ ;# go to start of line, in a buffer named "a" yank to EOL

@a ;# <-- execute the buffer "a"

Example line:

:r!ls -ld <splat>^M

^-- enter ed mode, read contents of command "ls -ld <splat>"[enter]

Is that close (or adaptable?) to what you're thinking of?

EDIT: Test in vim (it works) and change the "[shift 8]" to <splat> (HN html renderer was swallowing the "[shift 8]")

This promises to be incredible for all of the use cases where folks currently remote-control tmux windows, etc. When considering things like debugger integration, this cracks the door to some features previously owned well only by GUI IDEs.

I think the killer feature here is not just terminal-in-vim, but the full emulation aspect. When I used to use Emacs extensively, I could never really get into eshell because it ignored terminal emulation. It was OK for some things, but mostly just threw a wrench in my normal shell workflows.

To note: Emacs supports full terminal emulation too, with `ansi-term`. It's a little janky switching between line/char mode, but I use it as my default terminal.

Of course, if you use Vim, this looks great too! I just don't want anyone to be dissuaded from Emacs for this reason ;)

Thanks for the info. It's been many years since I tried shell use under Emacs; I should have figured there'd be a better solution by now!

This is, of course, equivalent to curl | sudo sh in terms of security properties.

(Which is not a complaint; I'm pretty okay with curl | sudo sh, because I'm okay with so many other equivalent things, like this.)

This is another proof of how editors and terminal multiplexers should really be just one thing.

Editors are replicating terminal multiplexer functionalities - tabs, windows, and now with terminal emulation they have become terminal multiplexers. Terminal multiplexers are also replicating editor features (copy-mode of tmux, for example). Unfortunatly neither has reached a state to completely supersede the other - I always find vim's window-manipulating commands obscure, and copy-pasting with tmux is never as satisfactory as in vim. I suspect that such a state will never be reached, since both party are still keeping their narrow mindsets - vim still tries to remain an editor, and tmux still tries to remain a terminal multiplexer.

The world can benefit from something that is built as both an editor and a terminal multiplexer from the very beginning. There is acme (http://en.wikipedia.org/wiki/Acme_%28text_editor%29), but we need something slightly more elaborate and friendlier to the keyboard.

(There is also emacs, which is both an editor and a terminal multiplexer. But it is also a news reader, a web browser, and a million other things. Something that is "just" both an editor and a terminal multiplexer is probably better for the reset of us.)

"I always find vim's window-manipulating commands obscure. . . ."

What's obscure? I assume you're talking about the keys mapped to the commands, which can easily be changed to whatever you want them to be. Trivial. Other than that, the operations themselves just seem to be basic stuff, splitting windows, closing windows, moving between windows. The common and obvious manipulations.

Remapping default key commands is a fraught problem. Doing so acclimates the user to a custom environment which is not strictly a superset of the default environment. This makes it very difficult to switch to other environments and remain productive.

Defaults enjoy privileged status.

Personally as a developer (not a sysadmin), I choose to be more productive 99% of the time than eschew customizations because I might vim in remotely here and there.

I was referring to the commands to manipulate complex layouts. Take the following transformation for example:

    +---+---+---+      +---+---+
    |   | 1 |   |      | 0 | 1 |
    | 0 +---+ 3 |  =>  |---+---+
    |   | 2 |   |      | 3 | 2 |
    +---+---+---+      +---+---+

The tmux command to achieve this is "move-pane -s .3 -t .0 -v", which reads very natural once you know the options. "Move the source pane 3 to the target pane 0 by creating a vertical split in the target pane".

I then looked up windows.txt of the vim reference manual. In the window-moving section, we are given commands to rotate and exchange windows and move windows to the far left, right, top and bottom. So apparently I can achieve my goal by moving 3 to the far left, splitting 0 into 0a and 0b, exchanging 3 with 0a, and closing 0a. Which is why I always end up closing 3, splitting 0 into 0a and 0b and redo what I used to open 3 in 0b instead.

Also, how do you split 0 when you are in 3, without leaving 3? In tmux it is simply "split-window .0". Apparently there is no way to do that in vim...

Instead of consisting of a set of simple, powerful primitives, vim's window-manipulating commands are built from the perspective of special use cases. This makes these specific use cases easy but everything else hard. This is why I call them obscure.

Thanks, I see what you mean. However, I think 'obscure' is the wrong word. Tmux seems to have analogous commands for most of Vim's, mapped to keys for use just like Vim's; they're simply the usual commands many people use to move windows(vim)/panes(tmux) around.

The commands you mention (at least move-pane) are more flexible than Vim's window manipulation commands. That's the word I would use, 'flexible'. I think building a Vim plugin to emulate those tmux commands would be interesting project; I've put it on my list.

One last thing. I'm curious what tmux command(s) you would use to transform the layout above back to its original state. In Vim it's quite simple, with cursor in your window 3, just issue command ':winc L'. I don't see anything as straightforward with the tmux commands you've described, but I could be missing something.

I don't think terminal multiplexers are the same thing as editors at all. Arguing that tmux should just get bundled into an editor like neovim is dismissive of how great tmux is. I.e., It stands on its own, and it's doubtful that a well designed terminal multiplexer like tmux could've been created as a sidecar project for a larger editor app.

As much as I like emacs, I think it's suffered from this very problem over the years.

The fact that a terminal multiplexer can not be created just as a sidecar project is exactly the reason why it is better to build them as a whole. The editor does need a lot of terminal multiplexer features, and instead of letting them grow into a mess, it's better to do it systematically from the beginning.

To put it another way: If you are going to have an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp anyway, why not just have Common Lisp as part of the program when you start?

No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead detect that it runs within a terminal multiplexer and instruct it to create a new window. When I find the time I will try to experiment with this design in vis.

https://github.com/martanne/vis

As for the copy mode, in my opinion the multiplexer should use the editor as a filter (which requires that the editor uses stderr for its regular output). The whole scroll back buffer is piped to the editor and whatever the editor writes to stdout is kept around in a copy buffer.

That is the way it is implemented in the latest dvtm releases.

http://www.brain-dump.org/projects/dvtm/

Reusing one's functionality is amazing, but not always the best solution.

The example you gave is exactly this: imagine if your web-browser would create new windows instead of tabs. Why? Well, it would just let OS manage the tabs, afterall that is the main functionality of the Operating System.

Hardly everyone wants their vim to create a bunch of tmux windows messing up their workflow: constantly changing IDs of tmux windows; slow navigation between vim files as user now has to open ID 15 (tmux); mixed order... Oh that sounds as bad as seeing all your open websites in Meta/Alt+Tab.

So please, do not speak for everyone with arguments "vim shouldn't have its own window functionality".

There is uzbl-tabbed, which separates the browser proper from the tab manager. It is not the OS which manages the tab though, since most WMs don't support hierarchal layouts and having all websites along with other applications is quite a mess.

I have always wondered how smooth the workflow can be with a WM that supports hierarchal layouts and tabbing (e.g. i3wm) and having the browser always opening up windows, but I have never done that experiment.

If your window manager is not able to manage your windows to your liking, you might want to fix it? Arguably creating a new window per tab is the correct thing to do. This allows your window manager to do its job. It is also more flexible, for example you can use something like tabbed (http://tools.suckless.org/tabbed/) to group multiple applications into a tab-like interface.

As for the editor case, in dwm/dvtm lingo each editor instance (or filename?) would get its own (dynamic?) tag. Therefore you can easily switch to a view which only contains your editor related windows.

Again if your navigation among tmux windows is slow/cumbersome you might want to improve that instead of duplicating the functionality at another layer.

I think the goal we are trying to achieve are the same. Having the editor and the terminal multiplexer communicating with each other is basically a modular approach to the "editor and terminal multiplexer in one" idea, which allows you to combine the editor and the terminal multiplexer freely. However, such integration requires the editor to have specific knowledge of the terminal multiplexer, e.g. the editor needs to know that tmux uses the split-window command to split a window, and the -h and -v options (or similar knowledge on dvtm); any knowledge mismatch can lead to subtle interop bugs. Also, the editor might gradually evolve to require specific versions of the terminal multiplexer and that will make installation a bit more cumbersome. These are signs of very tight coupling.

So the idea is, if you are going to have unavoidable tight coupling, you might better build them as one piece of software from the beginning. That eliminates all interop issues automatically and since you designed the UI of the editor and terminal multiplexer as a whole, the user experience can be much more smooth.

Though I am pessimistic about the modular approach, I would still be very happy to see it implemented. I will admit your success if it turns out to be good enough :)

PS. I have looked at your vis before and having modern, alternative vi-like editors is always exciting! Though not quite related, I would like to invite to take a look at my modern, alternative shell: https://github.com/elves/elvish

libvterm is really awesome and a very powerful library it's great to see it getting more use.

I've previously used it for a graphical terminal project (http://41j.com/hterm) and via Emscripten to create a web-based ssh client (https://minaterm.com). It's been very easy to work with in both cases.

Don't know if you're aware, but the naked domain (https://minaterm.com) is not working, while https://www.minaterm.com is.

It looks great, though light on documentation.

Thanks, yes at present both projects are mostly proof of concepts. I'd want to see if they gain any general interest before putting much more time into them and improving documentation (and to be frank general quality of the code).

whats the status of neovim at the moment ? has it reached a level such that you can use as an editor on a daily basis ?

I've been using entirely Neovim for around 4 months now. The only issue i experienced was two plugins (out of many) that had slight issues. One was an issue with Powerline, and i forget the other. Note that i had wanted to get rid of powerline anyway, so i didn't bother trying to get it to work.

As a side effect, various things seemed to become much faster, such as Vundle installs. I assume this is due to some async work, but i never really looked into it, so this is very anecdotal.

Overall it's been a seamless transition. I haven't even bothered to keep up to date with the repo master, simply because it has worked so well i haven't needed to.

Really enjoy this project, can't recommend it enough :)

> Really enjoy this project, can't recommend it enough :)

Genuine question, why is it so great? any reason to switch to it?

One of the big reasons is it has multithreading. So, you know when you have a plugin that's doing something and the whole editor locks up so you can't do anything... with NeoVim there's a way to prevent that from occurring.

I tend to avoid plugins so that really has never happened to me. I can see how that would be annoying to those that do though.

Additionally, neovim has gone through a huge code cleanup. Something vim will not do because they want to maintain infinite backwards compatibility.

Many old builds have been dropped and a number of important things have started using libraries (libvterm just an example of this). In theory this won't change the functionality, but may, long term, improve stability.

It's also nice that we aren't relying on one person to keep the project going. Bram is very dedicated, but when his response to "How can the community ensure that the Vim project succeeds for the foreseeable future?" is "Keep me alive", that doesn't say anything great about the project.

belak (author of dead sibling post to this one), FYI, you appear to be hellbanned.

I had many SIGABRT with my vim config under the hideous non-posix Terminal.app. Sometimes a SIGSEGV. With neovim, gone. Never had any.

Also, it's a bit faster (very noticeable with CtrlP).

Ah yea, CtrlP too, heavily!

Well, i suppose i'm recommending it because of the future. Currently, it has some advantages sure, but perhaps it's not enough to "care" about. I mean, it's easy to install and could potentially be a drop in replacement, but you may not care about even bothering to install it.

I recommend it, simply because it supports and promotes awareness of a really cool project. One that potentially could have significant gains.

Are you using it purely in the terminal? Is there any form of gvim functionality yet?

Purely in Term edit, no idea about Gvim

No gvim that I know of. However, it has a different philosophy there. The UI will be swappable. It will just embed neovim.

> Note that i had wanted to get rid of powerline anyway, so i didn't bother trying to get it to work.

OT, but why? what did you switch to, if anything?

Its very heavy. I've been using airline for the last year or so. https://github.com/bling/vim-airline

Can't recommend Airline enough. It's functionally equivalent to Powerline, without the added burden of having to use Python in the background.

I switched to nothing. In the future i'd like to enable something, but Powerline was always a bit messy and performance intensive (using it in both vim and tmux). I just got a bit tired of it.

I'd like something, but i'm in no rush to find it.

Overall quite usable. I have been using it for a couple of months and I haven't had any major issues with it. There are some slight differences in cursor behavior between vim and nvim but I got used to it.

Does neovim support 24 bit color themes for terminals which support it like Konsole?

Not yet https://github.com/neovim/neovim/issues/59

Has anyone played with Atom NeoVim? That looked like the most promising gui based approach. I'm sticking with macVim in the near term, but I'd love to play with Atom.

https://www.youtube.com/watch?v=lH_zb7X6mZw

How is the Windows side coming along?

Builds and Runs apparently: https://github.com/neovim/neovim/pull/810#issuecomment-74986...

Reply on news.ycombinator.com