
Vim 8.0 is coming - mrzool
https://github.com/vim/vim/blob/master/runtime/doc/version8.txt
======
pvinis
I have vim, neovim and emacs (and spacemacs) installed. Right now I'm trying
to get into emacs a bit more.

What's interesting to me, and the reason I try to keep up to date with the
latest changes for all four editors, is that it's been now, what, 25 years (?)
since emacs and vim started "competing" and they still are. I guess we could
be saying the same in 10 years about firefox and chrome, but it still is
amazing in my opinion. It's amazing that so much work has been done to vim and
emacs, and so many changes, so many users using them for different things. And
there is still no clear winner. I'm not trying to start a discussion about the
strenghts and weaknesses of each. Just expressing my appreciation.

Thank you for your great work, to everyone involved with vim and emacs, and
more recently neovim and spacemacs. You are awesome.

~~~
pjmlp
I became an heavy Emacs user as I could not find the comfort of Borland IDEs
in UNIX, as I started to use it.

Since I moved away from C++ into Java and .NET land, never felt the need to
use them any longer.

And nowadays, with Qt Creator, Clion, xCode, AppCode and VS, I also don't feel
the need of them when I need to go back to C++.

It is very good to know the basics from plain Vi, because there are still
commercial UNIX systems without GNU tools installed, just bare bones
installations.

So for me the question is why there are still people that enjoy working as if
their computers are using a 25 year old developer experience.

~~~
tambourine_man
_So for me the question is why there are still people that enjoy working as if
their computers are using a 25 year old developer experience._

The GUI paradigm is over 30 years old. People still stick to the mouse even
though we've had ubiquitous touchscreens for almost a decade.

A good paradigm does not easily die.

~~~
coldtea
> _The GUI paradigm is over 30 years old. People still stick to the mouse even
> though we 've had ubiquitous touchscreens for almost a decade._

Touch screens are not a 100% replacement for mice. They are an alternative,
and for desktop/laptop PCs with vertical screens they are a non starter due to
human physiology.

~~~
cicero
Mice are not a 100% replacement for keyboards. If you're doing lots of typing,
there is something to be said for keeping your hands on the keyboard. Vim and
emacs facilitate this much better than GUI-based editors.

~~~
coldtea
> _Mice are not a 100% replacement for keyboards._

And they're not used as such. They are used as complimentary to keyboards.

On the other hand, mice-based GUIs ARE a 100% replacement for CLIs.

~~~
ubertaco
_> On the other hand, mice-based GUIs ARE a 100% replacement for CLIs._

Really? I can automate a pipeline of GUIs? Please show me how I can
automatically query a database, take that output, run complex data aggregation
over those results combined with past results, send that to a remote server
for storage, and email myself the result of the upload, using only a
combination of GUIs.

(Points deducted for anything that involves instructing the machine to "move
mouse to position (x,y)", since screen sizes may vary and where an individual
GUI chooses to pop open a dialog/modal may also vary)

~~~
adrianN
AppleScript can do pretty complex GUI automation tasks.

~~~
ultramancool
Yeah, so can AutoIT or python with pywinauto... you could do it. It just
wouldn't be pleasant. Might do it if you had to extract data from some
proprietary GUI tool you couldn't tear open.

------
ecthiender
To list few of the new features: Asynchronous I/O support, channels (Vim can
now exchange messages with another process in the background asynchronously),
Background jobs, timers, packages for plugins!

Wow! This is huge. So many interesting features landing on Vim 8.0.

~~~
andrewstuart2
Async I/O, plus JSON is seriously enormous. I'm very excited for how much
faster things will be, and I can imagine JSON support will definitely make
integration just that much easier. My one minor gripe was plugin speed, as
syntax highlighting, linting, etc. can take long enough to be jarring.

~~~
userbinator
Async I/O? In a _text editor_ , where the bulk of the time is spent waiting
for the user to do something?

I've used (an older version of) Vim on huge 100MB+ files and never thought it
to be slow at all. In fact I don't think I've ever experienced any lag with
Vim. I suspect you won't find this new version any faster.

~~~
chronial
This is in fact fixing a massive pain point in vim, and one of the main
reasons why NeoVIM has so much support. Saving a file in vim takes 1-2 seconds
for me. Not because my disk is slow, but because I run some linters on my
files, that take that long to all complete.

Async I/O is not about disk I/O, but communication with other programs.

------
octref
I have a mixed feeling as a NeoVim user and long-time Vim user.

On the one hand, great to see such a huge release for Vim that brings so many
features people have been begging for. Especially Async IO and JSON.

On the other hand, I hope Vim just become more stable and performant while not
introducing new features. At the same time, I hope more development could go
into NeoVim, and more people could start using it and writing plugins (not in
Vimscript) for it. I want Vim to be my backup editor -- always there and
reliable, and Neovim my working gear -- great features, joy to use, could have
a few bugs that don't affect my workflow too much and are a natural result of
fast-paced development.

I know this sounds really unfair to Vim devs. I'm sorry! I really appreciate
the works you've done to make Vim amazing. But I feel for me, I just want to
spend 95% of my time on one editor. Now I'm on the NeoVim boat, I feel like
having completely switched my workflow to Atom from ST3, and just learned ST3
is going open source.

~~~
nerdponx
I'm not a NeoVim user, but I've been on the edge of becoming one for a while.

What I'm still holding out for is an _embeddable_ NeoVim. The thing I really
don't like about IDEs is that I love my Vim configuration but I never get to
actually use the damn thing since I do most of my work in an IDE. Now imagine
if the IDE could actually just embed NeoVim, and I could use my Vimrc as-is
with all the plugins (now managed natively). I know they already have
Electron-based UIs for NeoVim, and Electron-based IDEs, so hopefully it's just
a matter of time.

That said, does this actually put NeoVim _behind_ in terms of feature parity?

~~~
Tyr42
I think neovim is embeddable?

I'm pretty sure SolidOak just embeds neovim:
[https://github.com/oakes/SolidOak](https://github.com/oakes/SolidOak)

------
maxaf
I alternate between Emacs and Vim every 5 years or so. Emacs gave me superior
customizability using a "real" programming language: elisp. Vim, on the other
hand, offers a faster, more efficient editing UX. The older I get, the wider
the spread becomes between the speed of my thought and the rate at which I can
input editing commands into the terminal. Vim allows me achieve higher
efficiency and to almost "think ahead" by quantifying my movements and jumping
to specific tokens in known locations. That to me has become more important
lately than scripting in a nicer language than viml.

All of the new features of Vim are super nice, but I'll still primarily use it
for the terseness of its editing UX.

~~~
jen20
You may want to consider looking at Evil mode, which gives you a very close
approximation to the vim editing bindings in emacs. I've been using it as part
of the spacemacs distribution for a while now and find it to be the best of
both worlds.

~~~
Gonzih
Evil mode is slower than vim. And also you are in evil mode only during the
editing phase. All other menus drop you back to default emacs keybindings and
that is very painful experience. I used evil mode for a couple of years and
still just went back to vim.

~~~
mightybyte
I have not found this to be the case with Spacemacs. Almost everything you
need is bound to keystrokes using space as the leader key in the spirit of
vim. As a long-time and fairly advanced vim user I recommend Spacemacs highly.

~~~
maxaf
Don't you feel like you're pushing a square peg into a round hole? Or do you
actually find yourself taking advantage of elisp in harmonious combination
with Vim's editing UX?

~~~
chm
I thought the same thing as you at first, as I was a vim+pathogen user. My
workflow was working properly but to me it's just much simpler to do a SPC-f-
e-d, add 'git' to my packages, then SPC-f-e-R and voila, git support is
installed.

I'm sure I'll go back some day but for now Spacemacs is perfect for my use
(i.e. writing small software, not large projects).

------
userbinator
_Dropped the support for MS-DOS. It was too big to fit in memory._

This is a little surprising since the latest version of Emacs still supports
MS-DOS[1]. If anything, you'd expect Vim to be the smaller and faster choice
but it seems this isn't the case anymore...

Then again, I don't really understand the culture of all the
customisation/plugins/etc. around text editors; part of the reason why I
originally chose Vi(m) over Emacs on Unix-like platforms is that it's small
and simple, and perhaps I don't expect or need much from a text editor in the
first place since I used MS-DOS Edit[2] as my main text editor for many years
and on Windows I'm perfectly content to use Notepad. I use the CLI for more
advanced text manipulation.

[1]
[https://www.emacswiki.org/emacs/EmacsForDOS](https://www.emacswiki.org/emacs/EmacsForDOS)

[2] [https://en.wikipedia.org/wiki/MS-
DOS_Editor](https://en.wikipedia.org/wiki/MS-DOS_Editor)

~~~
hollander
My head turned around. I read it like Vim loads MS-DOS, and I thought, why
would it do that? But then it occured to me dat this means Vim can run under
MS-DOS. It's been so long since I've used MS-DOS as OS, I can't imagine it
anymore. To me it's just a program that is run by another something.

~~~
justinmk
Vim _cannot_ run under MS-DOS. It hasn't worked for years, that's why Neovim
removed DOS support 2 years ago. The cries of "losing compatibility" were
uninformed fear/uncertainty/doubt.

Vim also doesn't run on OS/2 and other platforms, though the Makefiles have
not yet been removed.

------
codemonkeymike
Been using Neovim for about 6 months now, The only real difference I have felt
so far is that I was able to remove a few lines from my .vimrc, like
history=10000 as Neovim does this by default. As for Vim, I am done with it
forever, not because of vim more because of package managers compiling vim
without paste mode or lua/ruby support and making me compile vim from source
with my own flags, which was a harrowing experience for me, when I was just
trying to set up my development environment.

~~~
aorth
Do you ever have to vim somewhere where there is no nvim? Like on a server,
etc? I worry about getting used to nvim features or behaviors that might not
be compatible with vim (are there any?) and being super bummed on a server
some day!

~~~
codemonkeymike
Others have provided good answers but I'll add my 2 cents. Neovim was made to
be fully(Mostly?) backwards compatible with all Vim specific features, and
most Vi features. You may be wondering what is missing, some ed features and
support for some more obscure Operating Systems. You shouldn't have to worry
about the missing features as they are mostly legacy features that mostly all
new/newish users of vim never will use. As for additional features they are
mostly all under the hood, better embedablility, extensibility, and sensible
defaults things you don't need when editing your Appache routes on the server.

------
ikawe
> Plugins keep growing and more of them are available then ever before. To
> keep the collection of plugins manageable package support has been added.
> This is a convenient way to get one or more plugins, drop them in a
> directory and possibly keep them updated. Vim will load them automatically,
> or only when desired. See |packages|.

Is this going to replace pathogen?

~~~
majewsky
Pathogen: Most likely. Vundle: Probably not.

------
nickysielicki
And... there goes a lot of energy to neovim.

The only other feature request I have is expanded features for window drawing
for plugin makers. I want to be able to draw over a buffer without editing the
text.

If you've ever used jedi-vim, you'll see the function's signature appear above
the line you're editing. What a lot of people don't realize is that is
actually modifying the file and saving the prior contents of that line in
another process. If you kill vim and recover from the swapfile, that line is
gone... It's a dirty hack for a feature that people want-- scratch buffers
suck for this purpose.

I'd be happy with either having function signatures formally tacked onto
omnicompletion, letting omnicompletion providers do function signatures
cleanly, or having arbitrary text-display over a buffer as a standalone
feature, phasing out omnicompletion pumenu.c for this generic interface-- and
omnicomplete would have to be rewritten to use this interface.

~~~
jbmorgado
From what this initial view of Vim 8.0 looks, it actually went in the
direction of Neovim, the asynchronous inner works were what made me try Neovim
in the 1st place.

Now, from what I can understand, Neovim only has two advantages, a cleaner
code trough re-writing (it's debatable if that's really an advantage) and the
ability of using other languages for plugins (which seems clearly and
advantage due to the lacking features of VimScript).

All in all, it's a nice step forward for Vim.

~~~
Spiritus
Don't forget true color support for those sweet colorschemes!

~~~
jbmorgado
True, forgot that one and it's really cool to be able to use Neovim in the
console without breaking my head over the colorscheme.

It's a very overlooked feature that has a great positive impact in usability.
Been talking in a bug thread spacemacs about this same problem for months and
there is still no solution to be seen.

------
_pmf_
This release is a poster boy example why competition is good.

Before neovim: Asyncronous operations? "Absolutely impossible"

After neovim: Asynchronous operations? "Why, of course, here, with a cherry on
top"

------
stewbrew
Can somebody tell whether the API for those features also in neovim is
compatible to vim8? Anyway, it's great to see that neovim provoced new
developments in vim.

~~~
oblio
Not really.

------
d33
By the way, I have a question: what is the best learning material for
intermediate/advanced Vim users? I know quite a lot of Vim features but apart
from vimtutorial, I never learned them in any organized way - it was more of a
bunch of tricks I found via googling. It would be nice if there was a book
(preferably free) on this editor.

~~~
zwarag
I make a list for things I know would be faster if I knew them and go on.

example of my vimimprove.md:

\- 5 deleting word while curser is in the middle of that word

\- 2 insert parantesis around the word im on

....

when something reaches 10, I google it and write it on a note. Then the first
thing I do in the morning is doing that thing 10 times. Before I leave work, I
do it again. And of coarse if you use it while working you might just have it
in your muscles or you look at your little note. Then after a while your
finger get that ninja stile of doing stuff you brain just things about.

Like ying and yang

~~~
arnsholt
Since I happen to have the answer to both of those:

`daw` and `diw` deletes a whole word (unlike `dw` which only deletes forward).
They differ in what they do with whitespace; `aw` also trims trailing
whitespace (or leading whitespace if there's no trailing) while `iw` leaves
the whitespace alone. These two are text objects that can be combined with
other commands and quantifiers, so that `yaw` copies a word without deleting
it, or `d2aw` deletes _two_ words.

Wrapping in parens requires the vim-surround plugin, but with that installed
you can do `ysaw(` and `ysaw)` to wrap in parens (also works with brackets and
curlies and such), either with spaces inside the parens (the former) or snugly
around the word (the latter).

~~~
aidos
If I want to put parens around a word I do, ciw()<ESC>P (change word pulls it
into the default register, insert the parens and then paste from the register
back between the parens).

You can use the same pattern for any selection you have visually highlighted,
such is the wonderful power of vim.

~~~
thomasahle
Nice use of the buffer. Is there a nice hack to remove the parentheses around
a word as well?

~~~
aidos
I guess you could do a similar thing: ci(<backspace><delete><esc>p

------
teamhappy
Does vim have a roadmap/milestones or anything like that (i.e., anything that
allows me to track the development process)?

~~~
oblio
A document? Nope. You'd have to lurk on the mailing list.

------
nachtigall
Why is there just 1 contributor listed at
[https://github.com/vim/vim](https://github.com/vim/vim)?

~~~
LukeB_UK
It looks like the author takes patch submissions and applies them, rather than
pull requests being merged. Detailed in:
[https://github.com/vim/vim/blob/master/CONTRIBUTING.md](https://github.com/vim/vim/blob/master/CONTRIBUTING.md)

~~~
Sir_Cmpwn
Wow, that's pretty lame. No one gets attribution for their work.

~~~
maaarghk
He does put the name of the contributor in the commit message.

~~~
Sir_Cmpwn
Ah, you're right. I only looked at a few patches in the log:

[https://github.com/vim/vim/commits/master](https://github.com/vim/vim/commits/master)

And most of them don't have a name.

------
greenspot
Async is massive. I have been using this feature heavily in NeoVim for the
last 6 months.

I am surprised that nobody mentioned this: Bram (Vim's author) was in the
beginning very much against async in Vim and this was one of the main reasons
that the NeoVim fork started.

6 Months later Bram comes up with tons of features and one which he heavily
opposed.

Anyone know why this change of mind? The fear of Neovim or did I miss
anything?

------
ed_blackburn
With the age of their respective codebases, I'd love to know what lurks
beneath? Immaculate, well factored code? A hornets nest of hacks - what do you
expect from such old codebases - or have they been re-written so many times
you'd never guess their ages from the codebase.

~~~
ageofwant
Pfft on immaculate, well factored code. All glory to battle hardened code that
does the business everyday.

Of course it would be better to have both. But don't dismiss code that
survived the withering infernos of real world use. All those edge hacks are
there because they probably need to be.

~~~
ed_blackburn
I completely appreciate that. 'Tis always a case of striking a balance. Even
battle hardened code with countless edge-cases can be well factored. A system
programmer whose opinion I trust greatly recently advised me to look at the
postgress code for well factored, battle hardened code. I've heard others
suggest that libgit2 is similar. I don't feel confident / qualified enough to
comment.

------
donkeyd
I'm quite a noob at 'nix, so I tend to use nano whenever I need to edit
something. Not sure if this is the right place, but could somebody explain the
added benefit of spending the time to learn to use vim/emacs? I've tried vim,
but it seems very complicated.

~~~
nZac
The added benefit for me are, staying in the terminal where I do more than
just edit, normal mode makes file navigation and text manipulation an
extension of thinking, fast file switching, cross platform consistency, and a
low maintenance burden (though the initial learning curve/setup is steep).

I work on Python apps all day and am constantly running she'll commands,
interacting with git, starting / stopping services. Along with tmux, I can
switch projects incredibly fast without having to wait for an IDE to load.

If you don't interact with text most of the day, I am not sure Vim is worth
the curve.

------
Walkman
What does it mean to NeoVim? Does it affect it's development, split developers
or anything? Is it good?

~~~
llimllib
I have to think it's a direct response to neovim, and that competition between
them is likely to be very good

~~~
icholy
The reason neovim was started was to add these exact features. Now that vim
has them, I think neovim's work is done. Mission accomplished.

~~~
akkartik
Replace Neovim with Chrome, Vim with Firefox. Does your argument still stand?

Starting up a competing project has a _huge_ cost. Once started, it's
overwhelmingly better for the world for the competitors to continue[1], so
that they can continue to make each other accountable.

[1] Unless one of the competitors is able to subsume the other. Like EGCS
subsumed GCC back in the early 2000s. Total victory is a valid emergent
outcome of competition, not somebody deciding what 'should' happen.

------
melling
I've been trying to evaluate the different editors.

[https://github.com/melling/EditorNotes/blob/master/vim.org](https://github.com/melling/EditorNotes/blob/master/vim.org)

To me it feels like the vim key bindings are more efficient for programmers.
No one has ever done a scientific comparison, and it always seems to end in a
religious war, but we should do a better job of evaluating our tools. Then
hopefully, we can improve them.

~~~
majewsky
The problem with evaluating editor efficiency is that you are more likely to
measure the user's proficiency. The vim editing style is only as efficient as
the number of motions that you know. (I use about half of them actively, but I
have a lot of vim users sitting around me that barely know "w".)

So to really compare efficiency of, say, Emacs vs. vim, you will first need to
find two users. One who is as proficient in Emacs as the other is in vim. Good
luck with that. :)

~~~
todd8
Yes, but there are a number of people that have gone though periods of using
one and then the other. I have, at least anecdotal, experience with both.

I worked on the first release of AIX for IBM. Their lawyers took a couple of
years to get comfortable with the Emacs license so I switched to using vi for
two or three years. (At one point I had to demo a Lisp system running on AIX
at at AAAI conference and I could barely work the built in emacs-based
editor.) Eventually, I was able to switch back to Emacs on AIX.

My own preference is Emacs for it's breadth of features and its
customizations, but I still miss the feeling of speed that I had while
navigating source code with Vi or Vim. I still toy with Vim every so often,
but I've forgotten so much that I just plod along. Spacemacs is currently on
my system, but I usually prefer my own set of customizations and just stick
with Emacs and its ordinary bindings. Nevertheless, Spacemacs is an work of
genius.

I'd encourage everyone to learn basic vi (say what's taught in the tutorial),
it's everywhere. After that, IMHO, either of these ancient editors is
wonderful and worth adopting.

Someday I'm hoping that a new Emacs will be developed built along the lines of
Neovim. Digging into the internals of a big Emacs package is pretty painful
for me when all I am doing is trying to fix some aspect of my editing
experience (see [https://xkcd.com/1205/](https://xkcd.com/1205/)). I'd like a
more modern extension language than elisp. While I'm dreaming, someone please
rewrite LaTeX to use a real programming language instead of its Turing
complete macro language.

------
zxcvcxz
Has anyone ever run :help iccf?

Remember to donate to uganda guys it's the only thing Bram asks for in return
for this software.

------
wellsjohnston
Best thing to come out of this is async support.

[https://github.com/vim/vim/blob/master/runtime/doc/version8....](https://github.com/vim/vim/blob/master/runtime/doc/version8.txt#L53-61)

------
michaelmior
There doesn't seem to be documentation for the new packages feature yet. I'm
curious if this is actually intended to obsolete the current ecosystem of vim
plugin managers.

------
sargas
I really like those improvements and features. Specially the Async/IO stuff,
jobs, timers, and a stab at plugin packages.

This will be quite a long journey I think - an exciting one.

The other thing is that I think Vim and NeoVim will diverge at a faster rate
now. They'll soon be way too different to be related. So NeoVim won't be a
"nicer"/asynchronous/opinionated Vim anymore. But it's own alternative.

------
lando2319
For Xcode users out there, XVim has been a game changer for me
[https://github.com/XVimProject/XVim](https://github.com/XVimProject/XVim)

------
Syssiphus
Soo, are these changes already in the git repository? Because the readme is
still pointing out that the repository is for 7.4 and the tags/branches are
not very helpful. Did I miss something?

------
cm3
The new breakindent options sounds very useful. I've run into the same issue
from time to time. This hasn't been possible to fix before, has it?

------
cm3
Does anybody know what native feature is missing in Vim that makes Ctrl-P
(with all optimizations) slower than Emacs ido-mode?

~~~
mr_november
Not a real answer to your question, but for the last number of years I've been
using Command-t
([https://github.com/wincent/command-t](https://github.com/wincent/command-t))
and after the initial index operation, it's super quick.

~~~
cm3
Command-t requires Ruby support in Vim.

It's interesting that ido-mode doesn't first create a cache, and the built-in
functionality available via elisp seems to be sufficient for speedy
performance.

------
cm3
Have the various plugins started to make use of the new async/jobs/messages
functionality already?

------
masukomi
The asychronous IO, Channels, JSON, and Jobs are HUGE. This will be a game
changer in so many ways.

------
nanis
So, if I had waited nine more hours, I would have gotten a lot of upvotes, I
guess.

See
[https://news.ycombinator.com/item?id=11484697](https://news.ycombinator.com/item?id=11484697)

------
dockerlocker
Is there a way how I can copy blocks of code outside the vim window to another
application without also copying the line numbers?

Also is there one simple key combination to [un]comment a line or a selected
block?

I found out how to do many simple operations with this ancient tool, what can
be really fun if you have nothing else funny in life (too many people have no
other sources of fun, really) - but I am still not convinced. Many operations
that are a no-brainer in e.g. geany take serious planning and studying in vim
- this is absurd.

I fear that we are wasting many potentially good programmers because they
accept the primitivism and stupid limitations of vim as something "cool" and
will never again in their lives be able to program a user-friendly GUI because
their brain is "vimed out". Maybe that is one of the reasons why we still have
so much really bad software.

Once I was totally impressed by programmers, they were the wizards of today,
superbrains, uber-humans. Then I learned programming and understood how many
uncreative and cognitively limited people are just repeating stuff that
somebody else has told them, without ever asking. Basically the typical obey-
guy, the perfect follower who never questions any order will be that kind of a
good programmer, reading manuals and getting happy that he is able to
reproduce - there is no creative moment here. Only very few of them are part
of a creative elite that actually brings new ideas to life - most of them are
totally dumb rat soldiers just following the orders. This is the reason why
such ultra-primitive tools like vim still exist.

~~~
JetSpiegel
There are plugins for that. Check out vim-easyclip, and for comments theres
vim-commentary(barebones) or nerdcommenter(loads of advanced features).

~~~
dockerlocker
too many keystrokes, checked that.

~~~
majewsky
:help :map

