[mynameisfiber]

Any worry about latency with this new plugin architecture? I'm not quite sure how the current plugins communicate with the main process, but I am sure that one of the things I would most like to see in a re-write of vim is a more responsive interface, even if I have a handful of plugins running.

[ggreer]

If anything, the NeoVim will be much more responsive. Vim's current plugin architecture is simple: when plugin code is running, the UI is blocked. If your plugin has an infinite loop, Vim hangs forever. If your plugin does network I/O, Vim hangs until the socket read/write is finished. The only work-around is to use non-blocking sockets and abuse CursorHold/CursorHoldI autocommands and updatetime. That trick breaks the leaderkey, which is a show-stopper for many users. There are similar problems with syntax highlighting. Vim has its own (extremely inefficient) regex engine that blocks the UI when matching.

[rquirk]

The regex engine was updated in version 7.4 and now is noticeably faster.

[ggreer]

There's plenty of room for improvement. For example: if you run the same regex many times in a row, Vim rebuilds the DFA on each run. A cache of recently-used DFAs would avoid tons of wasted computation. Also, Vim doesn't free many regex-related data structures until you close the buffer they were invoked on. I had to work-around that bug when writing a plugin, since it caused Vim to use gigabytes of memory.

The best solution would probably be to switch to PCRE. Some Vim-specific stuff[1] would have to be special-cased, but Vim could get an order of magnitude speedup (and fix quite a few bugs) by using a modern, optimized, well-tested regex library.

1. Vim abuses regexes like nothing I've ever seen. You can even match line and column numbers with the regex engine: http://vimdoc.sourceforge.net/htmldoc/pattern.html#/\%l