* :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
head "https://github.com/tarruda/neovim.git", :branch => "builtin-terminal-emulation"
brew install --HEAD neovim
brew reinstall neovim
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.
Of course, if you use Vim, this looks great too! I just don't want anyone to be dissuaded from Emacs for this reason ;)
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.
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?
[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"
: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?
Test in vim (it works) and change the "[shift 8]" to <splat> (HN html renderer was swallowing the "[shift 8]")
(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.)
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.)
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.
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
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".
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 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.
As much as I like emacs, I think it's suffered from this very problem over the years.
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?
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.
Defaults enjoy privileged status.
| | 1 | | | 0 | 1 |
| 0 +---+ 3 | => |---+---+
| | 2 | | | 3 | 2 |
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.
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'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.
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 :)
Genuine question, why is it so great? any reason to switch to it?
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.
I recommend it, simply because it supports and promotes awareness of a really cool project. One that potentially could have significant gains.
Also, it's a bit faster (very noticeable with CtrlP).
OT, but why? what did you switch to, if anything?
I'd like something, but i'm in no rush to find it.