Skip to content

Conversation

tiagobstr
Copy link

@tiagobstr tiagobstr commented Sep 19, 2025

Description

  • Adding code completion feature to be used on protostar;
  • Adding a generic method to inject a code completion "engine" so that in the future the completion logic can be handled for each different client/language;
  • Also fixing a small issue related with trying to use a location without permissions for the indexPath.

Testing

  • Manual tests

Checklist

  • The correct base branch is being used;
  • All active GitHub checks for tests and formatting are passing;

@tiagobstr tiagobstr changed the title initial version of the completion mechanism Code Completion Sep 19, 2025
@tiagobstr tiagobstr changed the title Code Completion Adding code completion Sep 19, 2025
@tiagobstr tiagobstr marked this pull request as ready for review September 22, 2025 10:25
Copy link
Member

@alessiostalla alessiostalla left a comment

Choose a reason for hiding this comment

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

Overall this is really nice in my opinion, I think the API could be improved by not hiding CompletableFuture as that gives more control to implementations (if we then see we tend to repeat boilerplate code around CF we can always include a default base completion engine as an abstract base class)

Copy link
Member

@ftomassetti ftomassetti left a comment

Choose a reason for hiding this comment

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

I do not know enough about this library to provide a meaningful review, so I just provided some comments

): CompletableFuture<CompletionItem> =
CompletableFuture.completedFuture(
try { completionEngine?.resolve(item) ?: item }
catch (t: Throwable) {
Copy link
Member

Choose a reason for hiding this comment

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

It's rarely appropriate to catch Throwable as that includes system errors such as OutOfMemoryError so unless there are compelling reasons to keep it like that I'd just catch Exception

item: CompletionItem
): CompletableFuture<CompletionItem> =
CompletableFuture.completedFuture(
try { completionEngine?.resolve(item) ?: item }
Copy link
Member

Choose a reason for hiding this comment

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

I would have moved this CompletableFuture to the engine interface as well for consistency, even though we've rarely used that method. However we can keep it like that and open an issue if this is blocking further work on code completion.

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.

3 participants