An experimental Vim fork with multi-threading capabilities

https://github.com/tarruda/vim/tree/event-loop

by tarruda • 13 years ago

75 33 13 years ago

epmatsw• 13 years ago

Hmmm. So the benefit of this is offloading plugin processing onto a separate thread(s)? I guess I see the theoretical benefit of that, but I'm unsure of how useful this actually is...

jeremysmyth• 13 years ago

An indirect attempt to troll for side-effects and hilarious race conditions perhaps?

taeric• 13 years ago

Ever had to sit and wait for vim to parse a gigantic file to get syntax highlighting correct? Just waiting for it to know the line numbers can take a while.

cma• 13 years ago

One thing I run into a lot is that sometimes tab completion scanning ctags locks up the whole process for several seconds.

seren3• 13 years ago

Every time you launch a process from inside vim (like grepping multiple files, generating tags for a large project, etc) it totally freezes the user interface. You can not execute any long task in the background, which is really annoying. So having a multi threaded Vim is very much overdue.

There is an ongoing discussion on the vim-dev mailing list regarding a proposed patch by Thiago Arruda [1]. I have no opinion on the technical merit of the patch, but as a user, I would warmly welcome a move in that direction.

[1] https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ

njharman• 13 years ago

GUI apps should be multi-threaded. But, process handling is OS task. Unix already provides facility for backgrounding of processes.

:!long-process&

recuter• 13 years ago

Wouldn't a simple fix be writing a little stub that acts like the Tee command line utility? It would immediately hand back to Vim and pipe onwards the command you sent it.

Could be a temporary kludge at least until OP gets going.

chongli• 13 years ago

You haven't tried some of the heavier auto-complete plugins. As it stands right now, they have an annoying tendency to block the UI while you're typing! It's bothered me so much that I've even considered writing my own vi clone based entirely on an asynchronous message queue such as this!

rjzzleep• 13 years ago

ever tried youcompleteme? the redraw bothers me, but that's a different issue

http://valloric.github.io/YouCompleteMe/

mattengi• 13 years ago

  - syntax highlight
  - decent automatic indenting
  - semantic auto completion popup
  - on the fly compile
  - on the fly syntastic check(lint tool)

In vim, those settings are very sluggish in my old AMD 2 core 1Ghz cpu laptop. Sublime Text and Emacs both are quite reasonable.

I think vim could be more responsive.

This slow response problem is only reason for trying other editor. Please make this real.

grondilu• 13 years ago

I don't use the last four of the features you're mentioning, but I can confirm indeed that syntax highlighting can make things terribly slow with large files and/or complex languages (I'm a Perl 6 guy), so yeah if multi-threading can help, I hope it gets implemented soon.

_delirium• 13 years ago

Wanting the "engine" of emacs but the interface conventions of vim, I've been using emacs with Evil (https://gitorious.org/evil/pages/Home) a bit lately, and quite liking the combination. It implements a fairly good portion of vim, enough to cover just about everything I regularly use, which was a pleasant surprise (I'm used to "vim compatibility" layers usually being pretty shallow).

CJefferson• 13 years ago

The patch for this on vim-dev has been completely ignored for other a month by all vim developers, so don't get any hope this will be accepted.

tarruda5• 13 years ago

Perhaps with enough pressure from the community there's a chance this will happen?

Meanwhile I will keep maintaining the fork up-to-date with upstream, so plugins can make use of the patch through a simple 'if has("messagequeue")' conditional

dudus• 13 years ago

1 month is not a long of time. Specially when you are waiting for core developers of a busy project. Besides that this month had several holidays. Maybe you just need some faith.

btipling2• 13 years ago

Depending on faith will probably lead to bad decisions, a rational appraisal of available evidence and some critical thinking will probably be more useful. And let me present some evidence that may destroy any remnant of that faith you have:

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

That's our async/timers patch, we pretty much gave up for now because debugging vim was a nightmare. Right now something is stomping over regexp objects in memory. We have no idea where. We've found unsafe pointer use, etc. Vim code is pretty much all globals, 25k lines and 400+ ifdefs for at least one file, some crazy file encoding, pre C89 C that still compiles on an amiga, mixed tabs and spaces. The vim code base is pretty much the worst code I've ever seen and Bram doesn't seem to really grok our patch. He's also been demanding with his requests that we feel are over the top. That's fine, that's his choice. We're focusing on other plugins right now, we put in many months of work into vim. It kinda works as long as you don't use leader keys.

elmindreda• 13 years ago

I wish more people understood this.

shocks• 13 years ago

Is this a bi like vimproc[1]?

1: https://github.com/Shougo/vimproc.vim

amadeus• 13 years ago

My understanding is that Vimproc can only kick off async processes, it can't actually call back into the main Vim thread once a process has completed.

An experimental Vim fork with multi-threading capabilities

Related Stories