Our question LaTeX Editors/IDEs is very popular, with close to 35k views as of Feb ’13. However, the answers vary a lot in terms of quality and the kinds of information they provide, which makes comparison harder than it would have to be. So I thought it might be nice to standardize the information available about every editor. Here’s what I’d propose to do:

  • Compile a list of features, which will be present in every editor’s answer (Unicode, RTL support, platforms, ...). This will pretty much result in standard answer template.
  • Create a sample document (~40 lines max) to take screen shots of in each editor, so the screen shots will be really comparable.
  • Have users here “sign up” for editors, i.e. one or a few users will be “responsible” for a specific editor that they are experienced in using. If the editor receives major updates, it’d be great if they could also update the answer accordingly.

Each of these should be one CW answer here, I guess, which I’ll create; discussions can take place in the respective comments.

Sometimes, we get questions like “Which LaTeX editor can make fried eggs?” – in these cases, we could just create a call for action here (another answer as a to-do-list probably) and have the editor caretakers add the feature “Make fried eggs” to their respective editor’s answer. All the information neatly collected in one place.

There is, of course, the great Wikipedia article Comparison of TeX editors, and we should try to avoid just duplicating that here. Instead, let’s take advantage of our format: screen shots are definitely a plus; we can me a little more subjective than Wikipedia; we can add a few words to a bare yes or no, if necessary; and, while I don’t know how up-to-date that article is, it might be easier for us to stay up-to-date.

Important: Let’s wait with updating the actual answers until we’ve pretty much sorted everything out here.

Feel free to edit all answers without prior discussion. I think most things won’t be very controversial, since it’s usually not an either-or situation. If the feature list or sample document get too extensive, we can always try to boil them down later.

Note Any discussion comments that get 'actioned' will be removed periodically so the key points stay clear.

  • +1 nice idea. I think the answers can be prepared in meta (new thread). Once finished, mods could then move the thread to the main site and merge to the current thread.
    – yo'
    Commented Feb 8, 2013 at 17:28
  • @tohecz Good idea, that would simplify collaboration on answers. But then again, we don’t have real-time collaboration here either, so it doesn’t really matter if the actual answers on the main site are edited or interim answers on meta. Since the template will be a good basis for relatively quick, but thorough edits, we might just be able to skip that meta stage?
    – doncherry
    Commented Feb 8, 2013 at 17:53
  • @doncherry Are we in a position to move on this?
    – Joseph Wright Mod
    Commented Feb 19, 2013 at 16:55
  • Sorry, didn't notice that you asked us not to update things until some consensus was reached. I've added two screenshots to Emacs. The entry is starting to get a little long. Should we have an upper-limit on the length of each answer?
    – Tyler
    Commented Feb 20, 2013 at 14:25
  • @Tyler Good idea: I thing that should go in the 'template' answer. Perhaps one 'review' only and max two screenshots?
    – Joseph Wright Mod
    Commented Feb 20, 2013 at 16:43
  • @JosephWright I made the move and put a note in the question body of the main question. Go go go! :)
    – doncherry
    Commented Feb 24, 2013 at 16:27
  • @doncherry I left posted an answer instead of a comment. I don't know how helpful it would be, but just leaving my humble opinion Commented May 5, 2013 at 19:23
  • it seems to me that a "toc", or something like the "quick links" of the question Who are the package maintainers here? would be helpful for the referenced question. at the moment, there's no clear organization. Commented Sep 19, 2013 at 19:09
  • tex.stackexchange.com/questions/161020/… Commented Feb 18, 2014 at 13:16
  • You may feature this one tex.stackexchange.com/a/385669/127392 Mathcha Commented Aug 22, 2021 at 13:19

6 Answers 6


Editor Sign Up List

Please add yourself with your favorite editor(s) here. In order to keep the “responsibility” somewhat concentrated, I’d say no more than three people per editor.

Editors with a score of at least 25 still looking for someone – freelancers welcome!

  • @Alan Whenever you find the time, you can go ahead and update the TeXShop answer. Also, thanks for your one-page, dictatorial guide – I used it in a workshop at UMass Amherst the other day :)
    – doncherry
    Commented Mar 16, 2013 at 18:53

Feature List / Answer Template

between the two double rules

TeX Editor Name

  • Platforms: Windows XP/Vista/7/8, OS X 10.?, Linux
  • License: License XYZ, US$ 20
  • Languages: de, en, fr, ...
  • Unicode: Yes
  • RTL/bidi: Yes
  • % !TEX directives: Yes
  • Syntax Highlighting: Yes, (not) customizable
  • Code Completion: Yes, (not) customizable
  • Code Folding: Yes
  • Spell Checking: Yes
  • SyncTeX: Yes
  • Built-in Output Viewer: Yes, supports PDF, DVI
  • Project Management: Yes (which?)
  • Autosave: Yes
  • Line Spacing: Yes

Description, if necessary.

TeX Editor Name screen shot

If there are some specific features to showcase, we could have more screen shots here. Try to make all alt texts of the pictures descriptive; we can see them on mouseover.

At the end, we could have personal statements with the name of the user in front and quotation marks (?), a bit like a mini-review, maintaining a separation between feature descriptions and more subjective statements, but allowing to reuse most of the existing material in the answers:
doncherry: “This is my favorite editor and I’ve been using it since 1978 because it was the only one with Tengwar support back then.”

Explanation of features, if necessary

  • License: I’m not sure if that’s the best way of putting that information [doncherry]
  • RTL = right to left; bidi = bidirectional.
  • Code Folding: Can 'roll up' sections into just the heading (also called 'outline')
  • % !TEX directives: See When and why should I use % !TEX TS-program and % !TEX encoding?
  • Project Management: Would it be good to have more than just yes/no here?
  • 2
    Indentation of soft-broken lines? (A line visually broken at the window or whatever border is indented as its parent). IMHO this is a crucial feature that surprisingly few editors (especially in the UNIX world) get right. For vim, for instance, one has to apply an unsupported patch (that works pretty well, though). TexShop, Texmaker, Texstudio and so on all do not support it. Sublime Edit 2 does.
    – Daniel
    Commented Feb 9, 2013 at 10:30
  • @Daniel Relatively unusual, I guess: most experienced people use hard wrapping as this helps with TeX errors and using version control.
    – Joseph Wright Mod
    Commented Feb 9, 2013 at 12:57
  • 2
    @JosephWright: Yes, I know. It's an conceptual idiosyncrasy kept alive by line-based tools that were invented more for programming than markup languages – at a time where screens had a hard limit of 80 characters per line. For a markup language, like LaTeX, hard line breaks are conceptually bogus: They rarely do carry any semantics (save for verbatim, listings, and so on), but just constraint the width of the editor window.
    – Daniel
    Commented Feb 9, 2013 at 19:51
  • @Daniel The hard limit comes from human eyes not from (old) screens. Commented Feb 10, 2013 at 23:10
  • @PaulGaborit: "Hard limit" and "human" contradict IMHO each other. The "right" line width on screen is in the eye of the beholder; it may also depend on the fact if she is sitting in front of a 30" TFT or a 4" mobile. Thus, it should be delegated to the presentation layer (editor) and not be encoded in the content, unless it carries semantics. This is just a question of separation of concerns. (In fact, the 80 cpl is a technical inheritance from IBM punchcards.)
    – Daniel
    Commented Feb 11, 2013 at 8:47
  • @Daniel Why IBM chose this limit? Because, a human being is not comfortable to read lines longer than 80 characters (60 characters are even better). Commented Feb 11, 2013 at 9:03
  • 1
    @PaulGaborit: In fact IBM chose the limit because the size of the punchcards was limited. And how chose IBM the size of the punchcards? It was determined by the currency of the time, so they could be shipped in the same boxes. IMHO, your last comment already shows the anachronism: Why 80 cpl if 60 cpl is considered to be optimal? What about 85 or 90? Maybe 77? In the end we all agree that there is a sensible corridor, but any concrete limit is arbitrary. However, my point is: A screen is not a book and there is simply no need to enforce a hard cpl limit.
    – Daniel
    Commented Feb 11, 2013 at 10:10
  • @Daniel My point is: A programming or markup language is used by human and too long lines are not comfortable for humans. ;-) Commented Feb 11, 2013 at 10:21
  • 1
    Should we extend ! TeX comments to the wider 'Special comments' idea? For example, Emacs uses a similar idea but with different 'magic' comments.
    – Joseph Wright Mod
    Commented Feb 11, 2013 at 16:25
  • @JosephWright That’s definitely something of interest, I can’t judge, however, if these comments are similar enough to each other to justify a shared category/feature, or if they should just be described in the respective editor’s description text.
    – doncherry
    Commented Feb 11, 2013 at 19:56
  • @JosephWright : I agree, TeX directives appear to provide exactly the same level of customization that Emacs provides with file-local variables (among other things). Having a general category for 'compilation directives', with the mechanism(s) provided in the answer would make this more general.
    – Tyler
    Commented Feb 24, 2013 at 17:00
  • How do I determine if bidirectional typesetting is available? And should "Open Source" be a point as well? It currently is in many of the answers.
    – doncherry
    Commented Feb 28, 2013 at 1:53
  • I suggest adding version control support to the list. Answers should enumerate supported VCSs.
    – Desik
    Commented Apr 10, 2015 at 15:47

Sample Document For Screen Shots

named foo-bar.tex

% A comment: here we use a standard class
\chapter{Hello World}
Inline math mode: $\int_{0}^{2\pi}\sin x\,dx$.
Display math mode: \[\int_{0}^{2\pi}\sin x\,dx\]
Something \verb|verbatim here with $|\\[2em]
\section{Hi There, John}
\emph{Baz} \textti{a typo in a macro}
  Foo & Bar & Baz \\\hline
  1   & 2   & 3   \\
  4   & 5   & 6   \\
and then a list with cross references and citations
   \item \label{it:first} This is an item with a citation \cite{dummy}.
   \item This item has a reference to the previous item, namely \ref{it:first} and should be deliberately longer than 80 characters.

Take screen shots preferably with the editor’s default settings, i.e. what users would see immediately after installation. Include the (pdf) preview, if available, and wherever the error about \textti would be displayed. Make the picture a link to itself so we can click to enlarge:

[![Texmaker sample document screen shot][1]][1]
  • For cross-platform editors, what is the best plan? For example, I do the screenshots for the official TeXworks page on my Mac, and do Mac/Win7/Ubuntu.
    – Joseph Wright Mod
    Commented Feb 8, 2013 at 21:45
  • I would add a long line (paragraph size), and maybe an itemize environment.
    – Guido
    Commented Feb 14, 2013 at 5:22
  • @Guido Go for it – the code is still relatively short.
    – doncherry
    Commented Feb 18, 2013 at 7:25
  • 3
    Would it make any sense to include some text in a non-Latin script here, in particular if it’s a right-to-left language? Perhaps this should only be added if the editor supports rtl.
    – doncherry
    Commented Feb 24, 2013 at 16:33

To-Do List

  • go ahead and edit your editor’s answer!
  • still looking for volunteers for some editors!

General Questions

  • Keep the title as it is? LaTeX Editors/IDEs
  • Edit the question body?
  • Voting will probably just keep sort-of reflecting the relative popularity of the respective editor, and perhaps also the convincingness of the answer? (That’s my guess for what it is right now.)

(This will be the accepted answer as soon as I can self-accept it.)


I know it was stated by the OP that the Wikipedia article shouldn't be replicated, but I think perhaps that it should (at least to some extent) for the reasons that follow:

  1. I recall when I looked at the Wikipedia page when I was first was learning how to use LaTeX, it was extremely messy and difficult to read on a smaller monitor. It may be cleaner that checkmarks be used instead (like on certain product pages on amazon). This also makes it easier for the viewer to compare instead of scrolling up and down when comparing between two different editors.
  2. The one on TSE could be restricted to the more popular ones, i.e. the ones that have already been suggested = the ones that people actually use. The Wikipedia article includes far too many options and is certainly overwhelming for those just learning LaTeX.

These are just some thoughts that came across my mind after I found the popular post.

If this is viable, perhaps a pros and cons list of each could be added instead?

  • Might be an option ... we’re not as good about maintaining as Wiki though, I think. Our strength is personal experience and task-oriented solutions, not huge data-like tables.
    – doncherry
    Commented May 6, 2013 at 4:07

I stumbled upon the following choices of the few FOSS editors that are targetted at live preview of TikZ. Should they be put in a section of their own? Any suggestions on how can this be handled?


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .