Community
Participate
Working Groups
IContentAssistProcessor takes viewer as input to get proposals, but doesn't take it as input to get trigger chars. However, some processors require the viewer, or the document, to decide what are the proper activation characters to use.
Can we add new methods to IContentAssistProcessor with default in the interface? Or can we create an IContentAssistProcessorExtension with those methods?
Do you instead mean characters that apply the current proposal? The trigger characters are more interesting to the content assistant and UI part of the story than the potentially headless processors.
I'm talking about IContentAssistProcessor#getCompletionProposalAutoActivationCharacters . In the meantime, I'm using a workaround to retrieve the document from ((ITextEditor)PlatformUI.getWorkbench().getActive....getActiveEditor()).getDocument()"
Actually, it seems to me that triggerChars don't scale: if someone wants to include all chars (how many are there these days, thousands?) except a few ones, then building a list is going to take a lot of RAM for dummy data. Instead of a new API to improve triggerChars computation, we may need a new API that checks directly a keyEvent and get access to the viewer and document to decide whether to auto-enable for this event.
Any progress on this? I would need this too as the proposals are dependent on the language of the document and in english there are other chars as in french or german (as the keywords are different). I could try to provide a patch if there is a consensus on how the API should be designed. We could provide an extension interface with the following properties: 1) getCompletionProposalAutoActivationCharacters could be default implemented returnin null 2) add a new default method (that's what the content processor does anyways) > boolean isAutoActivation(KeyEvent event, ITextViewer viewer, int offset) > char[] triggers= processor.getCompletionProposalAutoActivationCharacters(); > if (triggers != null && new String(triggers).indexOf(c) >= 0) { > return true; > } > return false this way new users can choose to implement any of the above methods, old clients are not affected.
@Christoph: That seems good to me, let's try and see. The only concern is just that the getCompletionProposalAutoActivationCharacters would still remain when it's not actually used, so it's a bit of garbage in the API. Maybe a new IContentAssistProcessor2 interface would be cleaner?
I could add a new interface but clients would still need to implement the old one because of ExtensionPoints use that interface also and we otherwise need to add the other methods also.
(In reply to Christoph Laeubrich from comment #7) > I could add a new interface but clients would still need to implement the > old one because of ExtensionPoints use that interface also and we otherwise > need to add the other methods also. Which extension points actually consume this API? I'm aware of Generic Editor, but that's something we can change easily.
The extension point is org.eclipse.ui.genericeditor.contentAssistProcessors but if we do not extend the interface we also need to change ContentAssistant and IContentAssistant and probably other places.
(In reply to Christoph Laeubrich from comment #9) > The extension point is org.eclipse.ui.genericeditor.contentAssistProcessors > but if we do not extend the interface we also need to change > ContentAssistant and IContentAssistant and probably other places. That's right. As we're increasing Platform development speed with more and more contributors, we're starting to get hurt very often by this kind of pattern; and so far, no perfect solution has emerged. I suggest you get started with your proposal and we may discuss potential improvement from this 1st iteration.
I found one issue with passing the key.event, it seems org.eclipse.jface.text.contentassist.CompletionProposalPopup does not has an event object but uses a char from the current document to check for autoactivation I see two opportunities: 1) generate an synthetic event -> but filled data will be incomplete because it is not a real event 2) pass a single char instead of the event I would tend to option 2 atm even though it is not that flexible it is a bit more cleaner in respect to the ITextViewer/IDocument API as those are not seem to use any SWT specific parts. A third option would be to use some kind of DocumentEvent (or even ActivationTrigger event) that optionally can carry the original event if present but is might be a bit hard to code against code that sometimes contains an event and sometimes not...
(In reply to Christoph Laeubrich from comment #11) > 1) generate an synthetic event -> but filled data will be incomplete because > it is not a real event > 2) pass a single char instead of the event > > I would tend to option 2 atm even though it is not that flexible it is a bit > more cleaner in respect to the ITextViewer/IDocument API as those are not > seem to use any SWT specific parts. Ok for approach 2.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/174905
I'm curious, what's the use-case for this new API that wouldn't be covered by a proper solution to bug 101420 ?
(In reply to Mickael Istria from comment #14) > I'm curious, what's the use-case for this new API that wouldn't be covered > by a proper solution to bug 101420 ? Well you opened the initial bug on this 4 years ago :-) The referenced Bug is > 15 years old and I don't see any progress there... maybe because its to vague or eclipse is designed to be too generic/extensible to find a solution that suits all to get to a conclusion. I also would consider this as new API, its more incomplete. All other methods allow access to the document so it seems right to have it here also. My particular use case is that the set of characters that trigger auto activation is not known as the language I like to supply autocomplete for is not static (the content of the document determines how the keywords are named) and I don't know them in advance. So I'D like to have the opportunity to check the document language, fetch the keywords and then only return those chars that could trigger an auto completion.
(In reply to Christoph Laeubrich from comment #15) > Well you opened the initial bug on this 4 years ago :-) Yet I didn't work on it because it wasn't high priority to me. As we've made progress with async completion and so on, the initial use-case I had for this is now better handled by bug 101420 > The referenced Bug > is > 15 years old and I don't see any progress there... maybe because its to > vague or eclipse is designed to be too generic/extensible to find a solution > that suits all to get to a conclusion. I don't think it's true that there hasn't been any progress. See the relation chain (blocks/depeends/duplicate/see also), there are numerous related issue that were tackled towards that goal. > My particular use case is that the set of characters that trigger auto > activation is not known as the language I like to supply autocomplete for is > not static (the content of the document determines how the keywords are > named) and I don't know them in advance. So I'D like to have the opportunity > to check the document language, fetch the keywords and then only return > those chars that could trigger an auto completion. OK, that's a very valid case, thanks!
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/174905 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=a8e8f4b9ea82b28b8ad80fa74c782fabaf537288
Thanks Christoph. Please add a note about it to https://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/tree/4.19/platform.html
New Gerrit change created: https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/174959
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/174960
Gerrit change https://git.eclipse.org/r/c/www.eclipse.org/eclipse/news/+/174959 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=25c049fcba60edaca9f29d45bfd237f298c53c9c
Thanks Christoph! (PS: please test the N&N .html files in a browser, there were a bunch of typos that are pretty easy to view in a browser)
Thanks for helping out here Mickael!
