Community
Participate
Working Groups
For the moment, the CompletionProposal is missing to implement all the very interesting ICompletionProposalExtension interfaces which provide some usability and performance improvements. As this class is pretty easy to use, it's often chosen by people who get started implementing content assist processors. In order to give them more value from the beginning, the CompletionProposal class should implement those interfaces.
CompletionProposal is the simple class that allows to easily add content assist. We have clients that just use that class without additional needs. Adding additional stuff would impact their behavior. Also, it depends on the proposals which interfaces are needed and make sense.
(In reply to Dani Megert from comment #1) > CompletionProposal is the simple class that allows to easily add content > assist. The goal is not to make it more difficult. No new options should be added. > We have clients that just use that class without additional needs. > Adding additional stuff would impact their behavior. Right. And what's tricky is to figure which of the assumptions of the CompletionProcessor they're really relying on. I don't know a good way to figure that out. > Also, it depends on the proposals which interfaces are needed and make sense. A simple one would be ICompletionProposalExtension7 to provide StyledString with matching part highlighted in bold. I think it's relatively easy to implement a still generic way to highlight characters without risking to break anything. Another one, for which there might be some reluctance, is the ICompletionProposalExtension3 and addition of the "validate(...)" method to decide whether to keep the proposal or not when typing a character (rather than recomputing all proposals). A simple implementation would be simply keep only the proposals for which entered characters are a prefix of the string (or maybe a subpart). As I'm writing it, I'm not sure what's best for the typical use-case of this class.
I think if we really want to offer a CP class that implements all extensions, we should remove the final on the current CP class and add a new subclass with that functionality. This would also allow clients to extend the existing CP class and adjust it to their needs.
(In reply to Dani Megert from comment #3) > I think if we really want to offer a CP class that implements all > extensions, we should remove the final on the current CP class and add a new > subclass with that functionality. This would also allow clients to extend > the existing CP class and adjust it to their needs. Thanks. That would indeed be an interesting approach. Let's try to keep it in mind for Photon. I'm reopening the bug and changing title so it can appear in backlog.
Removing target milestone for all bugs that are not major or above.
> Removing target milestone for all bugs that are not major or above. Of course I meant "major or below". Sorry for the noise!
