Additionaly there can be an extra module (editorcore.jar) that will
contain the code for reading the editor annotations and settings.

Shouldn't there be an editor-completion module which provides
infrastructure for doing completion (keyboard listening,
drawing the window, talking to MDR to fetch results etc.)
and then the java-completion module uses that?
Then it would be easy to add completions for other languages
instead.

Without that, every module has to rewrite all that code, and
undoubtedly there will be inconsistencies; one module will
have a 2 second timeout and another 5; one module will size
its completion window 200x200 and another 300x300, etc.

Also, when refactoring modules, it would be REALLY nice if 
you could create a "Code Editor" that all the language editor
modules could derive from. The Code Editor would define COMMON
settings like font size, color/font of keywords, color/font
of comments, etc. Right now I have to go and edit all of these
for each language. I realize that's because "keyword" is a concept
that doesn't belong in a Plain editor, but in the IDE area there
is a lot of overlap so it would be nice to share all this, not
just from an implementation perspective but from a usability
perspective too.

The future javacompletion module is intended to contain the databases
and provide the basic querying on top of them and updating of them. It
is not intended to do the additional logic such as evaluating the
editor context and presenting the output of the query. That part will
stay in the editor because it depends on the Syntax and other classes
that are "too deep" in the editor. One possibility to move even the
context evaluating part out from the editor would be if the lexer
module would be available because then the javacompletion could depend
on the java-lexer instead of Syntax classes etc. 

IMHO the "Code Editor" is equivalent of the editorcore mentioned in
the previous note.

By "containing databases" I've meant the java code completion
databases management code. So in fact the javacompletion module will
simulate the MDR until the MDR will be ready.
By "evaluating context" I mean that there is a simplified parser that
simply speaking obtains the JTextComponent and the cursor position and
produces the list of completion items appropriate for that context.

The final naming (cvs location to resulting jar(s)):
cvs/editor => editor.jar and editor-lib.jar
cvs/editor/settings => editor-settings.jar and editor-settings-lib.jar
cvs/java/completion => java-completion.jar and java-completion-lib.jar
cvs/java/editor => java-editor.jar and java-editor-lib.jar
cvs/java/editor/settings => java-editor-settings.jar and
java-editor-settings-lib.jar
cvs/html/editor => html-editor.jar and html-editor-lib.jar
cvs/html/editor/settings => html-editor-settings.jar and
html-editor-settings-lib.jar
cvs/text/editor => text-editor.jar and text-editor-lib.jar
cvs/text/editor/settings => text-editor-settings.jar and
text-editor-settings-lib.jar

The editor_split cvs branch will contain the changes related to editor
module split.

Implemented in the editor_split branch. The split was implemented in
the prj40_prototype branch. Please see also issue #27137.
 We are hesitant to implement the split in the main trunk (likely
codebase for 3.5) too as it requires changes in all-editor related
build scripts and manifests (including tests) and still we don't count
with the externally maintained scripts that we don't know about. The
split also requires some incompatible changes in the java code
completion which is not desired to be done in NB3.5 (should stay
compatible with 3.4). Doing the split in NB4.0 is more appropriate as
it is generally expected to have necessary incompatible changes there
in both the code and the build scripts.

Ok. Is there a way (in the trunk/3.5) to access java completion from
outside the editor?   Martin told me to use
org.netbeans.modules.javacompletion.lib.JCManager().getDefault().getFinder(...)
but I assume that's the way I do it in the split_branch. (Because when
I searched for a org.netbeans.modules.javacompletion in the trunk, I
didn't find it.)

In the trunk/3.5 you can use static method 
org.netbeans.editor.ext.java.JavaCompletion.getFinder()
in editor/libsrc CVS folder

Reopening - it's necessary to make the split in the current trunk. The
basis still apply and in addition we may revise whether it would make
sense to separate editor/libsrc into a separate submodule e.g. editor/lib.

*** Issue 44305 has been marked as a duplicate of this issue. ***

Removing the PROJECTS keyword, as it is probably not old-projects
specific (re-add it back if you disagree).
Also removing blocked issue #27137, which is probably invalid now
(re-add if you disagree).

The editor/libsrc sources are now projectized and built under a
separate submodule editor/lib.

Unfortunately the editor module splitting will not be integrated into
promo-D but we will perform it early in promo-E.

*** Issue 45965 has been marked as a duplicate of this issue. ***

Making dup of a new issue as this one was already partly implemented
in the original prj40_prototype and contains some obsolete information.
I have transferred the cc and keyword list to the new issue.

*** This issue has been marked as a duplicate of 51486 ***