Community
Participate
Working Groups
While working on bug 497871 (generic and extensible editor), I noticed that if a document as a custom partitioning, then it's not possible to register some completion proposals for the whole document. For example, on WTP SSE editors (such as CSS) it's impossible to trigger the generic completion in comments, because comments map to a non-default partition content-type. As the generic editor tries to "blackbox" the partitioning (or at least make it kind of optional to rely one), it would be very useful to have the ability to register a completion computer without passing a partition content-type, and to assume it's applying to the whole document.
The proposal is to change the ContentAssistant.(s/g)etContentAssistProcessor methods to allow a "null" or a magic value "any" content-type.
Another instance of this limitation is that for example if you want to use the generic editor for C#, with the Language Server extension (for most operations exception highlighting) and the Liclipse one (for highlighting): Liclipse requires the document to use Liclipse partitioning and set it directly on the document, but then all tokens in the document have a non-default content type, so completion from language server gets never invoked (as it's bound to default).
The same issues happens for hover. By default, hover is only associated to a given token content-type. A default one would be welcome.
@Dani: As I'm working on this issue, I see 2 possible approaches here: 1. Add this capability of a "default" completion proposal computer to JFace's ContentAssist class -in a backward compatible way-, so it can be used by other editors 2. Just tweak the ContentAssist used by the generic editor to add this support for a default computer. (and I guess it's similar for hover) Which one do you think is better?
(In reply to Mickael Istria from comment #4) > 1. Add this capability of a "default" completion proposal computer to > JFace's ContentAssist class -in a backward compatible way-, so it can be > used by other editors That's https://git.eclipse.org/r/#/c/80472/
(In reply to Mickael Istria from comment #4) > 2. Just tweak the ContentAssist used by the generic editor to add this > support for a default computer. > (and I guess it's similar for hover) and that's https://git.eclipse.org/r/#/c/80479
New Gerrit change created: https://git.eclipse.org/r/80472
New Gerrit change created: https://git.eclipse.org/r/80479
Tentative to 4.7.M4. @Sopot and others: I took this one to make sure I think about it, but feel free to take any bug about Generic Editor.
New Gerrit change created: https://git.eclipse.org/r/84654
Let's first restrain the scope of the request to the Generic Editor which is the only editor involved in the user story that droves to this report (mixing Language Server client and LicLipse syntax highlighting in the same editor). (In reply to Mickael Istria from comment #3) > The same issues happens for hover. By default, hover is only associated to a > given token content-type. A default one would be welcome. In the case of the Generic Editor (which is the target of this bug) the TextHover is actually document content-type agnostic, so this is not an issue here. Only completion needs to be dynamically registered on all documeent content-types, and this is covered by https://git.eclipse.org/r/84654 .
Gerrit change https://git.eclipse.org/r/84654 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=0425c77dced32fbcc337ebbd6753a4829ec513a9
