
Neovim now has builtin terminal emulation via libvterm - grimgrin
https://github.com/neovim/neovim/pull/2076
======
grimgrin
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

~~~
saidajigumi
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.

~~~
jmgrosen
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 ;)

~~~
saidajigumi
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!

------
xiaq
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](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.)

~~~
martanne
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](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/](http://www.brain-
dump.org/projects/dvtm/)

~~~
alandarev
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_".

~~~
martanne
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/](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.

------
new299
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](http://41j.com/hterm)) and via Emscripten to create a
web-based ssh client ([https://minaterm.com](https://minaterm.com)). It's been
very easy to work with in both cases.

~~~
andrewchambers
It looks great, though light on documentation.

~~~
new299
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).

------
je42
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 ?

~~~
fizzbatter
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 :)

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

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

~~~
lojack
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.

~~~
sigzero
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.

~~~
belak
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.

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

~~~
xvilka
Not yet
[https://github.com/neovim/neovim/issues/59](https://github.com/neovim/neovim/issues/59)

------
bstar77
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](https://www.youtube.com/watch?v=lH_zb7X6mZw)

------
sigzero
How is the Windows side coming along?

~~~
bjg
Builds and Runs apparently:
[https://github.com/neovim/neovim/pull/810#issuecomment-74986...](https://github.com/neovim/neovim/pull/810#issuecomment-74986872)

