Something changed at v0.7.0, and I can describe it precisely: I stopped opening Xcode in the morning.

For months, the routine was fixed. Coffee, Xcode, texspark’s source, chase whatever broke yesterday. The book — the entire reason texspark exists — got the leftovers: an evening hour here, a guilty weekend session there. The tool was eating the work it was built for.

Somewhere around v0.7.0, the ratio flipped.

Once the big architecture settled, my days became writing days. But here’s the part I didn’t expect: the writing became the QA department. Hours of real manuscript work put the editor into situations no test plan would have invented — and out came the bugs. Small ones. Strange ones. The kind you only meet at paragraph three hundred: a fold that misbehaves in one specific nesting, a scroll that drifts by a hair after a particular build sequence, an outline entry that’s right in every way except one. Each one small, each one irritating, each one findable only by actually living in the app.

So the rhythm now is: write, hit something odd, note it, keep writing. Fix the batch when it’s worth a detour. The commit log shows it — June was a wall of commits at hours I’m not proud of; July is a steady trickle of small, weird, satisfying fixes. Meanwhile the manuscript’s word count, flat for weeks, has started climbing like it finally got permission.

I won’t pretend texspark is finished. v0.7.0 is not v1.0; the roadmap still has real items on it. But there’s a threshold every tool-building detour eventually meets: the moment the tool recedes into the background and only the work remains — surfacing just often enough to hand you a bug report written in your own manuscript.

Three chapters down, twelve to go. The editor works. Back to the book — which is, it turns out, also the test suite.

A random thought hit me the other day: if the information is identical, which human language requires the fewest LLM tokens? You’d think this is a linguistics question. It turns out to be an economics question wearing a linguistics costume.

The intuition

Chinese should win, right? 猫 is one character; “cat” is three. Classical information-density arguments say logographic scripts pack more meaning per glyph. If tokens tracked meaning, dense languages would be cheap.

The reality

Tokens don’t track meaning. They track what the tokenizer saw during training — and tokenizers grew up reading mostly English.

Tokenizers don’t operate on characters; they operate on sub-word units, so character-level efficiency doesn’t automatically translate to token efficiency. A Chinese character can get fragmented into multiple tokens — sometimes one token per part of a character — because the byte-level vocabulary never merged it into a unit. Meanwhile “the” gets its own cozy token because English dominates the training corpus. arXivMedium

The numbers bear it out. A study using 2 million professionally translated sentences found that every CJK language uses more tokens than English — no exceptions. On GPT’s cl100k_base tokenizer, Chinese pays roughly 15% more tokens for equivalent content, and low-resource languages fare far worse — Khmer, Lao, and Burmese show notably high length ratios on most open-source LLMs. arxivGitHub

So English wins?

On most Western tokenizers, yes — but for the least satisfying reason possible: home-field advantage. The proof: GLM’s Chinese-native tokenizer inverts the pattern, producing fewer tokens for Chinese than English (ratio 0.923). Same languages, opposite winner. The answer to “which language is most efficient” is: whichever one your tokenizer grew up speaking. GitHub

(For fun: one recent paper asked whether Sanskrit — famously compact — beats everyone. With bias-controlled tokenizers trained at equal vocabulary sizes, Sanskrit does show superior density. The ancient grammarians would be pleased with their compression ratio.) Sicheng Ouyang

Why a LaTeX person cares

I write in Korean, English, and LaTeX daily, often through texspark’s AI panel — where the attach-document toggle ships my source to a model with a 60 KB cap and a token bill. My source files are trilingual: Korean prose, English terms, LaTeX markup. Every \begin{equation} is a flat tax in any language.

The practical takeaway is almost embarrassing: prompting in English is usually cheapest, not because English is better, but because the meter was calibrated in it. Somewhere in that fact is a whole essay about soft power. This is not that essay. This was just a random thought that turned out to have a real answer.

I’ve noticed something about texspark’s bug reports lately — most of them filed by me, to me, at unreasonable hours: debugging keeps getting more complicated.

Early on, bugs were honest. The app crashed on launch. The PDF didn’t load. Autocomplete inserted the wrong text, visibly, right in front of you. You could reproduce them in five seconds, fix them in an hour, and feel like a genius before lunch.

The current crop is different.

The recent specimen: code folding. Fold a section and, sometimes, the text below it drew on top of the folded region — two layers of document, overlapping like a double-exposed photograph. Ugly, obvious, clearly wrong.

And it would not reproduce.

That was the real problem. Not the glitch itself — the fact that I couldn’t summon it. Same file, same folds, same steps: clean. Then an hour later, doing nothing special, there it was again. A bug you can’t reproduce is a bug you can’t even begin to fix; you’re not debugging anymore, you’re waiting for a ghost to walk past.

When it became clear the ghost lived somewhere deep in the text layout stack, the fix stopped being a fix and became a decision: I tore out the TextKit layer entirely and rebuilt on a different foundation. Not four lines. Not forty. The whole floor.

Here’s the reframe that keeps me sane: this is what progress looks like. Easy bugs are a property of immature software — they’re everywhere, so you trip over them constantly. When the remaining bugs are non-deterministic rendering ghosts that force architectural surgery, it means the five-second bugs are gone. The floor got raised. The weird stuff is what’s left because everything normal already works.

There’s a name for this in quality engineering — surviving bugs are survivors for a reason. They live in the corners, in timing and layout internals, precisely because everything in the open has been shot.

So: the debugging is slower now, the git log less heroic, and one commit last week just says “replace text layout system.” And that’s the best evidence I have that texspark is becoming a real, grown-up piece of software.

The bugs are getting harder. Good.

It starts innocently. Someone sends you a figure for the paper — a .png, 800×600, screenshot of a matplotlib window. You paste it in, compile, zoom to 400% the way you always do, and there it is: the blur. The soft, fuzzy edges of a rasterized line. And something in you dies a little.

Congratulations. You have the condition. There’s no cure.

Symptoms

You know you have it when:

• You can identify, from across a conference hall, which posters were made in PowerPoint. The pixelated axis labels call to you.
• You’ve said the phrase “can you send me the PDF version?” more times than you’ve said “happy birthday.”
• Your matplotlib scripts end in savefig('fig3.pdf') and have for a decade. You don’t remember choosing this. There was never a choice.
• You’ve zoomed into your own compiled PDF to 6400% — not to check anything. Just to watch the curve stay perfect. Just to feel something.
• TikZ has made you cry exactly twice: once learning it, once realizing you can never go back.

The pathology

Here’s the thing — the obsession is correct. That’s what makes it incurable. A raster image is a lie told at one resolution. A vector image is the truth: the actual curve, the actual glyph, described mathematically, rendered perfectly at any scale, printed at any DPI, forever.

LaTeX people were always going to fall hard for this. The entire premise of TeX is that a document is a program, not a picture — so of course its users demand that figures be equations too. Pixels are someone else’s compromise.

The suffering

The condition has costs. You will spend forty minutes converting a collaborator’s .jpg chart into pgfplots — “it’s just cleaner this way” — for a figure that appears at 4cm wide. You will maintain strong opinions about PDF vs EPS. You will see a beautiful, useful diagram on the web and feel genuine grief that it’s a PNG.

And journals will rasterize your perfect figures in production anyway, and you will never emotionally recover.

For the record

My entire book — every figure, every diagram — is vector. Some of those figures took longer than the sections they illustrate. I regret nothing. At 6400% zoom, the curves are perfect.

Nobody will ever zoom to 6400%.

They’re perfect anyway.

Let me establish my credentials for this comparison: my 2019 PhD dissertation was written in Texmaker. Every paper I’ve published — Texmaker. Every Beamer slide I’ve lectured from, for years of teaching — Texmaker. Ten-plus years, one editor. I didn’t evaluate alternatives annually like a responsible consumer. I just opened Texmaker every morning and wrote. That’s not usage; that’s a relationship.

So this is not a competitor dunking on a rival. This is a decade-long user explaining, with some tenderness, why he eventually built his way out.

What Texmaker got right

Among editors that compile locally, Texmaker had no real rival for years. Free, stable, everything in one window: editor, PDF viewer, structure panel, Quick Build one keystroke away. It ran the same on the Mac in my office and the Windows machine in the lab — for a grad student moving between machines, cross-platform wasn’t a feature, it was oxygen.

There’s a reason my entire academic output lives in .tex files shaped by its conventions. It never lost my work. It compiled what I told it to compile. For ten years, that was enough.

The itch that never went away

But a decade of daily use gives you a very specific list. Not of bugs — of almosts.

On a Mac, Texmaker always felt like a visitor. It’s a Qt app: keyboard shortcuts that were near-standard but not quite, font rendering a half-step off from every native app beside it. The structure panel stopped at subsubsection — I once patched the source myself to make it show paragraphs. Multi-file projects meant manually declaring a master document and remembering you’d done so. The PDF viewer synced, but with the enthusiasm of an employee near retirement.

None of these were dealbreakers. That’s precisely why they lasted ten years. Every single one was small enough to shrug off on any given day — and together they formed a low, permanent hum of friction I stopped consciously hearing.

So what is texspark, really?

The honest answer: texspark is my list of Texmaker itches, implemented one by one.

Native macOS text engine, so shortcuts and rendering simply match the rest of the system. An outline that goes all the way down and follows \include chains recursively — no patch required this time. A build target you set once (or that sets itself when you build from a sub-file). SyncTeX that jumps both directions across a multi-file project like it means it. Plus the things 2026 makes possible: a minimap, an AI panel beside the PDF.

Every headline feature traces back to a specific moment of “…almost” in my Texmaker years. It’s less a competitor and more a reply, ten years in the making.

The honest ledger

What Texmaker still has over texspark: it’s free, and it runs on Windows and Linux. If you live across platforms, or free is the requirement, Texmaker remains what it’s always been — the dependable answer. I’d never argue otherwise; I have a dissertation’s worth of reasons not to.

But if you’re on a Mac, and you know that hum I’m describing — the accumulated almost of a great tool that was never quite of your platform — that’s the exact gap texspark was built to close.

Fourteen-day trial at texspark.io. From one longtime Texmaker user to, quite possibly, another.

Dear stranger,

At 5:33 this morning — my time, not yours; for you it was probably a reasonable evening hour — you downloaded texspark. Safari, macOS, an IP address somewhere in Poland. That’s everything I know about you, and I’ve already thought about you more than is probably healthy.

You should understand the context. My download log so far reads like a directory of robots: Googlebot, AhrefsBot, OpenAI’s crawler, something called Dataprovider.com. My Telegram bot pings me for every download, and for weeks I’ve opened each notification the way you open junk mail — already knowing.

Then you. A real browser. A real Mac. A real person, presumably, with a real reason to want a LaTeX editor at that hour.

So now I’m wondering. Are you a PhD student with a deadline? A professor, like me, writing lecture notes? Did you find me through a search for something Texmaker-related, or did one of my tweets into the void actually land? Did the app launch fine? Did the trial banner make sense? Is it — and I ask this with my whole heart — working?

You have fourteen days. Somewhere around July 25th, you’ll decide whether texspark is worth keeping. No pressure. But here’s a small confession: the Purchase button isn’t even live yet — the business registration paperwork is still winding its way through the system. So I’ll make you a deal: before your trial runs out, I’ll ship a new release with the checkout actually working. You hold up your end by compiling something; I’ll hold up mine.

If anything breaks: support@texspark.io. It goes straight to me. There is, in the most literal sense, nobody else.

Powodzenia,
Jacob

Let’s get the honest part out of the way first: if you’re co-writing a paper with three collaborators who all need to edit the same file this week, use Overleaf. That’s what it’s for, it’s genuinely excellent at it, and no desktop app — mine included — replaces real-time collaboration in a browser.

This post is about the other 80% of LaTeX writing: the part you do alone.

What Overleaf is

A browser-based LaTeX environment. Nothing to install, TeX Live lives on their servers, your collaborators see your keystrokes live. For shared papers, class assignments, and “I just need to compile this once,” it’s the obvious answer.

Where the browser starts to pinch

Write in Overleaf daily — alone — and small things accumulate.

The connection. No wifi, no writing. Train, plane, café with hostile internet: your manuscript is a loading spinner.

Compile queues. On the free plan your document compiles on someone else’s schedule, with a timeout. A book-length project with TikZ figures will meet that timeout personally.

It’s a tab. Your editor lives between Gmail and forty other tabs, with browser shortcuts fighting editor shortcuts. ⌘W closes your chapter, not your document.

Your files aren’t files. They live in Overleaf’s storage. Git integration exists behind a paywall, but your local Spotlight, backups, and scripts can’t see your manuscript.

The subscription. Overleaf’s serious features — longer compile times, Git, track changes — are a recurring cost, forever.

What a native editor changes

texspark is the opposite set of trade-offs. Your files are on your disk — versioned, backed up, greppable. Compilation is your Mac’s TeX Live: no queue, no timeout, works on a plane. The editor is a real macOS app: system IME for Korean/Japanese/Chinese input, native Find bar, shortcuts that don’t collide with a browser. SyncTeX jumps both directions across multi-file projects, the outline follows your \include chain, and an AI panel sits where Overleaf has none meaningful. One-time license instead of a subscription.

What texspark doesn’t do: real-time collaboration. There’s no shared cursor, no comment threads. If that’s your daily reality, see paragraph one.

The actual decision

It’s not “which is better” — it’s where does your writing happen:

• Multiple people, one document, this week → Overleaf
• You, your Mac, a long manuscript → a native editor wins every day you sit down

Plenty of people use both: Overleaf for the shared paper, texspark for the thesis. Files move between them freely — it’s all just .tex.

Try the local side of the argument: texspark.io, 14-day full trial, no signup.

One month into writing the book, I asked Claude a question I probably shouldn’t have: at this pace, when do I finish?

It answered without hesitation, the way only something with no stake in the answer can. First draft: end of this year. Publication: early next year. On a bookstore shelf: next summer.

Next summer.

Here’s the strange part: I wasn’t discouraged. There’s something clarifying about a timeline with zero flattery in it. A friend would have said “it’ll be done before you know it.” Claude just ran the numbers.

And the numbers are fine. Books take the time they take — the whole premise of Machine Learning from Scratch is building things properly from the ground up. It would be embarrassing if the book itself were an exception.

Back to chapter 5. See you at the bookstore. Apparently.

Every LaTeX writer has one. You might not have chosen it consciously, but somewhere along your first hundred equations, your fingers picked a default — and now it’s less a technical decision than a personality trait.

Here’s the lineup.

equation

The institutional choice. Numbered, respectable, exactly one equation at a time. People who default to equation cite theorems by number, keep their references in order, and probably have a .bib file that doesn’t embarrass them. The paperwork of mathematics, filled out correctly.

align

The workhorse. Once you’ve derived anything across multiple lines — an & here, a \\ there — you never quite go back. align people are process people: they want you to see how they got there, step by step, aligned at the equals sign like a well-organized argument.

The dark side: align users have all, at some point, used it for a single equation out of pure muscle memory.

gather

The rarest breed. Multiple equations, centered, no alignment — gather says “these belong together, but I refuse to impose a relationship on them.” Honestly, I respect it. Choosing gather means you know align exists and decided your equations deserve to stand on their own.

\[ ... \]

The minimalist. No number, no name, no ceremony — just math, displayed, gone. \[ people write quickly and don’t look back. They’ll tell you most equations don’t need numbers, and they’re right, and it’s still slightly unsettling how little they care.

(If you write $$ ... $$ instead: I see you. TeX purists would like a word, but I see you.)

eqnarray

Ah. So you learned LaTeX from a thesis template last touched in 2003, passed down through your lab like an heirloom nobody examines too closely.

Here’s the thing nobody in that lab told you: eqnarray has been considered obsolete for decades. The spacing around the equals sign is subtly, famously wrong — wide enough that amsmath’s documentation politely pretends it doesn’t exist. Every eqnarray in the wild is a small archaeological record of how LaTeX knowledge actually spreads: not through documentation, but through inherited templates and the phrase “just copy what the last student did.”

Switch to align. It takes five minutes. Your equals signs will thank you.

(If you knew all this and use eqnarray anyway: you are a chaos agent, and I’d love to know what else is in your preamble.)

For the record

I’m a gather person. I like my equations centered, independent, and free of imposed relationships — which, now that I write it down, may explain more about me than about my typesetting.

What’s yours?

---

Short answer: you can open a .tex file in Xcode. You can also eat soup with a fork. Nobody’s stopping you.

I understand the impulse, though. If you’re a Mac developer who suddenly needs to write a paper — or an academic who happens to live in Xcode — the question is natural. You already have a professional editor installed. It has syntax highlighting, a file navigator, and find-and-replace that works. Why install anything else?

Here’s what happens when you try.

What Xcode gives you

Xcode will treat your .tex file as plain text. You get the editor surface — which, to be fair, is excellent. Native text engine, flawless IME handling for Korean, Japanese, and Chinese, buttery scrolling, every macOS keyboard convention you already know. The bones are good, because the bones are AppKit.

What Xcode doesn’t give you

Everything else.

There’s no LaTeX syntax highlighting — your \section commands sit there in monochrome. No build integration: you’ll be alt-tabbing to Terminal to run xelatex, then to Preview to see the PDF, then back to Xcode to find your place again. No SyncTeX, so “where does this paragraph appear in the PDF?” is a question you answer by scrolling. No document outline, no autocompletion for the four hundred LaTeX commands you half-remember, no error list that jumps to the offending line.

You can bolt some of this together with Run Script build phases and external tools. People have — there are decade-old Stack Exchange threads with heroic Xcode-LaTeX configurations, and they all read like instructions for teaching a horse to drive.

The instinct is right, though

Wanting to write LaTeX in a real native Mac app — with the system text engine, real IME support, and keyboard shortcuts that match every other app you use — is exactly the right instinct. Xcode just isn’t the app.

That’s roughly why I built texspark. I wanted the part of Xcode that’s good (the native editor feel) attached to the parts LaTeX actually needs: one-keystroke builds with any engine, SyncTeX in both directions, an outline that follows \include chains, autocompletion that knows the difference between \ref{ and \begin{, and an error list where clicking a row lands you on the line that broke. Plus an AI panel, because it’s 2026 and half my debugging is asking Claude why my table is off the page.

One-time license, 14-day full trial, and it weighs a lot less than Xcode.

If you still want to use Xcode

Genuinely, no judgment — here’s the minimal setup: install MacTeX, add a Run Script build phase calling xelatex -interaction=nonstopmode "$FILE", and keep Preview open next to it. It works. For a two-page document, it’s fine.

For a thesis, come back to this post. I’ll be here.