In order to remain current, each Eclipse release is designed to run on
reasonably current versions of the underlying
operating environments.

The DLTK 1.0 depends upon on the Eclipse Platform 3.4.
Various sub components also depend on other Eclipse Projects,
namely the the Eclipse Modeling Framework (EMF) 2.3 or later and DSDP TM.
For this release, the core sources will be
written and compiled against version 5.0 of the Java Platform APIs and
designed to run on
version 5.0 of the Java Runtime
Environment, Standard Edition.

Source/binary Compatibility:
Due to active refactoring/optimization/improvement of the core DLTK frameworks
DLTK 1.0 will not be source/binary
compatible with DLTK 0.95.

Workspace Compatibility:
We intend to keep DLTK 1.0
upwards workspace-compatible with DLTK 0.95 unless noted.
This means that workspaces and
projects created with DLTK 0.95 can be successfully
opened by DLTK 1.0 and upgraded to a 1.0 workspace.
A workspace
created (or opened) by a product based on DLTK 1.0 will be unusable
with a product based on DLTK 0.95.

API Contract
APIs published for the DLTK 1.0 release will be carefully
reviewed prior to release, making use of "internal" packages
for
unsupported and variable implementation classes. Client plug-ins that
directly depend on anything other than what is
specified in the
published API are inherently unsupportable and receive no guarantees
about future compatibility.

Implement own parser based on XRuby with automatic error recovery, correct positions for all elements,
etc. Implement 2 modes of parser operations: FAST for building internal models and error reporting and EXTENDED with
detailed information of every source token for use in editor and formatter

Cache parsed ASTs for all modules to optimize performance of the search/content assist
operations

Syntax highlighting improvements
fix some cases with incorrect syntax highlighting. Deep use of semantic highlighting to correctly highlight all the
sources.

Rake runnner

Checks for the common code errors (need to clarify what could be checked)

Regular Expression Tester

Spell Checking Support

Mark Occurrences

Refactoring support

New TCL parser

TCL everything-is-a-string concept is cool but it makes difficult any tooling support (particulary ones dealing with
code analysis). TCL code is also string so to parse TCL source properly any tool must know parameter types at least to
follow execution flow in the source. Consider TCL statement
if a b c
Tool must know that for the case above b and c strings are source code which may be executed and shall be handled
appropriately by the tool. Real life is much complex and written above is true only if c string is not equal to else
value... This rules (proc metadata) can not be derived (inferred) from program source, and the only way is to supply
this rules externally.
Current parser has hard-coded metadata for widely used control-flow TCL procs, such as if,
switch, while, etc. This allow DLTK to
walk through large part of user program, but this is not enough to cover user
programs well.

Powerful Script Console

As a Java oriented IDE (initially) Eclipse lack of powerful Console support. But developers using interpreted
languages
like TCL expect good interactive (console, shell) support from tooling. Current Eclipse Console is a simple
stream-based
output to the the window, with some coloring and pattern matching features, which is not enough for good
interactive
console.

Proposed

Syntax highlighting

Code assist

API Documentation

Show variable values on hover

Proper OS streams handling

Available for local and remote processes

TCL IDE improvements

Proposed

TCL source code indenter (formatter)

Man-pages and documentation should be tied to the code

At the moment tcl documentation is configured globally instead the user should be able to specify different
documentation for each interpreter/library