- Blinking Caret
- Bracket matching support
- Moving parsing to another thread so as not to jam updates while typing
- Tabbed documents and dockable panels
- "Go To Definition" Feature
- Extensible syntax highlighting, auto-indenting for other programming languages
- Progressive (partial) parsing
-
Blinking Caret
Overview: The Code Editor caret currently does not blink, nor does the caret in any of the EditBox controls (also used by the Code Editor). Adding blinking would facilitate locating the caret and most users of the IDE and applications built with Ecere would expect a blinking caret. A global Timer could be used to control the blinking, and a property could be added to the GuiApplication class to control the blinking interval.
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)
Difficulty: Easy (Verty short task, consider bundling with related idea(s))
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
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)
Difficulty: Easy (Short task, consider bundling with related idea(s))
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
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
Difficulty: Medium (Short task, consider bundling with related idea(s))
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
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
Difficulty: Medium
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
"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
Difficulty: Medium
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
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
We have initiated a separation of the syntax highlighting from the EditBox which would be a first step towards generic syntax highlighting, but it currently suffers from a few issues:
https://github.com/redj/ecere-sdk/commit/c67ed3dbeef02a526544128375575cd601f0e38f
Auto-indenting should also be adapted to the language.
The ability to edit color schemes and indenting options (Whether to use tab characters, 1-8 spaces), with per language options, should also be added to the Global Settings/Editor dialog, and saved in the user configuration file using the IDESettings class. In addition to the syntax highlighting color, it should be possible to configure the values of the background and foreground color of the code editor, project view and various panels of a given color scheme.
Some integration with existing context sensing code (specific to eC constructs, implemented in CodeEditor.ec and other IDE sources files) could be done and reorganized to support multiple language as well, but this would likely be the focus of a subsequent 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 TextMate grammar rules
- Familiarity with regular expressions
- Familiarity with a number of popular programming languages
Support for auto-indentation should be adapted to each language.
Difficulty: Medium
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com> -
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
Difficulty: Hard
Lead Mentor: Jérôme St-Louis <jerome@ecere.com>
Additional Mentor: Réjean Loyer <redj@ecere.com>