# Let’s polish the Editors/IDEs question

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. – tohecz Feb 8 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 Feb 8 at 17:53 @doncherry Are we in a position to move on this? – Joseph Wright♦ Feb 19 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 Feb 20 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♦ Feb 20 at 16:43 @JosephWright I made the move and put a note in the question body of the main question. Go go go! :) – doncherry Feb 24 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 – AlanH May 5 at 19:23

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 Mar 16 at 18:53

# To-Do List

• 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.)

-

# Sample Document For Screen Shots

named foo-bar.tex

% A comment: here we use a standard class
\documentclass{report}
\usepackage[T1]{fontenc}
\begin{document}
\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} \begin{tabular}{ccc} Foo & Bar & Baz \\\hline 1 & 2 & 3 \\ 4 & 5 & 6 \\ \end{tabular} and then a list with cross references and citations \begin{enumerate} \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. \end{enumerate} \end{document}  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 Feb 8 at 21:45 I would add a long line (paragraph size), and maybe an itemize environment. – Guido Feb 14 at 5:22 @Guido Go for it – the code is still relatively short. – doncherry Feb 18 at 7:25 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 Feb 24 at 16:33 # Feature List / Answer Template between the two double rules ## TeX Editor Name — our-tag-for-this-editor-if-it-exists • 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?)

Description, if necessary.

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?
-
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 Feb 9 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 Feb 9 at 12:57
@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 Feb 9 at 19:51
@Daniel The hard limit comes from human eyes not from (old) screens. – Paul Gaborit Feb 10 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 Feb 11 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). – Paul Gaborit Feb 11 at 9:03
@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 Feb 11 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. ;-) – Paul Gaborit Feb 11 at 10:21
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 Feb 11 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 Feb 11 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 Feb 24 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 Feb 28 at 1:53

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 May 6 at 4:07