▲ 16 points

Ask HN: Modern Acme/Wily editor clones?

by rcarmo·12y ago·3 comments·view on hn ↗

After spending a few days fiddling with Plan9/Inferno, the Acme editor/"IDE" has grown on me somewhat (it's an acquired taste, but exceptionally handy to, say, run a command from inside it with a click and have the output on a new buffer).

So I started asking myself if there were modern alternatives that could be used with a trackpad, had syntax highlighting and other niceties that the Plan9 zealots consider "unfeatures" (and are thus absent from Plan9 in User Space or Acme-SAC).

After all, with a new fancy Webkit-based editor coming out every month, someone would have thought of that already, right?

But, alas, no. There's http://jakme.googlecode.com (which seems little more than a PoC) and https://github.com/fmoralesc/plan9-for-vimspace (which is promising, at least for me), but nothing else I can find.

Is there anything else out there?

3 comments

I use acme on a daily basis for Real Work™. Previously, I was an Emacs junkie, but upgrading el-get caused me grief for the last time.

I haven't heard of anything about "modern" acme clones, but I've actually found acme as-is from p9p to be palatable on a MacBook Pro. There's one chord that I've found to be nigh on impossible to sort out (for those keeping track at home, the 2-1 "execute with argument" chord), but I find that I don't really use that one a whole lot anyway.

On Linux, YMMV, but I've noticed that it's more than usable on a ThinkPad with the standard fare TrackPoint pointing device, at least once you disable, e.g., Canonical's emulation of middle-button scrolling as you'd find it on Windows. Once you get past that, it's swell, and all of the chords are accessible.

As far as some of the "unfeatures" concerns go, taking note that I'm not a Plan 9 zealot but a disciple of the Unix way of small, composable programs that all do one thing and one thing well, I can understand why something like syntax highlighting would be labeled an unfeature. Acme only provides an editing surface and a way to make text active; the rest of the functionality is provided by the myriad little programs that you likely already have installed.

Syntax highlighting would have to be provided in some form by an external program, and if such a feature were to be implemented, the community would want it done right and in the spirit of Plan 9 and Unix.

To play devil's advocate for a moment: ANSI (or some other encoding for this information) would be a suggestion, but then the concerns would likely arise about hiding information behind the text, which has been given some degree of meaning outside of merely being something painted to the display. Or, perhaps, someone would ask why there's a half-cocked reimplementation of drawterm suggested being embedded in acme.

I'm sure you'll find that a lot of people would not be opposed to seeing syntax highlighting and on-the-fly indenting and similar enhancements make their way into acme. The detractors will likely oppose the additions on the grounds that it may make acme more monolithic, depending on how each embellishment is written into the editor.

I see your points, but I disagree with highlighting being provided externally. The text rendering surface ought to be able to do it -- there are plenty of libraries that do a decent job of language auto-detection, for instance, all the more so in the JavaScript space.

My curiosity stems mostly from the fact that things like CodeMirror and ACE have been available in the JavaScript universe for a while (and LightTable, Atom, etc. leverage those kinds of "surfaces") and yet nobody seems to have tried to get, say, node-webkit to run something like acme.

So 1) all that's really necessary is the smart surface, 2) there are known instances of said surfaces (and plenty of people using them for a new generation of editors) and yet 3) nobody seems to have thought of reimplementing acme atop them.

Minimum viable syntax highlighting might be the distinguishing of commented text from other text. The Pikeman is presumably not averse to that since that is how the standard library source is presented on the golang website.