This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 89283

Summary: [Embedding] Define how various editor functionality should be composed in terms of embedded languages
Product: editor Reporter: Miloslav Metelka <mmetelka>
Component: -- Other --Assignee: David Strupl <dstrupl>
Status: RESOLVED WONTFIX    
Severity: blocker CC: mfukala, mstevens
Priority: P1    
Version: 6.x   
Hardware: PC   
OS: Linux   
Issue Type: TASK Exception Reporter:
Bug Depends on: 91718, 91891, 91893, 91906, 91907, 91909    
Bug Blocks:    

Description Miloslav Metelka 2006-11-14 10:44:30 UTC 
With presence of MimeLookup and MimePath in editor/mimelookup module and with
the Language and LanguagePath in lexer module there is now a powerful mechanism
of registering various editor functionality into xml layer for top-level and
embedded languages.
Each language has a valid mimeType accessible through Language.mimeType() which
composes a LanguagePath.mimePath() string for a particular embedding. This can
be used for MimePath.parse() and further for MimeLookup.getLookup(mimePath)
(issue 89282 will simplify this even more).
The question is how to compose the functionality such as Code Folding,
Completion Providers, various Higlighting Layers (e.g. semantic higlighting) so
that it's suitable for the embedded environments. For example the present java
infrastructure is not well prepared for the case when the java is embedded in
jsp and additional SPI needs to be provided e.g. for reusing java completion
provider for jsp. There will likely be no a single type of solution ideal for
all the potential embedding cases but we should have some guidelines and
documents with examples for each type of functionality.
Comment 1 Miloslav Metelka 2007-03-21 17:28:37 UTC 
Removed plan60 keyword because this is sort of a high level issue not too
suitable for being included in features planning. Moreover this is a longterm
goal that may need further modifications once new usecases get discovered rather
than something that can be easily embodied into a piece of code.
Comment 2 Jiri Prox 2008-04-11 00:41:41 UTC 
moving opened issues from TM <= 6.1 to TM=Dev
Comment 3 David Strupl 2011-11-25 09:45:43 UTC 
Closing old (and presumably obsolete) tasks assigned to me. If something is still needed please reopen...