Delay revalidation and handle validation cancellation correctly

[datho7561]

Delays revalidating after an edit is made in order to reduce the number of validations run. Handles validation, hover, completion, and definition cancellation better by checking if the request is cancelled between expensive steps.

See eclipse-lemminx/lemminx@420076e, eclipse-lemminx/lemminx@974099d

Signed-off-by: David Thompson davthomp@redhat.com

[datho7561]

@angelozerr when you get a chance, could you please look at this?

[angelozerr]

Your PR looks promising but the main idea is to get th eproperty model at first (instead of getting the project info cache)

For instance completion should start like this:

return getPropertiesModel(params.getTextDocument(), (document, cancelChecker)

and the project cache should be used after.

Why? Because the cancel checker that you will receive will be bind with the cancel of the client. All features like hover, completion, etc must return return getPropertiesModel(params.getTextDocument(), (document, cancelChecker) to receive the proper cancel checker bind with the cancel of client. Ex: if the user hover someting and move the mous in an another location, hover will be cancelled and your cancel checker will be bind with client cancel and it will cancel correctly.

For hover I will try:

@Override
public CompletableFuture<Hover> hover(HoverParams params) {
	 // Get the Properties model document
	return getPropertiesModel(params.getTextDocument(), (document, cancelChecker) -> {
		// Get MicroProfile project information which stores all available MicroProfile
		// properties
		MicroProfileProjectInfoParams projectInfoParams = createProjectInfoParams(params.getTextDocument());			
		MicroProfileProjectInfo projectInfo = getProjectInfoCache().getProjectInfo(projectInfoParams).getNow(null);
		// then return hover by using the MicroProfile project information and the
		// Properties model document
		return getPropertiesFileLanguageService().doHover(document, params.getPosition(), projectInfo,
				sharedSettings.getHoverSettings());
	});
}

BUT it means that projectInfo can be null, and we will need tocheck that in the doHover. I think we should do that in the doHover because some hover don't need projectInfo (ex : hover for expression to evaluate it).

For completion if projectInfo is every time required, we could check that before calling the doComplete of language service.

It seems that you take care of only properties file. It should be nice to do the same thing for Java file, but we can do that in a separate PR if you wish.

[datho7561]

@rgrunber I tested completion on a fresh Quarkus project, and instead of blocking while the properties are loading, it instead returns no completion results until the properties are fully loaded.

[angelozerr]

Great job @datho7561 !

[rgrunber]

Yup, definitely a nice improvement. The completion returns immediately now and results are populated as expected once projectInfo completes.