4coder November - The Detailed Todo List
First things first, this entire blog post was written in 4coder on a Mac! It was the first dog fooding I did for the new Mac version of 4coder. If you are reading this, then the first test must have gone pretty well!
Here on the first full week of 4coder November, I am writing, for you, a full-detail list of the things I am working on this month. If your #1 feature request or issue is not on this list let me know, I don't want to forget anything big! Also I won't necessarily get to everything on this list in one month, but I will try to sort important points to the top.
I want to get a new build out to get 4coder on Mac out ASAP. I still don't have file change detection working, which I will need before I launch it. (Side note, this has been one of the hardest parts of the port on every platform.)
In addition to core platform features the new build will feature multiple default bindings that users can switch between. This change is forced by the "Mac keyboard situation".
On Windows and Linux it was possible to use exactly the same key bindings, but between Mac keyboards being laid out differently and featuring a prominent "Command" modifier, and the Mac OS hijacking such a wildly different set of key combinations, it's just not possible for the entire set of key bindings to be the same on Mac.
On top of this, even making the key combinations similar is problematic because every other application on a Mac uses the Mac conventions where the Command key takes over most (but not all) of the key combinations that usually go to control. Therefore I plan on supporting a command mapping that will be familiar to Mac users, and a command mapping that will be more similar to the maps on other OSes.
Category: Behavior Cleanup
After a couple months of not touching 4coder, I have a back log of little requests and annoying bugs.
In particular the graphics is pretty poorly behaved, and it's also pretty poorly organized in the code. I plan to redo everything in the graphics system "by the book"; there will be no more legacy gl calls, no more legacy contexts, etc.
There are also some issues with file handling right now. 4coder doesn't really know that the OS can have read only files, and it doesn't do anything smart about it. It can't warn you when it failed to save a file. It can't delete, rename, or copy files (at least not conveniently). All of that will be upgraded.
The 4coder font manageament system has gotten gradually less hacky little-by-little since day one. I would like to put this issue to rest and get fonts straight from the OS font path, instead of shipping open source fonts with 4coder.
When 4coder launches child processes and reads the output from a pipe it usually works, but in some complicated cases it misses and reorders the output. I would like to investigate this and get everything operating "by the book" for pipe reading on every platform.
Then there are some small convenience commands that I have noticed are missing from 4coder. For example, the token killing command I have now would be much more useful if it didn't leave behind whitespace after repeated uses, and it would be nice to have a token rightward deleting command too. The scope manipulating commands have been sitting around not-quite-ready-to-publish for a while, and I think it's time that I fix them up and get them out too.
Right now the undo/redo system is a bit of a hodge podge of old experiments. The undo/redo behavior doesn't need to change hardly at all (in my opinion) but I need to clean it up. I also plan to expose the undo/redo system to the customization API so that it can be fully integrated/upgraded in the customization code too.
Category: Customization of Keyword Highlighting
There is already a custom keyword system in 4coder, but it's somewhat difficult to use, and it is locked up in the customization API. I think this is important enough that it should get it's own dedicated config data. That way the free version will also support keyword lists.
In addition to that, I want to support keyword groups with different colors per group. Finally I want to support coloring specific strings regardless of how they parse. For instance coloring my TODO/NOTE/HACK comments like I used to when I switched over to emacs and Casey's .emacs file from handmade hero. Such a feature would also allow me to make the formatting of the jump location buffers a little prettier.
Category: Command Mapping Improvements
I already mentioned this a little bit in relation to the Mac keyboard problems, but in the next few builds I plan to start supporting multiple default bindings. As I mentioend in it's section, the Mac port forced this decision on me, but while I am supporting multiple default bindings I might as well get to the long standing request to support a Windows/Sublime style of editing with a single cursor and highlighted selection region. My Vim knowledge is still not great enough to do my own Vim version, so that's not something I am planning on getting to yet (sorry :/)
On top of having multiple command maps I want to improve accessibility for non-US keyboard layouts by making the default bindings work decently for their keyboards. There are a few possible solutions to this problem and I need to do more research on it, but the goal is to make this move without changing how the convenient ASCII-centric bindings are specified now. Either I will be translating those to some kind of virtual keys, or translating virtual keys to US ASCII keys for the purpose of non-character-writing commands, or something else like this. (Suggestions welcome!)
Additional note: With the single cursor and highlighted selection system, I will also attempt to add a Sublime like multi-cursor system. It is in theory not out of the question.
Category: Productiviy Acceleration Research
I would like to spend some time testing the speed at which I can perform certain tasks, and studying what features I can add to 4coder to perform those tasks more quickly. This part is, perhaps, mostly for me, as the things I do to hyper-accelerate my coding might overfit the commands to my own style, so it might not all get integrated into a default command mapping, but increasing the speed at which I can work will also increase the speed at which I work on 4coder in the future.
Additionally, I plan to record/live stream as much of this part of the month's work as I can, and I wanted to pick somehting a little more interesting than checking off little todos for the purpose of streaming.
Category: Buffer Algorithms Upgrade
My work on upgrading the buffer algorithms, in particular encoding, line layout, rendering and coordinate conversions, has been a long time coming. A large part of these problems is already solved and just awaiting the time when I get the solutions fully integrated into 4coder. I am hopeful that by the end of the month this change will be published, but this is where my level of confidence in my ability to get this far starts getting pretty shaky.
If I do get this upgrade finished, the new features I will be able to build on top of it will eventually include:
UTF-8 Buffer Mode
UTF-16 Buffer Mode
Binary Buffer Mode
Strict-ASCII Buffer Mode
Programmable Virtual Whitespace Wrapping and Indenting
Background File Loading (no more hangs on batch loads)
The buffer upgrade is also the first step toward implementing virtual text which would support:
In-Line Compilation Error Ghosts
Word Completion Ghosts
Generic Programmable Text Ghosting & Hiding
Category: Blue Skies
At this point we are, very probably, well beyond the limit of what I can possibly do in one month. However I want this to be a complete list of things I want to do, so this is all the rest of the stuff I want to do.
At some point the current customization API will be mostly retired and replaced with something better. The new API would be structured in a way that makes callbacks completely unnecessary (but I would leave a transition path from old customization code to the new system with helper libraries). The new API would put the custom layer in the driver's seat with an event loop structure. On top of this the API would support programmable GUIs so that literally no behaviors would need to exist on the core side anymore. At that point 4coder would serve as an OS abstraction and buffer manipulating and rendering engine, and anything could be built on top of it. With this upgrade the dream of an in-4coder debugger would be the #1 next thing on the todo list.
So That's It!
That's all I've got for now! I can't wait to hear about all the details I missed in the comments and in my email inbox. It's time I got back to the Mac port. And look at this! I have just managed to write this whole post on the 4coder Mac version!