PhilT_eX

Some peo­ple are loathe to try new soft­ware once they’ve found a few appli­ca­tions they like. I’m the oppo­site. I’m con­stantly try­ing out new pro­grams, even when I’m per­fectly happy with the ones I already have. I’ve tried quite a few L^aT_eX edi­tors in par­tic­u­lar. I thought I’d try to put my hor­ri­ble time-wasting habit to some good use by pro­vid­ing a run-down of my expe­ri­ences with eight nice L^aT_eX editors.

(If you’re look­ing for a chart sum­ma­riz­ing which fea­tures cer­tain L^aT_eX edi­tors have or don’t have, there’s a nice one on Wikipedia, to which I con­tributed while writ­ing this. I am going to offer descrip­tive com­men­tary instead.)

I am lim­it­ing myself only to (i) edi­tors that I think are actu­ally worth con­sid­er­ing, (ii) edi­tors that are open source and free to use (the best kind of soft­ware), (iii) edi­tors that are avail­able for my oper­at­ing sys­tem, linux. (After all, “free and open source” should include the sys­tem it runs on, right?—well, that, and the facts that I don’t have access to a mac, and don’t want to encour­age any­one to use Win­dows.) This last con­di­tion explains why there’ll be no men­tion of the mac-only TeXshop or the Windows-only TeXnic­Cen­ter, and so on. Sorry. Six of the eight below are cross-platform, how­ever. Other min­i­mal con­di­tions for con­sid­er­a­tion include Uni­code (UTF-8) sup­port and L^aT_eX syn­tax high­light­ing (which would rule out TXC 1.0 anyway).

1. TeX­works
2. Tex­maker / TexMakerX
3. Gedit / gedit-latex-plugin
4. KILE
5. Gummi
6. LyX
7. GNU Emacs (with AUC­TeX, Whizzy­TeX or other plugins)
8. VIM (with the L^aT_eX–suite or other plugins)
9. Hon­or­able Men­tions and Others
10. Installing These on Ubuntu

Please note: In the screen-capture ani­ma­tions below, I resized the appli­ca­tions’ win­dows to a very small size in order to keep the ani­ma­tions to a rea­son­able file size. This may make these pro­grams look funny or much less attrac­tive than they would be when actu­ally used.

---

TeX­works

Home­page
Plat­forms: Truly cross-platform (Win­dows, Mac, Linux, etc.)

TeX­works is a rel­a­tive new­comer on the scene, actively devel­oped by sev­eral mem­bers of the TeX User Group (TUG), and mod­eled on TeXshop for mac. It is a light-weight edi­tor, very sim­ple in design and usage. Its most promi­nent fea­ture is its well-integrated PDF viewer, set up for forward/reverse “jumps” between the edi­tor win­dow and PDF pre­view using Sync­TeX. Right click­ing any­where in the PDF pre­view allows you to jump to the cor­re­spond­ing part of the mark-up and vice versa. Rebuild­ing the source and view­ing the new out­put is just a click away—at least if you’re using pdfL^aT_eX or XeL^aT_eX or other PDF out­put rou­tine. (Set­ting it up to work with DVI or PS files is rather more dif­fi­cult; the devel­op­ers are no doubt assuming—probably correctly—that PDF is likely to be the pre­ferred out­put in the years to come.)

Its slo­gan is “low­er­ing the entry bar­rier to the TeX world”, and one can see how its sim­plic­ity might be attrac­tive to a begin­ner. It does not over­whelm the user with lots of extra menus, pop-ups and side-panels. Using it is usu­ally as sim­ple as enter­ing code and hit­ting the “go” but­ton. Then again, it does not offer some fea­tures cer­tain begin­ners might cher­ish or rely on. While it does offer syn­tax high­light­ing, smart quotation-mark han­dling and inline spellcheck­ing, it does not offer fea­tures such as auto­matic code com­ple­tion, menus for enter­ing com­mon sym­bols or codes, or advanced error check­ing. (Note added later: appar­ently there is an auto­matic code com­ple­tion fea­ture, which I some­how missed the first time; chalk this up to another fea­ture not very evi­dent the user with­out fur­ther inves­ti­ga­tion!) (Indeed, it is ini­tially setup to han­dle errors just like run­ning L^aT_eX on the com­mand line would, paus­ing dur­ing com­pi­la­tion when errors are encoun­tered and show­ing only the error log.) Such fea­tures are very likely to be missed by many, but the purist in me actu­ally sees the ben­e­fit in forc­ing a begin­ning user to learn how to han­dle mark-up with­out such crutches—“the hard way”, so-to-speak. Or per­haps that’s the sadist in me. I’m not sure.

How­ever, its sim­plic­ity is a bit decep­tive. There are fea­tures that might attract an advanced user as well. While there is no hint of multi-document project han­dling listed in the menus, one can set up cer­tain files as mas­ter doc­u­ments or sub-documents by insert­ing spe­cial com­ments in the first few lines of the file. Set­ting up, e.g., XeL^aT_eX or pdfL^aT_eX or another com­pi­la­tion method as default can be han­dled sim­i­larly. While the menus don’t make it obvi­ous, it is pos­si­ble to cus­tomize the syn­tax high­light­ing col­ors and dis­play style by edit­ing con­fig­u­ra­tion files directly. You can write your own scripts using the QtScript lan­guage (sim­i­lar to JavaScript). The project is also under rapid devel­op­ment, and I hope to see a lot more fea­tures in ver­sions to come.

---

Tex­maker / TexMakerX

Home­pages: Tex­maker / Tex­Mak­erX
Plat­forms: Truly cross-platform (Win­dows, Mac, Linux, BSD Unix, etc.)

When I first tried Tex­maker, it struck me as rather “meh”. Not great, but not bad either. Re-examining it now, how­ever, I’m more and more con­vinced that this is a seri­ous con­tender, espe­cially for those who move from one oper­at­ing sys­tem to another and want a con­sis­tent L^aT_eX–ing expe­ri­ence on all plat­forms. I am espe­cially impressed with the Tex­Mak­erX “fork” of Tex­maker, which has all the fea­tures of its name­sake plus some addi­tional ones, and most of my com­ments below apply to it in par­tic­u­lar. (I’m not sure why the two ver­sions haven’t been merged, but such forks are the inevitable flip-side to the ben­e­fits of open source.) It has all the essen­tials: lovely and cus­tomiz­able syn­tax high­light­ing, code com­ple­tion (includ­ing cita­tion com­ple­tion), code fold­ing, intel­li­gent error han­dling, quick­start wiz­ards, user tags, inline spellcheck­ing, etc. Its side panel dou­bles as a structure/label browser and symbol/command quick-map:

It also has some rel­a­tively unique fea­tures, such as revi­sion con­trol and mod­i­fi­ca­tion high­light­ing, a built-in the­saurus, and a very advanced tex­tual analy­sis fea­ture (which can count words, com­mands, you name it).

All in all, it’s hard to see going wrong with this gem of an open-source, cross-platform pro­gram. A few of the oth­ers below may have a few extra fea­tures or power, but the aver­age L^aT_eX–er is likely not going to miss them. One caveat is that it takes a lit­tle bit of work to set it up for use with XeL^aT_eX (though it’s not too hard), or for forward/reverse search with a PDF viewer such as Oku­lar (for linux), Skim (for mac) or Suma­tra PDF (for Win­dows), but def­i­nitely do-able.

---

Gedit with the gedit-latex-plug-in

Home­page
Plat­forms: Linux (and per­haps other Unix-like systems)

Gedit is the default text edi­tor of the GNOME desk­top envi­ron­ment, which is extremely pop­u­lar in the GNU/linux world. GNOME users such as myself may find our­selves rou­tinely using gedit for other purposes—I am for exam­ple writ­ing the HTML for this blog post in gedit before past­ing into WordPress—and so it’s nat­ural to want to make use of it for L^aT_eX edit­ing as well. By itself, gedit is a fairly sim­ple and bare­bones edi­tor, although it does as is offer syn­tax high­light­ing not only for L^aT_eX but for most other mark-up and pro­gram­ming lan­guages, with a vari­ety of color schemes. But what really makes it a use­ful edi­tor is that it allows plug-ins. By default, for exam­ple, it does only sim­ple find and replace, but with a plug-in, it can be made to do reg­u­lar expres­sion search and replace as well. Dozens if not hun­dreds of other plug-ins are avail­able to add spell-checking, word counts, sort­ing, Uni­code char­ac­ter maps, the abil­ity to call exter­nal tools, set up cus­tom “snip­pets” of recur­ring blocks of text, and the abil­ity to make use of scripts from a vari­ety of lan­guages, vim or emacs-like key­bind­ings, and nearly every­thing else you can think of. By pick­ing and choos­ing exactly which set of plu­g­ins to install, you can be sure to get exactly as much edi­tor as you want or need, with no extra bloat.

The gedit-latex-plugin is itself a plu­gin that offers L^aT_eX–spe­cific fea­tures, such as com­pi­la­tion rou­tines, code com­ple­tion, a L^aT_eX friendly inline spellchecker, and even a PDF or DVI pre­view panel, which can be placed either to the side, or below, the edit­ing area. Don’t get me wrong, it’s a nice plug-in, and one could cer­tainly use it for all of one’s L^aT_eXing needs with­out look­ing back, but it doesn’t have quite as many fea­tures as some of the oth­ers on this list. For exam­ple, there is no XeL^aT_eX out­put rou­tine defined by default (and defin­ing one seemed like more work than it should have been), there is no auto­matic cita­tion com­ple­tion (Note added later: in fact, there is!), and as near as I could tell, only the DVI pre­viewer sup­ports forward/inverse search. It is pos­si­ble to set-up forward/inverse search with an exter­nal PDF viewer like Oku­lar, though that also wasn’t as easy as I felt it should have been. I gather, how­ever, that the default GNOME PDF viewer (evince), although it doesn’t cur­rently, will soon be updated to more eas­ily sup­port such inter­ac­tion with gedit. The plug-in is rel­a­tively young, and evolv­ing, and I expect it to get bet­ter and better.

---

KILE

Home­page
Plat­forms: Prin­ci­pally Linux/Unix, also Mac with some effort, and “exper­i­men­tal” sup­port for Windows

I’ve tried a lot of L^aT_eX edi­tors, and Kile is far and away the most fea­ture rich edi­tor I’ve tried. Kile (the KDE Inte­grated LaTeX Envi­ron­ment) is built upon the KDE Advanced Text Edi­tor (KATE), but heav­ily tweaked to become a L^aT_eXer’s dream. Kile fea­tures auto­matic code and cita­tion com­ple­tion (see below), context-sensitive help (i.e., high­light a com­mand and click to get help on that com­mand), a built-in doc­u­men­ta­tion browser, project man­age­ment, cus­tomiz­able tool­bars and quick-keys, optional VI-editing modes, inline spellcheck­ing, smart quotes, word count, the abil­ity to select by the para­graph, sen­tence, L^aT_eX envi­ron­ment or group, rec­tan­gu­lar block selec­tion mode, code fold­ing, advanced user tags cus­tomiz­abil­ity, auto-indentation, dozens of wiz­ards and tem­plates, syn­tax high­light­ing scheme selec­tion, and script­ing. Its side panel oper­ates just like texmaker’s (indeed, tex­maker likely copied kile’s), offer­ing a struc­ture and label view, code and sym­bol map and also a file browser. The bot­tom panel switches between intel­li­gent error han­dler, a log file viewer, pre­view panel and handy built-in BASH command-line ter­mi­nal. Set­ting up forward/reverse searches (jumps back and forth), whether for DVIs or for PDFs, whether com­piled with (pdf)L^aT_eX or XeL^aT_eX, between Kile and the Oku­lar viewer (another KDE pro­gram) works out of the box, and is nearly as easy to set up as in TeXworks.

One aspect of Kile that par­tic­u­larly impresses me is its Build tool man­age­ment. Unlike other edi­tors, you are not lim­ited in the num­ber of build pro­files you can have defined, and kile comes pre-defined with dozens of rou­tines, not just for com­pi­la­tion, but for con­ver­sion, view­ing, pre­view­ing and search­ing. You can define your own, mod­ify exist­ing ones, set up dif­fer­ent sub­ver­sions of the same tool, and define “meta­tools” for comb­ing sequences of exist­ing tools. (For exam­ple, you could define a tool to com­pile to dvi, con­vert the dvi to ps, con­vert the ps to pdf, launch a PDF viewer, and archive the project files into a zip file, with one click.) Dif­fer­ent build rou­tines can be set up as default for each project. I’ve added some tools of my own, includ­ing one that con­verts a L^aT_eX file to plain text and then passes that text to a text-to-speech sys­tem to be read out loud back to me, which helps in proofreading.

Kile is a great choice for both begin­ning and advanced L^aT_eX users. Although I bounce between them, it tends to be the edi­tor I grav­i­tate back towards most of the time. The only down­side I can think of is that it is fairly resource-heavy com­pared to other edi­tors, which is unsur­pris­ing given its com­plex­ity. This is espe­cially the case if you’re not already using the K Desk­top Envi­ron­ment (KDE), for which Kile was intended. While Kile runs per­fectly well under GNOME, it does require hav­ing many KDE libraries installed and avail­able, which may seem like a lot if you have no other rea­son to have them. To be fair, Oku­lar is also a KDE pro­gram, and this is cur­rently the only PDF viewer (apart from TeXwork’s built-in viewer) to sup­port Sync­TeX jumps on linux eas­ily, so a L^aT_eX user on linux prob­a­bly can’t avoid hav­ing these any­way with­out giv­ing up a lot. (This may change soon.) Set­ting up kile to work on mac prob­a­bly has sim­i­lar costs, and may require a fair bit of patience. Sup­port for Win­dows is still con­sid­ered exper­i­men­tal, though I have heard mostly good things.

---

Gummi

Home­page
Plat­forms: Linux (and per­haps other Unix-like systems)

Another new­comer on the scene, Gummi is a very sim­ple GTK L^aT_eX edi­tor with one sin­gle, truly amaz­ing, stand­out fea­ture: a live updat­ing PDF pre­view pane. That’s right, live, in that it actu­ally updates itself as you type, with no need to save or hit com­pile or anything.

There is about a one-second lag on my sys­tem for the updates, and it tem­porar­ily sus­pends itself (show­ing a red light) when the source has errors. This is fan­tas­tic fea­ture, some­thing which I’ve dreamed of since I first started writ­ing with L^aT_eX. It gives me all the ben­e­fits of WYSIWYG that I actu­ally like while still allow­ing me to do direct source-editing.

Unfor­tu­nately, how­ever, this is about the only thing Gummi cur­rently has going for it. It has syn­tax high­light­ing, spell-checking and min­i­mal Bib­TeX sup­port, but apart from that, is as about a min­i­mal as it gets. Indeed, the cur­rent ver­sion is miss­ing some fea­tures it’s rather dif­fi­cult to believe any edi­tor could sur­vive with­out, such as reg­u­lar old find and replace, much less reg­u­lar expres­sion searches. (It has find only!) It’s also rather tem­pera­men­tal, and an older ver­sion crashed on me a few times. (A rare occur­rence on linux.) But this project should not be judged too quickly. As noted, it’s very new in the devel­op­ment stage, and I have no doubt that ver­sions will be pro­duced that are more sta­ble and offer more fea­tures. I’m keep­ing my eye on this one.

---

LyX

Home­page
Plat­forms: Cross-platform (Linux, Win­dows, Mac, pos­si­bly others)

LyX is a curi­ous inter­me­di­ary between a L^aT_eX edi­tor and a tra­di­tional word-processor. The devel­op­ers describe it as “WYSIWYM”, or, What You See Is What You Mean. It is very sim­ple to use, at least for basic fea­tures, and some­one who has become accus­tomed to edit­ing in a WYSIWYG word proces­sor such as MS Word or Open Office writer will feel right at home. Unless you choose to see them, the edi­tor hides all codes from the user: titles look like titles, ital­ics looks like ital­ics, lists look like lists. Even the look and feel of com­plex math is approx­i­mated right in the edi­tor window.

But make no mis­take, LyX is not WYSIWYG, or even close. You are still edit­ing a source doc­u­ment, which is then passed on to L^aT_eX for type­set­ting. The fonts, styles, lay­out, etc., will all change, and typ­i­cally, sig­nif­i­cantly improved thanks to L^aT_eX’s advanced typo­graph­i­cal algo­rithms. So LyX rep­re­sents an ideal way of get L^aT_eX–qual­ity out­put with­out writ­ing mark-up codes yourself.

Its menus also pro­vide easy ways to export your doc­u­ment, not just to DVI and PDF, but also to HTML and Open­Doc­u­ment for­mat (used by OpenOf­fice and con­vert­ible to Word for­mat), using, if I’m not mis­taken, TeX4ht as a backend.

LyX undoubt­edly could be an attrac­tive option for many, espe­cially those whose writ­ing isn’t tremen­dously tech­ni­cal or who are mainly inter­ested in L^aT_eX for the qual­ity of its out­put, not its cus­tomiz­abil­ity and trans­parency. It is also a great way to get your feet wet in the L^aT_eX world before plung­ing head­long into the unfa­mil­iar. Sooner or later, how­ever, I think most die hard L^aT_eXers will want to move on to a direct source edi­tor. While it greatly stream­lines the process of writ­ing a sim­ple doc­u­ment, for more com­pli­cated doc­u­ments, where more unusual L^aT_eX pack­ages, doc­u­ment classes or meth­ods are called for, the lay­ers it puts between you and the actual code sim­ply get in the way. This is espe­cially true, if, like me, you rely heav­ily on custom-defined com­mands. It is also clearly geared more for straight math­e­mat­ics and per­haps cer­tain sci­ences as opposed to logic or tech­ni­cal phi­los­o­phy. I also ran into some snags set­ting it up: in par­tic­u­lar, I could not get the spell-checker to work on the 64-bit linux version.

---

GNU Emacs (with AUC­TeX, Whizzy­TeX or other plugins)

Home­page
Plat­forms: Cross-platform, with minor dif­fer­ences in ver­sions (Linux, Unix, Win­dows, Mac, and many other oper­at­ing systems)

One half of the infa­mous UNIX “text edi­tor holy wars”, the Emacs text edi­tor has been in con­tin­u­ous devel­op­ment since the mid-1970s. Yes, the 1970s, which of course makes it pos­i­tively pre-historic as soft­ware goes. Yet, it arguably remains the most pow­er­ful edi­tor in exis­tence, with approx­i­mately 1000 built-in com­mands, and since Emacs is basi­cally a text-editing envi­ron­ment for run­ning the LISP pro­gram­ming lan­guage, it can be extended to do just about any­thing. Yes, you can check your email, browse the web, send updates to twit­ter, all with­out leav­ing emacs. (Advo­cates of its rival, vi(m) like to joke that emacs would be a great oper­at­ing sys­tem if only it had a bet­ter text edi­tor.) Don’t worry too much about bloat, how­ever. If it could run on hard­ware from the 1980s, it’ll do fine on your sys­tem. Then again, learn­ing how to use all these com­mands may take you until the 2030s. It is geared to be used many com­mand key com­bi­na­tions to avoid hav­ing to use the mouse (and take your hand away from the key­board) to max­i­mize efficiency.

There are num­ber of exten­sions for Emacs to facil­i­tate L^aT_eX edit­ing. Per­haps the most famous is AUC­TeX. It has the sort of fea­tures you’d ordi­nar­ily expect, such as quick inser­tion of L^aT_eX envi­ron­ments, error han­dling, code fold­ing, and con­fig­urable com­pi­la­tion rou­tines, but also some unique ones. A num­ber of edi­tors (includ­ing Tex­maker and Kile) will offer pre­views of small pieces of a doc­u­ment in a sep­a­rate panel, but with AUCTeX’s preview-latex fea­ture, you can set up things like sec­tion titles and equa­tions to be replaced in the edit­ing win­dow with their pre­view, result­ing in a quasi-WYSIWYG feel.

A sep­a­rate plug-in, called Whizzy­TeX (com­pat­i­ble with and usable along­side AUC­TeX), uses a spe­cial DVI viewer to cre­ate a live-updating pre­view sim­i­lar to Gummi’s. How­ever, I was dis­ap­pointed that it worked only with DVI out­put rather than PDFs, and found Whizzy­TeX to be even more tem­pera­men­tal than gummi. It seemed to stop com­pletely if I tried to use a font other than Com­puter Modern.

How­ever, it may be pos­si­ble to work out such kinks with some fur­ther study, and in gen­eral, I feel as though I’ve only begun to explore what fea­tures Emacs, or Emacs for L^aT_eX in par­tic­u­lar, offers. Still, I think it can be safely said that this is prob­a­bly not the edi­tor for those who want things to “just work” with­out fur­ther fid­dling or research. Then again, it could be worse, as xkcd reminds us.

---

VIM (with L^aT_eX–suite or other plugins)

Plat­forms: Cross-platform, with minor dif­fer­ences in ver­sions (Linux, Unix, Win­dows, Mac, and many others)

VIM stands for “Vi IMproved”, built upon the Vi edi­tor, i.e., the other half of the text edi­tor holy war, men­tioned above, again dat­ing back to the mid-1970s. Vim, and its cur­rently more pop­u­lar graph­i­cal vari­ants, like gVim and MacVim, are highly con­fig­urable and script­able text edi­tors with more fea­tures than you can learn about in a life­time, although still extremely light­weight in resource usage by cur­rent stan­dards. Like Emacs, Vim is geared up for effi­cient pro­duc­tiv­ity using the key­board alone, but takes it to an even fur­ther level. Rather than offer­ing a sin­gle edit­ing mode, vim has dis­tinct modes for insert­ing text and for other func­tions. In “nor­mal mode”, ordi­nary keys exe­cute com­mands or nav­i­gate through the doc­u­ment instead of insert­ing let­ters. They do this in an extremely effi­cient way, and quick edit­ing of text, whether by the word, by sen­tence, by the line, by the region inside braces, etc. For exam­ple, typ­ing “c5w” will change 5 words (to what you type after­wards), “dap” will delete all of a para­graph. Through the use of its modes, Vim encour­ages the user to keep his or her fin­gers on the “home row”; you needn’t even overex­ert your­self for those far away Ctrl and Alt keys. Every­thing is set up for per­form­ing just about any rou­tine text edit­ing task with max­i­mal effi­ciency. Through the use of scripts and Vim’s many built in com­mands, Vim is with­out ques­tion a text-editing powerhouse.

Of course, it’s only effi­cient once you get used to it. This is def­i­nitely not the edi­tor for those who have trou­ble adjust­ing to change. The stan­dard process of point­ing your mouse cur­sor in a cer­tain spot and start­ing to type is just about as in-grained a process as any­thing could be for many of us. Any­thing that dis­rupts these expec­ta­tions is likely to be a source of con­ster­na­tion at first. But once you get accus­tomed to its method, you’ll won­der how you ever lived with­out its effi­ciency. Or so I’ve been told by peo­ple I trust. I’ve spent a fair bit of time play­ing around with Vim, and I have to say that I haven’t got­ten there yet, per­son­ally. Nev­er­the­less, the chal­lenge of sur­mount­ing this learn­ing curve reminds me of L^aT_eX itself, and that cer­tainly paid off, so I wouldn’t write this one off too quickly.

Many plug-ins for Vim exist, and the most pop­u­lar one for L^aT_eX edit­ing is the Vim–L^aT_eX suite. It does offer some nice fea­tures, includ­ing a quick-insertion tech­nique that pro­vides key­board short­cuts for nav­i­gat­ing directly to those parts of a L^aT_eX envi­ron­ment that typ­i­cally need edit­ing. How­ever, it is a rel­a­tively old plug-in, and shows its age in cer­tain ways. I was able to set it up to use XeL^aT_eX, and to make it do Sync­TeX forward/inverse searches with Oku­lar, but the process was much less easy than I feel it should have been. There are other L^aT_eX plug-ins worth try­ing, how­ever, such as the sim­pler L^aT_eX box plu­gin, or a VIM-specific port of Emac’s AUC­TeX.

---

Hon­or­able Men­tions and Others

I shall not declare a “win­ner” among the eight selec­tions above. They are all worth con­sid­er­ing, and I’d rec­om­mend each one of them in cer­tain cir­cum­stances to cer­tain users. I have, how­ever, tested out quite a few more. While I thought it unlikely that these would be great choices for anyone’s pri­mary edi­tor, here are some other options worth con­sid­er­ing, at least for use on cer­tain projects or in cer­tain circumstances:

1. L^aT_eX lab for Google docs: Nice for cloud com­put­ing, net­books, col­lab­o­ra­tive edit­ing and Google docs junkies. espe­cially in not requir­ing a locally installed TeX sys­tem. Con­sider also Scrib­TeX.
2. Gobby Col­lab­o­ra­tive Edi­tor: Light­weight online col­lab­o­ra­tive edi­tor not requir­ing cloud-hosting or a web browser inter­face; does syn­tax high­light­ing for L^aT_eX and other languages.
3. geany: A fast, light­weight gen­eral pur­pose GTK-based text edi­tor includ­ing syn­tax high­light­ing for L^aT_eX and cus­tomiz­able out­put rou­tines; per­haps a good choice for older hard­ware or USB-bootable linux systems.
4. jL^aT_eXEdi­tor: A cross-platform Java-based L^aT_eX edi­tor with built in ver­sion con­trol and a really nice sys­tem for error han­dling; this might have made the list above if the font ren­der­ing wasn’t so hor­ri­bly ugly for me on Ubuntu (a prob­lem it shares with a lot of java programs).

Some other edi­tors I’ve tried out, but, in Gricean fash­ion, won’t say any­thing more about include Wine­fish L^aT_eX edi­tor, jEdit, TEA, joe, jeHep, java­tex and leaf­pad. I didn’t con­sider TeXlipse or any of the other L^aT_eX exten­sions for the Eclipse IDE. This seemed like overkill for the pro­fes­sional philoso­phers who are the audi­ence of this blog. I also didn’t con­sider qbtex, qile, AmyEdit, or L^aT_eXila mainly because the projects didn’t seem mature enough, or they were too dif­fi­cult to install or com­pile. Searches at Source­Forge and sim­i­lar places turns up quite a few other projects in the works which may or may not materialize.

---

Installing the above on Ubuntu

Here’s a quick sum­mary of how to install any of the eight edi­tors above on Ubuntu 10.04 “Lucid Lynx”. Sorry, those of you using other oper­at­ing sys­tems or linux dis­tri­b­u­tions are on your own.

The core L^aT_eX sys­tem (TeXlive) – First you need to install L^aT_eX itself. The eas­i­est thing to do, if you have the disk space (~1 GB), is just to install a com­plete ver­sion of TeXlive 2009, includ­ing all pack­ages and a lot of tools. Open a ter­mi­nal, type in the fol­low­ing, and press enter.

sudo apt-get install texlive-full

(This pack­age, and the oth­ers below, can also be installed through the Synap­tic Pack­age man­ager or the Ubuntu Soft­ware Cen­ter for those who pre­fer a GUI to the command-line.) If you don’t have the disk space for the full texlive, then you might try:

sudo apt-get install texlive-latex-recommended texlive-latex-recommended-doc texlive-xetex

This will give you the most com­monly used pack­ages and tools. You may need to man­u­ally install cer­tain addi­tional pack­ages if it turns out you need them, how­ever, with this sec­ond option. Alter­na­tively, you could just skip this step, in which case, most likely, installing one of the edi­tors below will “pull in” some sub­set of the TeXlive pack­ages as dependencies.

TeX­works – You can install the sta­ble ver­sion in the Ubuntu repos­i­to­ries with the command:

sudo apt-get install texworks

Or you can install the cur­rent devel­op­ment ver­sion (offer­ing some more fea­tures, but per­haps less sta­ble) by adding the TeX­works PPA and then installing:

sudo add-apt-repository ppa:texworks/ppa && sudo apt-get update && sudo apt-get install texworks texworks-help-en

Tex­maker – To install the stan­dard ver­sion of texmaker:

sudo apt-get install texmaker

For the Tex­Mak­erX fork, down­load the .deb file from here appro­pri­ate for your archi­tec­ture, and open it in the GDebi pack­age man­ager to install. (It is pos­si­ble to have both ver­sions installed side-by-side.)

Gedit/gedit-latex-plugin — Ubuntu comes with gedit pre-installed. To install the L^aT_eX plu­gin, use the command:

sudo apt-get install gedit-latex-plugin

and then open Edit → Pref­er­ences → Plu­g­ins inside gedit itself, and check the appro­pri­ate box to acti­vate the plugin.

kile – From the ter­mi­nal, use the command:

sudo apt-get install kile kile-docs okular

Be warned, how­ever, that if you don’t already have them installed, this will “pull in” all the KDE libraries that kile depends upon, lead­ing to quite a sig­nif­i­cant num­ber of pack­ages to install. I’m also includ­ing the Oku­lar pack­age, since it works together with Kile bet­ter than other linux viewers.

Gummi – Down­load the .deb file from here and open it in the GDebi pack­age man­ager to install.

LyX – Easy enough. Use the command:

sudo apt-get install lyx

Emacs – For Emacs with the AUC­TeX plugin:

sudo apt-get install auctex

(This will include Emacs itself if you don’t already have it.) If you want Whizzy­TeX as well, fol­low this up with:

sudo apt-get install whizzytex

VIM — Some ver­sion of vi or vim is likely already installed on any linux sys­tem, but for the graph­i­cal ver­sion of gVim for GNOME, use:

sudo apt-get install vim-gnome

For the latex-suite plug-in, use:

sudo apt-get install vim-latexsuite

(Other plu­g­ins can be found on the vim site.)