It's still right around the start of a new year, making it a great time (psychologically - for me) to organize thoughts and examine progress on 4coder.

Goal
My primary driving goal right now is to get the current version stabilized, build up a few more key features, retire this version and move on to updating the 4coder infrastructure, documentation, and then get on to a new major version.

This is basically the same goal I set last year. I'm not quite on the pace to completing the goal I hoped I would be but I'm also not terribly far off. The biggest problem has been the size of the project growing out of control. Usually my pattern is to alternate between major changes and new features one build, and major cleanup and bug fixes the next build, but the last few builds the cleanup and bug fixes haven't been enough. Problems are coming from all sorts of directions:

  • File change notifications are still problematic on every OS
  • The OpenGL renderer exhibits blinking bugs on Windows
  • Mac dropped support for OpenGL
  • There are different keyboard bugs on every OS
  • Good DPI scaling is becoming a necessity, but works a little differently on each OS
  • The core has a number of bugs relating to configuration that have been hard to nail down
  • There are a few crash bugs in the core that have eluded my testing for the last few builds
  • The customization layer has gotten complex enough that many bug reports just come down to a problem caused by the API complexity rather than a bug in the core or an obvious mistake by the author of the customization code
  • The build and packaging system for the 12 different files I distribute with each build has gotten very hard to maintain (most egregiously the 32-bit Linux versions stopped working silently in 4.0.29 and I couldn't recover them for 4.0.30 thanks to Linux package/dependency/linkage problems)


Stabilizing and fixing everything has to be task number one this year, but just getting a handle on everything has proven to be very difficult. 2018 was the first year I tried to simultaneously support three operating systems for every build all year, and I think that is a part of what has slowed me down so drastically. This gets us to the big change I want to introduce to my work flow for 2019:

New Approach to Builds
Starting with the next build I will not be updating all versions for all OSes with each build. The next few builds will all be bug fixes for Windows. Then after that I will do a round of bug fixes on Mac, and then on Linux.

After an initial phase of focusing on one OS at a time for stabilizing everything, I will evaluate whether I want to continue to stick to one OS at a time or not. I suspect that if I did limit most builds to just update the files for one OS I could probably move a lot more quickly and confidently than I could in 2018. I recognize that this might leave valuable users waiting for a while to get the newest features on the OS they are using, so I want to hear back from anyone who is concerned about this. I think this method will benefit everyone in the long run with more stable builds and faster development and iteration on the core, but if you disagree for any reason or have specific concerns about how this might effect you that could be mitigated, I want to hear about them. I'm still just considering this.

Final New Features
Once I'm past the stabilization problems, I still have a few big changes I want to get into this major version. My to do list for this year is mostly just inherited from last year:

  1. Undo-Redo Upgrade
    The Undo-Redo system is still old, messy, and all locked up in the core. There are three big changes to be made:
    • Expose Undo-Redo through the customization API.
    • Extend Undo-Redo information to support per-buffer and global Undo-Redo.
    • Extend the Undo-Redo with an easy to use grouping mechanism for putting multiple edits under a single group to be undone or redone together.

  2. Event Handling Upgrade
    Last year I did some work on how events are processed in the core and triggered in the custom layer. In that process I formed a vision of a more unified communication channel from the core to the custom layer. Currently the core can trigger a command from a command map, call a hook, and on init call the "get_binding_data" procedure, all of which fit together very differently. I think that both sides, the core and the custom layer, will be better off with a more unified vocabulary of events.
  3. Keyboard Input Handling
    The keyboard handling input right now is poor for non-English users, and is especially bad for any language that relies on IME (or similar) input. In order to really represent input properly the interface used for specifying bindings has to change. I'm putting this off to the end of this major version because of the fact that it will break all custom bindings. Hopefully, anyone who doesn't need the improved input will be able to skip this build.


Conclusion
With that I've explained my current thoughts on the 2019 road map. Questions and comments are encouraged!

Thanks everyone!