Bracket matching support

Overview: Although the Code Editor currently supports some automatic indenting when typing curly brackets, it does not feature bracket matching. We would like to see both matching brackets in bold when the caret is on a bracket. We would also like Ctrl+(opening or closing curly bracket) automatically bring the caret to the matching bracket. This could work for all types of brackets: (), {} and []. If also handling angled brackets <>, it should not be confused with the relational operators, possibly only enabled for some languages like HTML. Care should be taken not to include brackets from commented out code while matching.

The bracket awareness code currently implemented (for auto-indenting) is handled directly in the EditBox control. It may be the easiest to implement the bracket matching there as well.

For a more in-depth implementation, this idea could be looked at together with a fuller generic language grammar and regular expressions approach.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

Moving parsing to another thread so as not to jam updates while typing

Overview: At the moment parsing the code in the editor occurs in the main application thread which also handles drawing and processing input. The parsing analyzes the code for the purpose of context sensing for parameters/members popups and autocompletion, and is done on typing some special characters such as '.', '>', '(', '{', ',', ';', '=', '?' and ':'. On larger source files, this can cause a noticeable delay which makes the Code Editor appear sluggish (holding down the '.' key on a large source file is a good example).

We would like to move this parsing to happen in a separate thread, so that if the user keeps typing the parsing doesn't cause any noticeable lag. The popups would be the only thing potentially delayed by lengthy parsing time, and the code would overall be parsed fewer times. For example if ten dots are repeatedly typed and the first one took a lot of time to parse, the code would only be parsed on the first and the last (after the first parsing finished).

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with multi-threading and synchronization

Tabbed documents and dockable panels

Overview: The IDE still presents documents with an old-fashioned MDI layout, which annoys some users who would prefer to see a more trendy tabs and docking layout.

Code Editor and Object Designer documents instances should create tabs instead of new windows, and all panels (e.g. debugger panels, output panel, project view, toolbox) and documents should share the screen estate through a docking system.

Documents would always fill the remaining space in the middle, while panels would snap to one of the for edges of the main frame. Splitters (both horizontal and vertical) should be added for the document portion windows to support comparison between two different source files, or between two sections of the same file (all tabs would be duplicated in both panes after a split). As part of this task, it may be necessary to uncouple the document model from the Window class (or otherwise use some other syncing solution), since you could now have the same documents viewed from two different panes.

This functionality could be implemented either with our current GUI system, or as part of docking support in the new auto-layout GUI and then integrated in the IDE. If implemented with the current GUI, the developer should first be familiar with our ideas for the auto-layout GUI so that code can easily be adapted to the new system. Please refer to the detailed description of how the docking should behave in the GUI toolkit docking task.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with programming user interfaces

"Go To Definition" Feature

Overview: A lot of our users have expressed a strong desire for a "Go To Definition" feature. Right clicking on a language construct should popup a context menu to go to its definition, or alternatively hitting F2 with the caret over that construct would do the same.

This feature would first determine the type of construct whose definition the user is interested in , and figure out in which module it is defined. The definition could come from any of three different locations:

• In the same eC source file, in which case the IDE already parsed the definition and has a corresponding Abstract Syntax Tree node for it, including location information (line and column for the start and end of the construct).
• Another eC module in the same project, in which case a symbol file (.sym) would exist if any compilation attempt has already taken place. The IDE would know in which corresponding eC file to find the definition, open it up, parse it and then proceed to identify the definition from the AST.
• A prebuilt library, whose information would be loaded from a shared library and have information available from the reflection object model. In this case, if the source is available (through adding the library as an additional project in the workspace), the module would need to be identified. Then the IDE would open the source file, parse it and proceed to identify the definition with the AST.

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with Abstract Syntax Trees

Extensible syntax highlighting, auto-indenting for other programming languages

Overview: At the moment, syntax highlighting in the code editor is done simply by parsing:

• Comments
• Preprocessor directives
• Character literals
• String literals
• Number literals
• eC keywords

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with TextMate grammar rules
• Familiarity with regular expressions
• Familiarity with a number of popular programming languages

Progressive (partial) parsing

Overview: Every time the code editor reparses a source file, the result of previous parsing (abstract syntax tree) is completely discarded, and the parsing is done from scratch again. This parsing currently occurs upon saving, typing characters which may trigger context-sensing popups or activating the object designer to visualize objects.

It would be a great improvement to be able to keep unmodified AST constructs and only re-parse those construct that may have been modified by text recently typed. Special characters being typed (e.g. curly brackets, semicolons) could give a hint as to which sections of the code would need to be re-parsed.

This may be easier done with the new prototype recursive descent parser.

See also related task about moving parsing to a separate thread.

Skills Required:

• Familiarity with basic object oriented programming concepts
• Familiarity with eC, C or another language in the C family (e.g. C++, C#, Java)

• Familiarity with parsing and abstract syntax trees