Roadmap
Roadmap for Version 3.5
October 26, 2017
Every once in a while I like to give all of you a sneak peak at what is being worked on in TKE. In the 3.5 stable release cycle, the goal is to focus on application performance, especially editing performance. There are two main factors in the success of a code editor: functionality and performance. One is not more important than the other, so it is important that TKE's development does not exclude one for the other. TKE's performance is adequate at the moment, but I would like to see improvements in a few key areas.
First, application startup performance needs to be improved again. Ideally, I would like to the see the application start in around 2 seconds or less depending on the number of previously opened tabs and the currently displayed file(s). I've noticed that the application startup time has begun to slip in recent stable releases. On Linux, I'm seeing pretty good startup time results, but on macOS and Windows, things need to be improved. Some of this is going to be in my direct control and some is not (wish interpreter startup time is out of my hands).
Second, I would like to see the time to initially view a file come down dramatically. TKE lazy loads the contents of a tab currently to help with startup performance which is a good thing; however, if you are switching tabs to a larger file, it can look like the application is locked up for several seconds. Not good.
Third, I need to greatly speed up the rendering time for markup-style languages, including Markdown and its derivatives. The language parsing that is required to highlight HTML/XML/Markdown requires a lot of custom language parsing which is much less efficient than standard built-in parsing support. I have spent a good amount of time focusing on adding functionality for writing documents in these types of languages, but it is all for not if the tool cannot process them quickly.
Fourth, I would like to attempt to speed up operations that are run as text is being entered/deleted. Some functions such as code folding, mismatched bracket highlighting, and comment/string highlighting are a bit expensive in their current implementations. Ultimately, this makes entering and deleting text feel a bit sluggish at times. Additionally, I would like to improve these performance issues so that we can add other "as you type" features such as auto-completion and code linting in the future.
As you can see, our goals are ambitious in this release period. I have been busy coding and analyzing various solutions to some of these problems already, and there is excellent promise that these performance goals can be met. However, I also need to make sure that new code doesn't come at the cost of lots of bugs and/or reduced functionality. I would like version 3.5 to be functionally equivalent if not slightly better than 3.4. To that extent, the 3.5 release date is yet to be determined. I expect this work to take a several months to complete. I don't anticipate the Changelog file for 3.5 to be as lengthy as its predecessors, but you should notice a big difference when using TKE compared to previous versions.
First, application startup performance needs to be improved again. Ideally, I would like to the see the application start in around 2 seconds or less depending on the number of previously opened tabs and the currently displayed file(s). I've noticed that the application startup time has begun to slip in recent stable releases. On Linux, I'm seeing pretty good startup time results, but on macOS and Windows, things need to be improved. Some of this is going to be in my direct control and some is not (wish interpreter startup time is out of my hands).
Second, I would like to see the time to initially view a file come down dramatically. TKE lazy loads the contents of a tab currently to help with startup performance which is a good thing; however, if you are switching tabs to a larger file, it can look like the application is locked up for several seconds. Not good.
Third, I need to greatly speed up the rendering time for markup-style languages, including Markdown and its derivatives. The language parsing that is required to highlight HTML/XML/Markdown requires a lot of custom language parsing which is much less efficient than standard built-in parsing support. I have spent a good amount of time focusing on adding functionality for writing documents in these types of languages, but it is all for not if the tool cannot process them quickly.
Fourth, I would like to attempt to speed up operations that are run as text is being entered/deleted. Some functions such as code folding, mismatched bracket highlighting, and comment/string highlighting are a bit expensive in their current implementations. Ultimately, this makes entering and deleting text feel a bit sluggish at times. Additionally, I would like to improve these performance issues so that we can add other "as you type" features such as auto-completion and code linting in the future.
As you can see, our goals are ambitious in this release period. I have been busy coding and analyzing various solutions to some of these problems already, and there is excellent promise that these performance goals can be met. However, I also need to make sure that new code doesn't come at the cost of lots of bugs and/or reduced functionality. I would like version 3.5 to be functionally equivalent if not slightly better than 3.4. To that extent, the 3.5 release date is yet to be determined. I expect this work to take a several months to complete. I don't anticipate the Changelog file for 3.5 to be as lengthy as its predecessors, but you should notice a big difference when using TKE compared to previous versions.
Summer Roadmap
June 28, 2017
Well, now that the summer is here and version 3.2 is out the door, TKE development is going to slow down a bit. I am planning on getting 3.3 out towards the end of August.
The main focus of the 3.x releases thus far have been a steady improvement to editing features, focusing mostly on Vim editing. This will continue with version 3.3; however, more focus and attention will be placed on the non-Vim editing experience. To that end, I have a new, keyboard-focused selection mode that I'm working on which will greatly improve the selection process. As a result, the Edit / Delete menu will be removed (since selected text can be quickly deleted using the Delete/Backspace key on the keyboard.
Additionally, I have been improving the built-in regression test and this will also continue in the 3.3 release, helping to improve the quality of the release and all future releases.
Of course, if there are any community submitted bugs that need to fixed prior to the end of August, I'll address those and get a smaller release put out there sooner.
The main focus of the 3.x releases thus far have been a steady improvement to editing features, focusing mostly on Vim editing. This will continue with version 3.3; however, more focus and attention will be placed on the non-Vim editing experience. To that end, I have a new, keyboard-focused selection mode that I'm working on which will greatly improve the selection process. As a result, the Edit / Delete menu will be removed (since selected text can be quickly deleted using the Delete/Backspace key on the keyboard.
Additionally, I have been improving the built-in regression test and this will also continue in the 3.3 release, helping to improve the quality of the release and all future releases.
Of course, if there are any community submitted bugs that need to fixed prior to the end of August, I'll address those and get a smaller release put out there sooner.