Fix Slow Scrolling in Vim When Line Is Too Long

I've tried a good dozen times to compile Vim on my Mac but I've never managed to obtain a usable Vim: each time it worked but it was unbearably slow and laggy.

After loosing too much time trying to make it work I simply dropped the towel and created an alias to MacVim's bundled CLI executable.

alias vim='/path/to/MacVim.app/Content/MacOS/Vim'

Not only is it fast and responsive but it has the exact same features you could find in MacVim, as long as it makes sense in a terminal. Since then, using MacVim and/or Vim makes no difference for me and whether I use one or the other is dictated only by the context. Not by one being better than the other.

Why is my vim configuration slow? How can I improve the speed of my vim configuration within Terminal or iTerm2?

By using MacVim's pre-compiled binary.

Also try Linux one day. MacVim is fast only if you have never used GVim or Vim on a linux box.

:%norm! gww

This applies the normal command gww (which formats the current line as with gw) on the entire buffer, without taking customized mappings into account (to avoid problems if e.g. gw has been mapped to something else).

See

• :help :%
• :help :norm
• :help gww

This alternative is as per Ben's suggestion in the comments, and is more straightforward than the original solution, which is saved below since it might fit better in other similar circumstances due to the regular expression matching ability. In the "match all lines" case, it is unnecessarily brute, though.

Applying gww on every individual line in the buffer programmatically:

:g/^/norm gww

See :help :g and :help norm. ^ matches the beginning of a line, which in practice makes this match every line.

One can also opt to select only lines longer than e.g. 60 characters with

:g/\%>60v/norm gww

(see :help \%<) but in practice gww will only reformat lines longer than textwidth anyway, so it might not matter much in neither speed nor result.

(I am using v for "virtual column" instead of c for "column", since the latter really calculates a certain number of bytes into the line. This can lead to unexpected results when using multibyte encodings, which is often a reason to be wary. In practice it is not a real issue for the same reason as above, regarding that gww will not reformat lines shorter than textwidth anyway.)