Please, rollback wrong change set ASAP.

(In reply to Alexander Simon from comment #1)
> Please, rollback wrong change set ASAP.
I think, better fix is welcomed as well :-)
Just make sure, that in C++ files (i.e. create Quote sample project)
you have completion after typing
#|
and also after 
#include |

Change rolled back; sorry, I only did sanity check on JSPs.

OK, so the idea was to correct the situation where providers for embedded language text/foo are actually obtained through providers of toplevel language, which is against the principle of seamless extensions by defining embeddings in lexer/parser. Yes, the Lexer API has also some rough edges :)

Consider a use-cases:

SQL embedded in a Java String. In (a little artifical) example, Java String is a 'language' itself (it allows \ escaping etc), one would like to get
* SQL completion, since SQL command(s) are being edited in the string
* String completion, i.e. \ sequences
* Java completion, i.e. " pair completion or possibly something else.

Each of the completion providers can solve just work for its own language and does not need to handle possible embedded stuff.

Use case #2:
text/x-jsp uses a Wordmatch provider, text/x-java also uses Wordmatch. But text/x-java can be embedded in text/x-jsp. We do not want to have wordmatch items duplicated.


Use case #3:
since JSP can include many types of content (embedded), it registers:
* HTML provider
* Java provider
* HTML palette provider
* CSS provider (implemented through GSF provider)
* of course the JSP itself

Leave aside HTML (case similar to UC#1). Java is a language which can itself have some embedded providers. CSS cannot be directly nested in JSP, but can be nested through embedded HTML ... so JSP should know nothing about CSS.


So I propose the following:
* all provides for the MimePath at caret dot and all enclosing languages will be collected (UC#1, UC#3)
* each provider implementation will be accepted only once for the mime *path* (UC#2)

I'll attach a patch for those interested to review.

Created attachment 158640 [details]
Proposed patch

Integrated into 'main-silver', will be available in build *201602260002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/08aa81c4758e
User: Svata Dedic <sdedic@netbeans.org>
Log: #258139: Rolling back bdcebe92274a, improper fix

Fixed in jet-main#b6a574bbf8af

Integrated into 'main-silver', will be available in build *201609040002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/b6a574bbf8af
User: Svata Dedic <sdedic@netbeans.org>
Log: #258139: applied suggested patch, enabled completion in emebddings

The fix introduced NPE in CompletionImpl.ensureActiveProviders() in the line:
String mime = getMimePath(getActiveComponent());
Active component can be null, but getMimePath() requires non null parameter.

Svata, please, estimate when can we expect the NPE fix which causes 50 cnd test failures?

Fixed in jet-main#65981b4b175c; please review before merging to 8.2 release branch.

I think that the patch is fine.

Integrated into 'main-silver', will be available in build *201609090002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/65981b4b175c
User: Svata Dedic <sdedic@netbeans.org>
Log: #258139: avoid NPE if active component or document is null

Pushed as 92661cf06ab0 into release82 branch.

Integrated into 'main-silver', will be available in build *201610110002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/885fa2c2ac3d
User: Svata Dedic <sdedic@netbeans.org>
Log: Applied #258139 patch