• AI answers no longer get cut off, and the model list is live

    Longer replies from the AI assistant used to stop mid-sentence at a fixed token limit, and the model menu was a short, hardcoded list. 0.8.6 removes the cap and lets each provider tell texspark what it can do.

    • Answers run to completion. The shared response cap is gone. OpenAI and Gemini now use their full output budget, so long explanations and code blocks finish instead of getting truncated.
    • Each Claude model gets its real limit. Anthropic’s API requires a max, so texspark reads each model’s true output ceiling from the provider and sends exactly that — never over the limit, never needlessly short.
    • The model picker shows what your key can actually use. Preferences → AI and the assistant header now list models fetched live from each provider, so new releases appear on their own. Offline, it falls back to a built-in list.

  • texspark was built around one workflow: a project that’s split across many files — a main.tex, a folder of chapters, a .bib somewhere. This guide sets that up from zero. It takes about two minutes.

    1. Open your root file

    Open the file that holds your \documentclass — the one with the \include or \input lines. For most projects that’s main.tex or manuscript.tex.

    That’s genuinely all you open. texspark has no “open folder” step and no project file to create — the root file is the project, because everything else can be discovered from it.

    2. Make it the build target

    Double-click its tab. (Or press ⌘⇧P.) A 🔨 appears on the tab — that file is now the build target.

    This one gesture is the whole setup. From now on:

    • The outline immediately reads the whole \include tree — every chapter in document order, including files you’ve never opened. No build needed.
    • ⌘B builds the root, no matter which file you’re editing. Chapter twelve, the appendix, a figure caption — ⌘B always compiles the right thing.
    • \ref{, \cite{, and SyncTeX all work project-wide: labels from other chapters autocomplete, every .bib the project references is found, and ⌘-clicking the PDF lands in the right sub-file.

    3. Work from the outline

    Click any section in the outline and the right file opens at the right line — that’s how you move between chapters. There’s no file browser in the sidebar, and after a day you won’t miss it: the outline is a better map of a book than a folder listing ever was.

    Sub-files you open this way come up as ordinary tabs. Edit, ⌘B, and the root rebuilds; the PDF stays where you were.

    The one rule: start from the root

    Order matters once: open the root file first and set it as the target before you wander into chapters.

    The reason is honest logic, not a limitation to apologize for: a chapter file doesn’t mention its parent. main.tex says \include{chapters/ch3}; ch3.tex says nothing about main.tex. So if you open a lone chapter first, texspark has no way to know which document it belongs to — no editor does. Start from the root, where the relationships are declared, and everything downstream follows.

    (If you arrive in a sub-file through texspark — from the outline or a ⌘-click in the PDF — the parent is already known, and the build target is handled for you.)

    A layout that works

    texspark doesn’t impose a structure, but if you’re starting fresh, this is a comfortable one:

    book/
    ├── main.tex          ← build target 🔨
    ├── references.bib
    ├── chapters/
    │   ├── ch1.tex
    │   ├── ch2.tex
    │   └── ch3.tex
    └── figures/

    Sub-folders in \include{chapters/ch1} are fine — the outline and SyncTeX follow paths, not just filenames.

    That’s the whole setup: open the root, double-click its tab, write. If anything here doesn’t match what you see, email support@texspark.io — it goes straight to the developer.


  • (v0.8.5) Open With

    Getting texspark to open your .tex and .bib files on double-click used to mean digging through Finder’s Get Info panel — especially if another TeX app had already claimed the extension. Now it’s one button.

    • Set as default from Preferences. Preferences → Compile → File associations has a Set as Default button that makes texspark the editor for .tex, .ltx, .latex, .sty, .cls, .bib, and .bst in one go.
    • Shows the current state. The panel tells you whether texspark is already the default, reading the extension’s real handler — so it’s accurate even when another app owns .tex.
    • Nothing sneaky. texspark never seizes an association silently; macOS asks you to confirm the change, and it only happens when you click the button.

  • (v0.8.4) Steady

    Reload polish

    Reloading a file from disk now leaves you exactly where you were:

    • Caret & scroll stay put — reload keeps your current cursor and scroll position instead of jumping to the top or a stale spot.
    • Full re-render in one pass — syntax highlighting, layout, and the minimap all refresh together, so nothing is left looking half-updated.
    • Caret kept in view — if the reloaded file shrank enough to push the caret off-screen, texspark gently scrolls it back into view.

  • (v0.8.3) Projects

    Licensing

    A round of correctness fixes around licensing and saving. Existing texspark licenses keep working exactly as before — nothing changes for paying users.

    • Product-scoped license keys. Activation and the periodic re-check now confirm a key actually belongs to texspark, so a key for a different product from the same store is turned away with a clear “this key isn’t for texspark” message instead of unlocking the app.
    • Save All, without the modal pile-up. Save All (⌥⌘S) is an explicit “write everything” action, so it no longer asks for per-file overwrite confirmation. Files that changed on disk outside texspark are left untouched — never clobbered silently — and reported together at the end so you can resolve each one with ⌘S or the reload button.
    • Steadier save / reload / build. The rules for what happens when a tab has unsaved edits and/or the file changed on disk are now driven by one shared decision path, covered by tests — so every entry point (⌘S, ⌘B, the reload button) behaves consistently.

    Build commands

    If you juggle projects that build differently — one on xelatex, another on latexmk, a third with a makeindex pass — texspark now remembers the build command for each project, and puts it right where you work.

    • A command per project. Each project (its build target 🔨, or the file you’re editing) keeps its own build command. Switch projects and the command follows — set latexmk once for the book and xelatex for the paper, and never swap them by hand again.
    • Command bar in the Terminal panel. Two always-visible, editable rows sit at the top of the Terminal: the build command with a ▶ to build (⌘B), and your custom command with a ▶ to run it (⌃⌘B). No trip to Preferences to tweak a flag.
    • Templates a click away. The 🔨 next to the build command opens Preferences → Compile, where the engine templates (xelatex / pdflatex / lualatex / latexmk / bibtex / makeindex) and options live.

  • The last few weeks have been a small education in rejection.

    I sent the manuscript to publishers. The replies came back — polite, professional, no. Then again. Then again.

    My first instinct was to look inward, which felt like the responsible thing to do. If they’re saying no, something must be wrong with the book. So I revised. I tightened chapters, rewrote a derivation I’d never been happy with, went through the figures again. Each pass made the manuscript a little better.

    But somewhere around the third round, I had to admit something: no amount of polishing was going to reverse those decisions. The gap between “good draft” and “yes” wasn’t a gap of quality. It was something else.

    The something else

    Publishing draws a line between two kinds of books: the trade book — something a curious reader picks up in a bookstore — and the textbook, which lives in classrooms and has adoption cycles and a syllabus around it.

    I’d been pitching mine as a trade book. Twelve chapters of derivations, exercises, from-scratch implementations. A book that assumes you’ll work through it rather than read it on a train.

    That’s not a trade book. That was never a trade book. I’d been walking into the wrong department and wondering why nobody wanted what I had.

    It’s a strange kind of relief, discovering that the problem is a category error. The manuscript wasn’t failing. It was in the wrong queue.

    Putting it down

    So I repositioned it as a textbook, made the revisions that framing called for, and then — the harder part — stopped.

    There’s always one more pass available. Another derivation to smooth, another figure to redo. At some point continuing to revise stops being craftsmanship and starts being avoidance, and I think I got close enough to that line to see it. The draft is good. Not perfect; good. I put it down.

    It’s now with publishers who actually work in textbooks, and I’m back to waiting — but this time waiting on the right people.

    What I’ve been doing instead

    Not writing, mostly. Which turns out to be its own kind of progress.

    I’ve started a new research topic — the first genuinely new thing in a while — and drafted a paper around it. And in the way these things go, working on that paper sent me back into texspark’s source: new usage patterns, new small frictions, new fixes. The tool improves when I use it for something I haven’t used it for before.

    The book is where it is. Somebody will read it eventually, or they won’t, and either way it exists now, which was never guaranteed. Meanwhile there’s a paper to write, and an editor to improve, and — as always — one more thing to fix before I can get back to writing.


  • Ever had a file change under you — a git checkout, a quick edit in another app, a script rewriting your .bib — and wondered whether the editor was still showing the truth? texspark now watches your open files, flags a tab the moment its file changes on disk, and asks the right question before any save, reload, or build could quietly clobber one side or the other.

    • External-change detection. Every open tab is watched. When a file changes on disk outside texspark, the tab gets an orange badge — a heads-up, never a surprise auto-reload.
    • Reload on demand. Pull the disk version back in from the ↻ button in the editor header, or right-click a tab → Reload from Disk.
    • Conflict-aware save, reload & build. Each action knows whether the tab has unsaved edits and whether the file changed on disk, and offers exactly the choices that make sense — never silently losing either version. Full behavior below.
    • Safer defaults. “Confirm before overwriting” is locked on and background auto-save is locked off while texspark is in active development.

    Legend: Unsaved edits = the tab differs from what texspark last saved. Changed on disk = the file was modified outside texspark since then.

    Save (⌘S)

    Unsaved editsChanged on diskWhat happens
    NoNoNothing to save — no-op
    NoYesAsks: Reload from Disk / Overwrite with Editor’s Contents / Cancel
    YesNoAsks: Overwrite / Cancel, then writes
    YesYesAsks: Overwrite / Discard / Discard & Reload / Cancel

    Reload from Disk (editor header ↻ · tab menu)

    Unsaved editsChanged on diskWhat happens
    NoNoReloads (identical — no visible change)
    NoYesReloads the disk version immediately
    YesNoAsks: Discard & Reload / Cancel
    YesYesAsks: Discard & Reload / Cancel

    Build (⌘B)

    Unsaved editsChanged on diskWhat happens
    NoNoBuilds straight away
    NoYesAsks: Build with Editor’s Contents / Reload from Disk & Build / Cancel
    YesNoAsks: Overwrite / Cancel, then builds
    YesYesAsks: Build with Editor’s Contents / Reload from Disk & Build / Cancel

  • (v0.8.1) Reload

    Ever had a file change under you — a git checkout, a quick edit in another app, a script rewriting your .bib — and wondered whether the editor was still showing the truth? texspark now watches your open files and lets you pull the disk version back in on demand.

    Reload from disk

    • External-change detection. Every open tab is watched. When a file changes on disk outside texspark, the tab gets an orange badge — no surprise auto-reload, just a heads-up that the on-disk copy has moved on.
    • Reload on demand. Pull the disk version back in from the new ↻ button in the editor header, or right-click a tab → Reload from Disk. If the tab has unsaved edits, texspark confirms before discarding them.
    • Smarter save conflicts. Saving over a file that changed underneath you now always asks first — Overwrite, Discard, Discard & Reload, or Cancel — so another editor’s or git’s changes are never clobbered silently.
    • The overwrite-confirmation safeguard is now locked on while texspark is in active development.

  • (v0.8.0) BibTeX

    Finally, texspark supports BibTeX! For the past while I’ve been heads-down writing a full-length book, where citations never really came up — but now that the manuscript is done and I’m back to research papers, I needed BibTeX again. So here it is.

    BibTeX

    • BibTeX tab in the sidebar. Next to Outline and Labels, a new BibTeX tab lists every entry from the .bib files your project references (\addbibresource / \bibliography), discovered recursively across \input / \include. Filter as you type.
      • Click — insert \cite{key} at the editor cursor
      • Double-click — open the .bib file at that entry
    • Citation autocompletion. Typing \cite{, \citep{, \citet{ (and friends) now suggests your BibTeX keys, the same way \ref{ offers labels — one source of truth, drawn from the same entries.
    • .bib syntax highlighting. Open a .bib file and entry types, field names, citation keys, and braces are colored to match your theme.

  • LaTeX rarely finishes in one pass. Cross-references need a second run. A bibliography needs BibTeX in between. An index needs makeindex. If you’ve been running these by hand in Terminal — or clicking through a sequence of menu items — this guide sets it up as a single ⌘B.

    Why more than one pass

    A quick refresher, because knowing why makes the command obvious:

    On the first run, LaTeX doesn’t yet know what page Section 3 lands on, so \ref and \cite come out as ??. It writes what it learned into .aux. BibTeX (or makeindex) then reads those files and produces .bbl (or .ind). A second LaTeX run picks those up — and sometimes a third is needed, because inserting the bibliography shifts page numbers, which changes the references again.

    Hence: run, process, run, run.

    The command box

    Open Preferences (⌘,) → Compile. You’ll find one-click templates for the usual engines — xelatex, pdflatex, lualatex, latexmk, BibTeX, makeindex — which is the fastest way to get a working build.

    But the templates only fill in the command box; they don’t lock it. The field itself is fully editable, so you can start from a template and modify it, or ignore them entirely and type your own pipeline from scratch. Anything your shell can run, texspark can run. Steps chain with && — meaning each step runs only if the previous one succeeded, so a failure stops the chain instead of cascading nonsense.

    Two tokens get substituted before the command reaches the shell:

    • {file} → main.tex (build target with extension)
    • {filename} → main (without extension)

    Both are shell-escaped, so spaces in your path won’t break anything. The command runs in the build target’s directory.

    Recipes

    Bibliography (BibTeX):

    xelatex -synctex=1 {file} && bibtex {filename} && xelatex -synctex=1 {file} && xelatex -synctex=1 {file}

    Note that BibTeX takes {filename} — no extension — while LaTeX takes {file}. Getting this backwards is the single most common mistake here.

    Index (makeindex):

    xelatex -synctex=1 {file} && makeindex {filename} && xelatex -synctex=1 {file}

    Both, for a book:

    xelatex -synctex=1 {file} && bibtex {filename} && makeindex {filename} && xelatex -synctex=1 {file} && xelatex -synctex=1 {file}

    Or let latexmk figure it out:

    latexmk -xelatex -synctex=1 -interaction=nonstopmode {file}

    latexmk decides how many passes are needed and runs BibTeX when appropriate. If your project is standard, this is the least fussy option — and texspark keeps your PDF scroll position through all of latexmk’s rewrites, so a five-pass rebuild doesn’t fling you back to page one.

    Keep -synctex=1

    Every LaTeX invocation in the chain should carry -synctex=1. That’s what produces the .synctex.gz file next to your PDF, which is what makes ⌘⇧↩ and ⌘-click work. Drop it from the final pass and forward/inverse search quietly stops working.

    When a step fails

    The chain stops at the first failure, and the bottom panel switches to Issues automatically. Click any error row to jump to the offending line — in the right sub-file, not just the build target.

    Two things worth knowing:

    • BibTeX errors don’t always surface as LaTeX errors. If your bibliography comes out empty, check the Log tab (next to Terminal and Issues) for BibTeX’s own complaints — a missing .bib entry usually shows up there.
    • If a run leaves things in a strange state, ⌘⇧⌫ sweeps the build directory clean of .aux, .bbl, .ind, .toc, and friends, leaving your .tex and .pdf alone. Then build fresh.

    One target, any chapter

    Worth restating: mark your project root as the build target (⌘⇧P) and this chain runs against it no matter which chapter you’re editing. Multi-pass builds and multi-file projects were the two things that used to make me alt-tab to Terminal. Now they’re one keystroke.