Bug 258139 - CompletionProviders for embedded languages
CompletionProviders for embedded languages
Status: RESOLVED FIXED
Product: editor
Classification: Unclassified
Component: Completion & Templates
8.2
PC Solaris
: P1 (vote)
: 8.2
Assigned To: Svata Dedic
issues@editor
release82_fixed
: REGRESSION
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-25 06:41 UTC by Alexander Simon
Modified: 2016-10-11 01:59 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Proposed patch (10.50 KB, patch)
2016-02-25 13:37 UTC, Svata Dedic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Simon 2016-02-25 06:41:27 UTC
Regression after the fix:
http://hg.netbeans.org/cnd-main/rev/bdcebe92274a
Result:
There is no completion in C/C++ preprocessor directives.
Comment 1 Alexander Simon 2016-02-25 06:42:42 UTC
Please, rollback wrong change set ASAP.
Comment 2 Vladimir Voskresensky 2016-02-25 06:48:19 UTC
(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 |
Comment 3 Svata Dedic 2016-02-25 07:23:41 UTC
Change rolled back; sorry, I only did sanity check on JSPs.
Comment 4 Svata Dedic 2016-02-25 12:12:58 UTC
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 :)
Comment 5 Svata Dedic 2016-02-25 13:36:43 UTC
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.
Comment 6 Svata Dedic 2016-02-25 13:37:31 UTC
Created attachment 158640 [details]
Proposed patch
Comment 7 Quality Engineering 2016-02-26 02:08:37 UTC
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
Comment 8 Svata Dedic 2016-09-02 13:20:40 UTC
Fixed in jet-main#b6a574bbf8af
Comment 9 Quality Engineering 2016-09-04 01:57:42 UTC
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
Comment 10 Alexander Simon 2016-09-05 09:19:07 UTC
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.
Comment 11 Vladimir Voskresensky 2016-09-07 16:29:10 UTC
Svata, please, estimate when can we expect the NPE fix which causes 50 cnd test failures?
Comment 12 Svata Dedic 2016-09-08 09:21:48 UTC
Fixed in jet-main#65981b4b175c; please review before merging to 8.2 release branch.
Comment 13 Miloslav Metelka 2016-09-08 11:04:58 UTC
I think that the patch is fine.
Comment 14 Quality Engineering 2016-09-09 01:53:16 UTC
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
Comment 15 Svata Dedic 2016-09-09 12:51:29 UTC
Pushed as 92661cf06ab0 into release82 branch.
Comment 16 Quality Engineering 2016-10-11 01:59:16 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo