Choose a LaTeX Editor by Testing the Project Boundary
An editor comparison is more useful when it tests how source, assets, bibliography, build instructions, and history behave after the editor is removed.
Feature counts age quickly. A more durable editor question is what remains after the application is removed. The answer lives in the project directory, build notes, and independent version-control diff.
Define the project before comparing editors
Use a small but non-trivial repository: one root document, an included section, a bibliography file, an image, and a build note. Keep the fixture rights-safe and make every dependency explicit.
editor-exit-test/
├── main.tex
├── sections/method.tex
├── refs.bib
├── figures/diagram.png
└── BUILD.mdRun a seven-step editor-exit test
- Open the same repository in the candidate editor.
- Change one equation in the included section.
- Compile the documented root.
- Close the editor and inspect the directory with ordinary file tools.
- Review the repository with git diff.
- Open the directory in a second editor or build tool.
- Compile again and record environment differences separately.
The test passes when meaningful changes remain standard project files, the build root can be reconstructed, and no proprietary container is required to continue working.
The public fixture ran those essential checks on documents/paper/main.tex. TeX64’s production BuildService applied a one-line edit and built the nested root. After the editor step, git diff recorded the ordinary source change. TeXShop 5.57 then ran its bundled pdflatexmk.engine against the same path. Both tools produced a 41,040-byte PDF with SHA-256 2ddbfe95bc3491d1d2b0d0f3294f1ddf4597c94b44fd0bc6a8c21d21905788b9.
Use ordinary file tools as an independent observer
A product-controlled export dialog is not enough evidence. The repository itself should reveal what changed. TeX64 opens and writes normal project files and uses the local project directory as its working boundary. That design can be checked with Git rather than trusted as a slogan.
Compare portability, reproducibility, and collaboration separately
| Dimension | Test | A passing result means |
|---|---|---|
| File portability | Inspect the project after closing the editor | Source and assets remain usable standard files |
| Build reproducibility | Build with recorded versions in another tool | The environment can be reconstructed |
| Data flow | Observe what stays local and what is sent to a service | The boundary is documented and testable |
| History | Review changes with Git | Meaningful edits appear as understandable diffs |
| Collaboration | Exercise the team workflow | The chosen process fits actual collaborators |
Standard files do not promise identical PDFs
TeX engine, package versions, fonts, shell-escape policy, operating system, and custom build scripts can change the output. Record those dependencies in the fixture. Local ownership also does not make one editor best for every team: browser collaboration and institution-managed environments may matter more.
Primary sources
Report changed behavior, failed reproductions, or errors through TeX64 support.