I've reviewed another editor which I liked the core of but couldn't stand anything else about. I really wanted to like that editor, and indeed, did like many things about it, but in the end simply couldn't use it. Today's subject is an editor that is superficially very similar. Textadept, like Sublime Text (ST), is a solid editor at its core with almost stupid amounts of configurability around it. The devil, however, is, as usual, in the details.
Some readers may note a very different tone in this review. In my previous review I was somewhat acidic when talking about the flaws of the software and its ecosystem. Here I'm more tolerant. There is, naturally, a good reason for this, one that is pecuniary in nature: I paid US$59 for ST. I paid nothing for Textadept. I'm far more tolerant of flaws in volunteer labour than I am in labour I've paid for.
I also don't really think this is unreasonable.
As before, I begin this review with all of the good points of the product I can find. Textadept has many such good points so this portion of the review will be materially longer than the previous review. Let is begin with one of the biggest differences from the previously-trialed editor.
Textadept comes with a lot of documentation, and documentation that is from the official source: the developer. It is not perfect documentation by any means, but it is reasonably complete and, once you get a feel for how the editor is constructed, it's not too bad to navigate. It is mostly reference documentation—indeed the bulk of it seems to be the API docs—so there is definitely room for someone writing a tutorial and, perhaps, some kind of "cookbook"-like user guides. Presumably this is a problem which will be solved through community effort as the editor's user base oh-so-slowly expands. (I plan a few things of my own, in fact, including a tutorial for building a language module from scratch.)
One very nice feature of the docs is that Mitchell (who only appears to go by his first name) keeps them up to date as he adds features. Given that pros who're paid for their work are almost scornful of writing docs, it's nice to see a hobbyist taking docs seriously.
And this segues nicely into the next nice thing about the Textadept experience: the lead developer is extremely responsive. Mitchell is active in the mailing list constantly answering questions, taking bug reports and feature requests and just generally providing assistance and succour to the user base. He also keeps the project wiki up to date.
To show you what I mean, during my trial period I have made several feature requests worth mentioning. Here's what happened:
- A fix to the way auto-pairing of parens, braces, quotes, etc. work was in place (and documented (!)) in under two days after receipt of the feature request.
- Changing the way the buffer switching dialogue box works was done also in under two days.
- A way to specify sessions at the command line. This was done in several days.
- A way to specify lexers at the command line. This turns out to be supported out of the box via some scripting trickery that permits users to make their own command line options. Response time for this, less than a day.
- A request related to the positioning of dialogue boxes is still in the works.
In addition, during that time span, a lot of user questions (several (dozen) of mine included) were answered, bugs were fixed and in general the user base was supported.
Of course no matter how nice the docs, how supportive the developer, it all falls down in the end if an editor sucks at editing. How does Textadept fare in this realm?
It fares well. Textadept is built, you see, upon the Scintilla text editing engine with a Lua wrapper around it. (The console version uses an ncurses-based Scintilla wrapper as well.) (There are a few more libraries involved, of course.) This is a good thing because Scintilla is a very good editor core. (I used to use SciTE as my go-to editor.)
Textadept is easily on par with Vim, Emacs and ST (to name three popular, powerful editors) in terms of its capabilities. It has all of the usual suspects: undo/redo (but not the tree structure of Vim – this is not something I ever really found a use for so I don't miss it); assorted forms of movement and selection (with practice it will be almost, but not quite, as efficient as my work in Vim); tools for manipulation of source code like commenting out blocks, and searching and replacing; syntax highlighting – pretty much everything that a decent programmer's editor needs.
There are some interesting features of the editor that I never saw in Vim but now that I use them I'm not likely to ever want to give them up again. For example while Vim and Textadept both share a powerful set of selecting text in matching pairs (vi" in Vim, for example, is Ctrl+" in TA), the equivalent of doing Textadept's Alt+" is, to my memory, a bit harder and more error-prone in Vim. (It wraps the selected text in double quotes, or if there's no selection, the token to the left of the cursor.) Even more impressive: if the word foo is highlighted and Alt+< is pressed, you get <foo></foo> supplied.
In terms of speed, Textadept is reasonably fast. It's snappier than Vim and Emacs, but it's noticably slower than ST. (When I say "noticably", I should note, this is only when I'm looking for it. Had I just used Textadept instead of assessing it for a review I'd likely not have noticed the difference.) For any realistic editing scenario I found Textadept more than capable enough (which is a given since I just said that it's faster than my previous go-to editor of choice). There are some scenarios where it falls down, however. Lexing can (and does) grind the editor to a halt if you open up a large file (in the millions of bytes range of size). If you plan on hand-editing such a file—regardless of the fact that it's obviously not intended for hand-editing—you'd best be served by turning off lexing or at the very least using the LuaJIT-based version of the editor instead of the Lua 5.2-based version. (The developer may wish to look at how editors which both do syntax highlighting and don't grind to a halt on large files do their magic.)
(I've put "misfeatures" in quotes because the opinionated world of software development will have people label these things as such.)
There are some things that will require adjustment for those used to other environments. Textadept, for example, does not provide the currently-fashionable tabbed interface. This is a design decision the lead developer stands by. His reasoning is that between the unlimited view splitting that Textadept allows and the quickly-accessible buffer browser there's no need for tabs. If you simply must have tabs you'll have to look elsewhere. This is not an issue for me: I used un-tabbed Vim as my default editor, but people used to other editors (most other editors…) might find this off-putting at first. My own suggestion is to take this in stride and learn the Textadept workflow instead of bemoaning the lack of your old one.
Another area that will take some getting used to is that searches cannot use regular expressions. They instead use Lua patterns. Lua's patterns are not as powerful as regular expressions, most specifically in the area of alternation. You cannot search for "foo or bar" as you can in regular expressions. There are a few other such restrictions, albeit more minor than this one. So not only do you have to get used to a pattern matching system that's very different from what you're already used to, you have to make do with a system that's a tad less powerful. That being said, for most practical editing purposes Lua's patterns are just fine. I've rarely missed the slight increase of power that regular expressions provide; it's mostly the alien syntax that gets to me at times.
Textadept is an insanely configurable editor. How insanely configurable? Most of it is written in Lua. You could, in principle, rewrite Textadept completely using Textadept's facilities. This puts it well into Emacs territory for configurability and has it outdoing Vim and ST by far.
The key to this configurability is the same as the key to Emacs' configurability: the very deeply embedded scripting language. Textadept is based almost entirely on Lua wrappers around a small, fast editing kernel (Scintilla). All of its expansion facilities (with one minute exception) are based on Lua scripts that have full access to the guts of Textadept if you choose to be so brave. (You won't need to, of course. It's just nice to know the capability is there should you need it.)
The choice of Lua as the embedded scripting language is, in my opinion, the correct one. Lua isn't as alien as Emacs' choice of a Lisp and it's superior to ST's choice of Python. As a language Lua is faster (by far!) than Python and is approximately as easy to use. (It has its oddities and unfamiliarities, but all languages do.) It is also smaller and easier to embed into a program than Python and this is what makes Textadept so insanely configurable; moreso than, say, the Python-based ST.
Coming from the other side of the coin, VimScript is, just to put this as baldly and bluntly as possible, a festering pile of horse dung as a language. Lua is far nicer to program in, is far faster, is far more flexible and expressive and just all around puts Vim's scripting language to shame, and while Vim technically allows other languages for scripting, it's through a very clumsy and restricted interface. Only VimScript gets full access.
Syntax highlighting is often a rock against which editors break. Modern languages and development techniques almost, but not quite, rely on it so editors' support of it is vital to their success. There are two facets of this:
- How many languages are supported out of the box?
- How easy is it to extend the languages supported?
Textadept comes out of the box with syntax highlighters for 90 programming languages. The usual suspects are supported as well as some oddball formats like "gtkrc" or "jsp". That latter one is worth taking a closer look at because it highlights one of the major strengths of Textadept's approach to syntax highlighting. JSP is, after all, not a syntax definition. It's a semi-trivial extension of HTML with Java source stuck into it.
And that's precisely how it's defined.
The syntax highlighting configuration file for JSP is 30 lines long, including whitespace and (sparse) comments. (It's under 20 lines of code if you strip out vertical whitespace and comments.) Yet, despite this tiny size, the JSP lexer includes all HTML highlighting and all Java highlighting. So how does it do this?
The answer to this is that it's based on LPEG, a Lua library for defining parsing expression grammars. PEGs have several key advantages over the more traditional approaches (based on regular expressions) to writing syntax highlighting. First, they are strictly more powerful. Second, they are composable. Third they're faster than most modern regular expression engines (the ones that can do backtracking and their ilk, like Perl's). Finally they're more readable, partially because they're composable, than regular expressions (once you've learnt them, of course).
Building syntax highlighting on LPEG is what allows the trick of defining lexers for embedded and combined language environments like JSP. The grammars can, you see, be embedded in each other. The JSP lexer is embedded in the HTML lexer, for example, and it further embeds the Java lexer into itself. (Read the docs for details on what all this means.) The result of all this is that JSP is, in effect, defined as an extension of HTML's lexer and uses Java's lexer as required.
This ability to compose lexers permits great flexibility in the definition of new languages. Composite grammars abound in the default support. HTML embeds CSS. ERB is embedded into HTML. You could easily conceive of documentation formats, like JavaDoc, say, being embedded into source comments. The various components would be independently modifiable while still being used in composite forms.
Some of the things I praised in ST included the "Goto Anything" functionality and the command palette. Textadept doesn't have quite the power of either of these, but their rough equivalents—AdeptSense and command selection—are close enough for jazz. The latter doesn't have the awesome fuzzy search of ST's command palette, but for that I actually think AdeptSense is better-constructed and more useful. (For starters it can work with tags files out of the box instead of needing a plugin.)
Command entry is pretty powerful as well: you get, in effect, a Lua prompt and can access anything in the Textadept API as well as the entirety of the Lua programming language. This is a powerful tool for complicated functionality (and for debugging your inevitable configuration problems for which q.v. below). One of the interesting things you can do with the command entry tool is make custom tools of your own and add them seamlessly to Textadept. (Indeed, this is exactly how the search/replace feature is implemented.)
Code snippet handling is also nice. It's arguably the nicest rendition of snippet handling I've seen (although, to be fair, I rarely use snippets so I may be missing out on some awesome stuff).
So that was the sales pitch. Here's where I put on my critic's hat. As with any software, Textadept is not perfect. It has sharp edges, misfeatures (in my opinion, of course) and problems. Much of this is mitigated by the aforementioned documentation and developer support, but a review which does not highlight these is remiss.
First the big one: the default theme, the one you see when you first open the editor, seems to be designed for maximal eye strain. Let's take a look at it (and keep in mind that I'm not using the default font):
I'm not sure how that theme was selected as the default one, but to my eyes, the light grey background and the not-quite black text are difficult to see. Comments are almost invisible against the background too. Luckily there are other themes that come with the set as well as themes available on the community's wiki.
There are some usability issues that will bite first-time users as well. Here are some of them:
Session management in Textadept is confusing. If you fire it up by just typing textadept at the command prompt, you get the default session which is basically just the setup you last had when you fired it up without specifying a session. Exactly what Textadept does vis a vis sessions is complicated and hard to figure out at first. You can get used to it, but it definitely compromises the principle of least surprise several times in the learning process.
One mitigating plus: when I started my evaluation I couldn't specify the working session at the command line. Now I can. Thanks, Mitchell, for your prompt attention to feature requests!
As with most GUI tools in the Linux world, you have to use a stupid shell trick if you want to launch the editor cleanly from the command line. Vim doesn't require this trick, however, which leads me to believe that this is something that could be solved without forcing users to waste CPU cycles and RAM to launch a whole new subshell just to launch a program and then go away.
Text-based configuration … with a vengeance
Textadept is ridiculously extensible, but this ridiculous extensibility comes at a price: a massive cognitive load when you're configuring the editor. ST uses JSON format for most of its configuration files (with the exception of code snippets which use an XML format). Textadept uses Lua for all but one case (file type associations are defined in a file that doesn't match any format I've ever heard of). In this regard, Textadept is far more regular than ST was (and only marginally less regular than Emacs). So what's the problem?
The problem (shared by Emacs I hear) is that using a Turing-complete language for configuration is a very easy way to shoot yourself in the foot. A really stupid syntax error in my init.lua file resulted in an unusable editor. I learnt very quickly to put my ~/.textadept directory into revision control just to preserve my sanity.
The other problem that all this text-based configuration causes is confusion. There are lots of configuration files in a typical Textadept setup; until you internalize the rules for which ones are executed when you are going to get hurt. I found this one out the hard way when I installed a theme file that changed my indent size to 2. It was driving me nuts. I'd change the tab spacing which worked fine – as long as I typed the tabs after text. Any tabs typed in the whitespace in the leading part of the line only inserted two spaces. Of course this also brings up the question of why a theme file was changing my tabs, but that's because the contents of configuration files are purely one of convention: any configuration file (outside of the file type association one) can have any Lua code you like in it, accessing the full power of Textadept's API and the Lua programming language. (I would recommend carefully inspecting any and all third-party plug-ins before using them as a result…)
Now much of this confusion can be mitigated by the documentation. Unlike, say, ST, Textadept's documentation is complete and up-to-date. It's not necessarily the easiest to navigate, but it's all there. You can learn this (unlike, say, modifying menus in ST). It's just a bit daunting.
One thing that stood out for me while learning Textadept was that in some cases the editor wanted LPEG grammars and in other cases it used Lua patterns. This did cause some confusion and frustration at times, especially since Lua patterns can be underpowered for some use cases. Once you learn which goes where, mind, the problem goes away. It is still something to watch for, however.
The web site (specifically the wiki), has quite a bit of built-up cruft in it. There are, for example, themes and other packages available that are for earlier versions of Textadept that are not clearly labelled as such. Given the whole ability of a badly-written configuration file to kill the editor for all practical purposes, these crufty pieces need to be better labelled or moved into a section that clearly labels them as legacy.
The Textadept community is small. Very, very small. The result of this is a marked lack of modules and language support (beyond syntax highlighting). The community that is present is a good one: friendly and quick to respond. You will, however, frequently have to roll your own solutions if you want something done. How much of a minus this is depends a lot on your proclivities and on how much the existing support meets your needs.
There is one final issue that is not really a "good" or a "bad". It can be either depending on your personal perspective.
ONLY an editor
Textadept is almost militantly only a text editor. It offers limited support for compilation and execution, as well as filtering text through commands, but it is emphatically not an IDE or a project manager. For some users (myself included) this is actually a selling point. For many others this is a show-stopper. People looking for a capable text editor will not be disappointed with Textadept. Those looking for a full-fledged development environment (or at least a project manager paired with a text editor) will have to look elsewhere.
Now, I should point out that it would be possible to turn Textadept into a better-supported environment. I've already seen ways, for example, of adding debugging support to the mix (and may do it for Mercury for a lark). Doing this, however, would require a lot of difficult, complex, error-prone work. It's not really feasible for anybody who wants a tool that works instead of wanting to make a tool effectively from scratch.
Textadept is a spiffy little F/OSS editor that has accomplished the impossible: it has replaced Vim as my default editor of choice. Despite its flaws, I find it to be the best blend of capability vs. usability of the editing tools I've tried so far. Its edging out of Vim is marginal, but sufficient for me to make the switch.
Should you follow me in this? That depends very much on your needs and wants. If you want a small, fast, powerful text editor out of the box that works roughly the way you'd expect it to work most of the time (instead of the idiosyncratic approaches used by similarly powerful editors like Vim or Emacs) and are unafraid of getting your hands dirty to make your own modules then Textadept is likely for you. If you want an editing tool (and only an editing tool) that allows you to hit the ground running, depending on which languages you're using this may or may not be the case out of the box. If you work in oddball languages (like me) and are not interested in configuring your editor, however, you'll probably find Textadept off-putting.