Other editors

In 1993 Aleksander Simonič could not find a TeX front end he liked, so he started writing one for Windows 3.1. That became WinEdt, which went up on CTAN as shareware in 1995 and is still shareware three decades later. Editors for LaTeX split into two lineages: tools somebody built because nothing existed, and everyday general-purpose editors with a plugin bolted on. This page surveys the ones that have no page of their own — WinEdt, WinShell, the JetBrains IDEs, Notepad++, Kate, GNOME Text Editor, EmEditor, Sakura Editor, and the Markdown hybrids such as Typora — and ends by turning how to choose into four conditions rather than a feature list.

No editor typesets anything: settle the distribution first

Every option below is an editor, not a TeX system. The typesetting is done by TeX Live, MiKTeX or MacTeX, installed separately, and the editor merely invokes it to produce a PDF. “Which editor” and “which engine” are therefore two different questions, and the second has to be settled first. Get the order wrong and no amount of fiddling in the editor’s preferences will produce a PDF, because the reason it does not appear lives outside the editor entirely.

The Windows-only front ends: WinEdt and WinShell

WinEdt is a Windows-only Unicode text editor that was for years the default TeX front end on the platform. It works as a plain editor, but its real strength is that it is built to bind tightly to TeX Live and MiKTeX: one toolbar button runs pdflatex or platex, alongside completion, spell-checking, project management and regex search-and-replace. The catch is the licence — it is shareware, and after a trial you pay a registration fee to keep using it. In an era this rich in free options, paying for an editor gives one pause, but development continues and the 11 series is current.

WinShell occupies almost the same ground and is free. This Windows LaTeX IDE bundles a text editor, syntax highlighting, project management, spell-checking, a table wizard, BibTeX integration and Unicode support, and calls your engine from the toolbar. It is freeware distributed as a binary with no public source, but it still stands as a solid no-cost alternative to the paid WinEdt. Neither ships a typesetting engine, so the procedure is the same for both: install MiKTeX or TeX Live first, then point the editor’s settings at where those commands live.

Bolting a plugin onto an editor you already use

An editor that is not TeX-specific can still write LaTeX comfortably, provided you can arrange two things: syntax highlighting and a way to invoke the build. There are two routes. The thick one leans on a plugin that also handles completion, PDF preview and forward and inverse search; the thin one simply calls latexmk from the editor’s external-command feature. The thin route takes five minutes to set up, but jumping to error lines and staying in sync with the PDF are left for you to wire yourself.

The thick route’s standard-bearer is a JetBrains IDE (IntelliJ IDEA and its siblings) plus TeXiFy IDEA. It brings syntax highlighting; completion of labels, commands, environments and file names; an embedded PDF viewer; and BibTeX (.bib) support — carrying IntelliJ’s ergonomics straight into LaTeX. For anyone who already lives in JetBrains tools while programming it is the natural pick, and IntelliJ IDEA has a free Community edition. The thin route’s standard-bearer is Notepad++ with NppExec. Thanks to the underlying Scintilla library Notepad++ highlights TeX files, though by default it does not colour math environments (a user-defined language fills that gap). The usual build setup is to bind a command to a key such as F6 through NppExec, show the output in a console, and optionally colourise error lines.

For the historical record there is also Atom. GitHub’s editor had LaTeX packages too, but development ended and the project was archived on 15 December 2022. Technically it handed the baton to its descendant Electron and to VS Code. If a search for settings drops you into an Atom article today, do not start there; for the same feel, move to VS Code.

Kate and GNOME Text Editor: the Linux desktop defaults

If you are wondering whether to write LaTeX in KDE’s Kate, one fact shortens the conversation: the editing surface inside Kile is Kate. Kate’s editing engine is factored out as a component called KatePart (through the KTextEditor interfaces), and KWrite, KDevelop and Kile all embed it. So “writing LaTeX in Kate” and “using Kile” differ only in whether the LaTeX scaffolding — build tools, templates, the structure tree, the Okular handshake — is already built around that same editing surface. Kate alone gives you syntax highlighting and can run external commands, but the scaffolding is yours to assemble. On KDE, going straight to Kile is the short road.

On the GNOME side the story moved in a sadder direction. gedit, the long-standing default, owed most of its power to its plugins, and a LaTeX plugin was among them. Then GNOME 42, in March 2022, handed the default seat to GNOME Text Editor. Bringing gedit into line with the newer design guidelines (libadwaita) would have meant an extensive rewrite, so the successor was written from scratch and did not initially inherit the plugin machinery. gedit still exists, but the route of “add a plugin to the desktop’s default editor and write LaTeX in it” has narrowed on GNOME. Writing LaTeX in a GNOME environment is safer with a dedicated editor or the VS Code family.

Typing the Japanese manuscript in an editor you already know

In Japan there is a durable tradition of using a home-grown, Japanese-savvy editor as the base. EmEditor is a Windows editor that stays nimble even on enormous files and has shipped TeX (LaTeX) syntax colouring from early on; there is a free edition and a paid Professional one. Sakura Editor is a free and popular domestic editor for which the community has long shared build automations that call platex from its macro facility — ExecCommand and friends — and then open a DVI viewer. Both suit the pattern of keeping the environment you type Japanese in and farming out only the build. The other side of that bargain is accepting from the outset that completion, cross-reference help and bibliography integration are not part of the deal. One thing is worth committing to, though: write the Japanese route — upLaTeX into dvipdfmx, or LuaLaTeX — into the project’s .latexmkrc rather than into the editor’s settings. Then a co-author who opens a different editor still gets the same PDF.

Can a Markdown editor like Typora stand in for LaTeX?

The short answer: it can stand in for the look of the mathematics, but not for the typesetting. A Markdown editor like Typora renders $E=mc^2$ as mathematics the moment you type it, but what draws it is not TeX — it is a browser math renderer such as MathJax or KaTeX. Line breaking, float placement, cross-references, a bibliography: none of the machinery LaTeX carries for a book-length document is in there. A formula looking right on screen and a two-hundred-page book being set correctly are two different achievements.

When it comes to producing an actual PDF, this family calls Pandoc. Pandoc converts Markdown to LaTeX and hands that LaTeX to a TeX engine. In Typora’s case plain PDF export does not need Pandoc — there is a path through its internal HTML — but exporting via LaTeX, or to .tex, docx or EPUB, requires installing Pandoc separately. And Typora does not convert the Markdown directly: it passes its internal abstract syntax tree to Pandoc. Choosing this road therefore means what you have to learn is not LaTeX’s notation but Pandoc’s Markdown dialect, its templates and its metadata conventions. Nothing gets easier; the subject you must learn is simply swapped for another.

The options side by side

Here is what each editor is and how it connects to LaTeX. Read the last column across and the common pattern is plain: every one of them produces a PDF by calling out to a separately installed engine. What differs is how thick the scaffolding is, and who has to build it.

How to choose: four conditions, not a feature list

The practical test for a general-purpose editor is not the length of its feature list but four conditions that keep the manuscript moving. Saving runs the same build command every time. An error takes you back to the source line. The PDF refreshes by itself. And the configuration lives not only inside the editor but in the project — in a .latexmkrc or a build file. The fourth matters most: when the settings exist only inside your editor, a co-author’s machine or your own second computer will not produce the same PDF, and you will be hunting for the reason with a deadline overhead. If those four cannot be met, moving to a dedicated LaTeX editor gets you writing sooner.

• You are on Windows and want a TeX-specific feel immediately: the free WinShell, or the polished, paid WinEdt.
• You want to keep your everyday development environment: JetBrains users reach for TeXiFy IDEA; if you would rather keep it light, Notepad++ with NppExec.
• You are on a Linux desktop: on KDE go to Kile, whose editing component is Kate itself; on GNOME avoid the plugin route and pick a dedicated editor or the VS Code family.
• You want to type Japanese in an editor you know: wire an external command into EmEditor or Sakura Editor, accepting that completion and cross-reference help are not included.
• You are on macOS and do not want to deliberate: TeXShop is the standard starting point, and has a page of its own.
• You have no strong attachment either way: start with VS Code (LaTeX Workshop) — free, full-featured, cross-platform, actively developed — or with the purpose-built TeXstudio.

One last word on switching. When the time you spend wiring up reference completion, bibliography completion and SyncTeX exceeds the time you spend actually writing, the editor no longer fits the job. Move to a dedicated tool — VS Code, TeXstudio, Emacs, Vim. Every option on this page wins on one thing only: it lets you keep an environment you are already fluent in. None of them wins on LaTeX features as such. The moment that fluency stops being worth the friction is the moment to switch.