Autographe Recap #1

Autographe, as an app idea, keeps evolving as I do my exploration. This is a brief recap about where we are today and where we’re heading.

The last incarnation was a programmers text editor macOS app. Autographe now is a “companion app” to Xcode.

More than three months and still nothing to show!

Yes, already morer than three months into this project and still there’s nothing to show. Of course, I could have just fired some LLM and asked it to at least do the MVP for me, but that’s not in my agenda. I’m doing this project to explore, learn, practice and have fun. Do you find “coding” using an LLM fun?

Autographe started as a prose writers macOS app. I always dreamed to be a writer (lol) and I thought to myself this project will be huge: many writers want to enter the flow state asap, so why not give them a similar experience to Spacemacs in a gorgeous macOS shell? Folks who use Vim/Emacs all the time know about the productivity gains we get with a keyboard first text editor.

While doing my exploration of the subject, I hit the first major roadblock: text editing. I never thought there’s so much computer science involved in text editing. Compared to it, doing iOS apps is like playing Legos. I was so naive.

Text editing is HARD!

Text editing is very hard, and early on, that was the crazy thing that kept my fire on to develop the app; I liked the challenge more than anything else, partly because I didn’t have a real appreciation of the hard parts, being naive served me well during this phase.

I’ve read articles that proved that Text Rendering Hates You, that Text editing hates you too, that text editing is a Craft and hence needs long time to get right. But the ignorant that I was kept digging, till I read the xi-editor retrospective by Raph Levien, and there I realized that maybe I should learn from the pros and just stop my crazy endeavor, because after all, I’m not 15 anymore and I don’t want to spend five years building a text editor just to get to the same conclusions.

Briefly, this is what happened:

• I started by researching text editing technically, in general.
• Then I did some research on what the Apple/macOS ecosystem has to offer: TextKit 2, the most complete text engine ever made, that is 30 years old and needs basically a PhD. to get the hang of it.
• I started to identify the feature set I wanted, then some tiny projects to explore what interacting with TextKit 2 really meant. Then soon after that I got a window that has a text editing pane inside, and I could programmatically do one or two glyph manipulation inside it. The realization: why not doing the extra mile and build a programmers text editor?!
• Autographe’s new incarnation now is a programmers text editor that aims to have the sole of Doom Emacs/Spacemacs and the shell of a native macOS app.
• Yes, source code rendering is much simpler because there’s not big glyph manipulation as everything is monospaced; but it has its own complexity: syntax highlighting and semantic navigation (ok we have Tree-sitter), code intelligence (ok we have LSP), code building and running (ok let’s start just with Swift and SwiftPM).
• Wiring those libraries/tools into a simple AppKit window wasn’t simple, but I got a working POC. I was so happy.
• Time to do some polish then. And that was the time the complexity of text editing hit me again: even with premade libraries and tools, making them work to get a simple feature of what a good text editor has is a lot of work. Surfacing Tree-sitter tree into TextKit2 is a lot of work, making the app core communicate seamlessly with an LSP server (SourceKit-lsp for starters) via JSON-RPC has its own quirks, and implementing text editing idioms that we take for granted (adding closing brackets automatically, smart indenting code.. etc) need to be implemented.
• I was very tired. Took some rest (two or three days), then just to change a bit, I started exploring text editing in pure C! Why? Because Tree-sitter is in C, and C must have the most battle tested libs and APIs out there; so I said to myself maybe it will be easier! Well, not at all, because GUI in C, which has nothing to do with text editing, is totally a whole new story. What about Rust and “cosmic-text”? I was clearly with no compass at this phase and finally thought of abandoning my dream project.

What about Xcode?

I took some rest, two days. I live in Sète - France, a beautiful Mediterranean town, so it wasn’t that hard to go for a lovely walk in town or go swimming at the beach with the family.

I do mostly Swift/SwiftUI development, and I do it in Doom Emacs not Xcode. I never liked Xcode as many Apple platforms developers; but my Autographe endeavor taught me to respect established programmers editors. All of them. And Xcode was one of the legends in this space.

Back to my desk, I fired Xcode to try to feel how its text editing experience was (hey, I know a bit or two about text editing internals now!), I loaded one of my projects, activated Vim mode and started playing; then something clicked in my head: why creating a brand new editor when we have Xcode itself? I mean, maybe I can develop my whole Doom Emacs/Spacemacs UX around Xcode as a plugin? My eyes were wide open, and enthusiasm was back!

After a couple of Web searches I learned that Xcode plugins is a thing of the past, no more a thing since Xcode 8!

But the search led me to something I heard of, but never touched directly: The Accessibility API. I know that Apple put enormous efforts into accessibility, and this is not new, it was since the NS days. What I didn’t know, and this one was mind blowing for me (I still consider myself new to the Swift/Apple ecosystem), was the fact that we can drive whole apps with the Accessibility API!

That was just huge for me, and reading more about it, I discovered that even Xcode is open to that API and hence theoretically I can drive some of its functionality with the accessibility API to mimick the keyboard driven workflows of Doom Emacs/Vim/Spacemacs.

Imagine if I could develop a simple macOS app, that is loaded in the background (like Alfred), and it awaits that Xcode is in front to activate itself, and when I hit the Which-key, the app should give me the bottom panel like Spacemacs’s as an overlay on top of Xcode itself, then if I tap some key combination like which-key b b it triggers a project build, as if I hit Command b!

I now have a clear exploration to do, and if it sounds feasible and sound, I believe it will be the last incarnation of Autographe: augmenting the Xcode experience instead of rolling my own.