I just added the ability to diff directories in gap. It makes it so much more usable via git difftool -d since now you can view all the diffs in a single invocation of gap.

Over the past week I've been working on a GUI diff tool called 'gap' for the HM Essentials jam. It has been a lot of fun and I've actually been using it as a replacement for git diff! (seen in video)

Further, the code is also open source: https://github.com/cdacamar/gap

The code shares a lot in common with fred (though an older snapshot). If you're curious about how I write HM software, feel free to take a look!

When I said this was the last update to &gap , I wasn't lying, but I do have one other thing I'd like to share... gap is also open source! https://github.com/cdacamar/gap

Why is this interesting? gap is using much of the same tech that fred is built on: custom OS layers, renderers, arenas, etc. If you're curious about how I write HM C++ or just generally curious about some of the bones behind fred, feel free to take a look!

Note: the base layers are older snapshots of what is currently in fred.

One final update to &gap . As one more handy feature for usability, I added the ability to drag-and-drop files onto a specific diff-side to retarget that side. If you need to compare the left-hand side to another file on disk, its as easy as grabbing and dragging the new compare target onto the right-hand side.

And just like I was hoping for when I started &gap , I can now use it for git diff when viewing local repo changes!

Making diffs more intuitive was the work item for today. VSCode, Azure DevOps, etc. have their own diff algorithm that does some pretty useful stuff to help guide the reader into context. This change to &gap helps to provide even more visibility into inner-diffs by offering a word-based or character-based inner-diff. Sometimes one or the other can help you see changes a little bit better.
First image: word-based inner-diff.
Second image: character-based inner-diff.

I added context window narrowing to &gap . This is very helpful for skipping large common areas in bigger files.

A lot more functionality hooked up including the, annoyingly difficult to implement, sub-diff regions. &gap

My little diff viewer &gap is starting to take shape!!

I have been struggling for a long time trying to figure out what makes a good plugin system for editors. I've experimented with compiled plugins that are loaded via a DLL interface. I've experimented with interpreted languages (e.g. Lua). I've even experimented with trying to compose editor commands via key chords alone. Of all the systems, I came to a realization: A good plugin system requires a compiler. Adding to that, a good plugin system in an editor must ship with a builtin compiler to reduce as much friction as possible.

With the above in mind, I think I chose an insane, but fun path: ship my editor with a C compiler. We all love C, and it's the language with the largest possible surface area for interop with everything else on the system. As such, I now ship my editor, fred, with TCC that generates an executable code page for the editor to hook into for plugin building!

I can't explain it better than this: https://www.youtube.com/watch?v=bqU7ghs9ou0 .

It's actually crazy how much you miss something until you don't have it anymore. I spent a day implementing line guides in my editor because I realized how much I relied on their visual nuance in VSCode. It's actually a really interesting problem to implement these because they're effectively regions of code guided by some user-defined indentation specification. It's actually a perfect fit for interval trees! Which is what I used here to implement them.

A text editor which can edit text is really useful. But an editor that can interact more intimately with the system means it can replace entire tools for me. In this case, I found myself going to the terminal to execute commands, edit some text with my editor, then tab back to exeucte some more commands. What if I could just do both from in the editor? That's what inspired me to create the command executor window in my editor. From there I can run... anything! The outputs are piped to separate displays so I don't get the problem of stderr and stdout mixing together, making errors more difficult to see and all wrapped in a very nice async IO system.

I spent a lot of time this weekend reworking the way panels work in my editor. It always bothered me that I could only split panels in one direction, it dramatically limited the number of ways I could view text. This past weekend I went through the effort of making a proper panel tree which could be infinitely sub-divided, combined, and split.

I suck at typing/remembering names of things. I rely on IntelliSense quite a bit, and I've wanted to bring a similar experience to my editor for a long time. Now I finally have a framework to do that! Here, I do the dumbest thing possible: collect up all words which look like identifiers and throw them up as a suggestion, but the most important thing is reusing my fuzzy matching algorithm to quickly filter through them in real time. Even on large million-line files this filtering seems to be fast enough! It also has a config option to disable it if necessary. Eventually I want the editor to have more code smartness to offer up suggestions based on context. That's a tomorrow problem though 🙂.

This is something I've been designing and working on the past few days. I have recently become frustrated with navigating the TOML config in my text editor. There are simply too many options now, I never remember their names, and I feel like toggling something should just be easy. I have a couple keybinds to accommodate common things, such as enabling/disabling line numbers, but I wanted something a bit more uniform and expressive. I finally came to the conclusion that I needed something like VSCode's UI options, because I like it. My new config explorer is filterable, you can easily toggle things, and I finally have a color picker!