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 - [Embedding] Define how various editor functionality should be composed in terms of embedded languages
Summary: [Embedding] Define how various editor functionality should be composed in ter...
Status: RESOLVED WONTFIX
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: David Strupl
URL:
Keywords:
Depends on: 91718 91891 91893 91906 91907 91909
Blocks:
  Show dependency tree
 
Reported: 2006-11-14 10:44 UTC by Miloslav Metelka
Modified: 2011-11-25 09:45 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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...