> But it definitely would be better if it worked asynchronously.
Yes, I agree with that. The tricky part
in converting existing content assist processors is that they can currently
access the UI thread. Plus, they can be contributed by clients i.e. we
don't have control over them (https://bugs.eclipse.org/510814).
Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx> To:
Discussions about the
IDE <ide-dev@xxxxxxxxxxx> Date:
21.04.2017 22:46 Subject:
Auto content assist Sent by:
On 21 April 2017 at 18:28, Daniel Megert <daniel_megert@xxxxxxxxxx>
wrote: > The foremost
issue is what Mickael Istria mentioned: the completion API needs to be
adapted to work in asynchronous mode, instead of in the UI thread. Otherwise,
enabling auto-invocation of completion is almost certain to be a grief
to the user.
I disagree with that. The existing JDT content assist is expected to return
results fast. Slow completion processors are flagged and disabled. So,
there won't be more delay than when you currently type '.' or invoke Ctrl+Space.
Did you try it before commenting here?
Slow/fast for an UI-blocking operation that is invoked
explicitly (Ctrl+space) is not the same as slow/fast for an UI-blocking
operation that is invoked automatically and that I may not even want at
that point. So for example blocking 200-400ms for a completion I invoked
explicitly is fast. But having the UI block for 200-400ms when I am typing
and want to continue typing or do something else (but not autocomplete)
is mega annoying. (more or less to how often and long these freezes occur)
I guess this could be mitigated by choosing a good auto-invoke delay, that
would be key to having this work is a suitable way. So maybe I was wrong
to say it needs to be done in async mode to be worthwhile. But it definitely
would be better if it worked asynchronously.