Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to asynchronous racer command with timeouts. #119

Merged
merged 1 commit into from
Mar 7, 2019

Conversation

vkz
Copy link
Contributor

@vkz vkz commented Mar 5, 2019

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 #97

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#97
@coveralls
Copy link

Coverage Status

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

1 similar comment
@coveralls
Copy link

Coverage Status

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

@kngwyu
Copy link
Collaborator

kngwyu commented Mar 7, 2019

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.

Copy link
Collaborator

@kngwyu kngwyu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kngwyu
Copy link
Collaborator

kngwyu commented Mar 7, 2019

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

@kngwyu kngwyu merged commit d3ece58 into racer-rust:master Mar 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

racer starts when cursor resting at pos 0 and locking up the UI for seconds..
3 participants