Switch to asynchronous racer command with timeouts.

[vkz]

This commit replaces blocking call-process with asynchronous make-process. Instead we block explicitly until racer process output is received or timeout fires. To that effect we introduce two new custom variables racer-command-timeout and racer-eldoc-timeout. The latter is important because Eldoc runs every time Emacs is idle but the user should be able to start typing any time without waiting on the racer process. Timeout value of nil will wait for the output indefinitely.

I observed that the first time racer shell process runs it may take a while to respond probably due to indexing. Following responses tend to be snappy. For that reason and because user asking for completion is likely ok with a bit of waiting racer-command-timeout defaults to nil. racer-eldoc-timeout however should be fairly low. How low depends on your machine, etc. Value of 0.1 was too short on my machine, but 0.5 seems to work fairly reliably.

Hopefully fixes racer-rust/emacs-racer#97

[coveralls]

Coverage increased (+0.8%) to 64.962% when pulling 780074b861c3327c3830e72d81b71a4f7321122f on vkz:master into 22636dd8d53ffa22dcbeea2d71bf1b755f155062 on racer-rust:master.

[coveralls]

Coverage increased (+0.8%) to 64.962% when pulling 780074b861c3327c3830e72d81b71a4f7321122f on vkz:master into 22636dd8d53ffa22dcbeea2d71bf1b755f155062 on racer-rust:master.

[kngwyu]

Thanks!

I observed that the first time racer shell process runs it may take a while to respond probably due to indexing

It's because racer calls cargo metadata. Though it can be problematic I don't have no other idea to get dependencies.

racer-command-timeout defaults to nil. racer-eldoc-timeout however should be fairly low

I think it's reasonable decision, though maybe I have to test it by actually using it.

[kngwyu]

I tested in my repository and it looks everything works correctly Thanks!