| HN Mirror

I have said a couple of words about Acme as you can see, and I’ve read the Acme and Plumber papers and a couple of intros; their Unixy take on Smalltalk’s “Do It” seemed ingenious in principle... But I have to admit that I always got turned off early enough in my attempts to actually use Acme (very shallow and superficial reason: non-primary-button drag is painful on a Macbook) that I can’t say I’ve given it an honest try. So the rest of this is only from my understanding of the manuals and might well be wildly wrong (I certainly hope to see counterexamples!).

OK, so what are the things that, to me, differentiate an IDE from “just” a programmer’s editor (mind you, I usually use the latter) but don’t seem to have an obvious solution in Acme?

- File tree with interactively collapsible subtrees (although this is not really an IDE feature, even Gedit has one). Haven’t seen an implementation, and don’t really see how one could fit into the UI paradigm without being awkward (would I have to select “collapse foo” to collapse the foo/ subtree? I’d much prefer to just click on foo).

- Jump to definition and list uses, using semantic analysis and not just text search. The former should be doable with plumbing but I don’t remember it described anywhere; the latter should be dead easy using something like cscope, but again, I haven’t seen an implementation, and also the interface would have to be a list of all matches and not in-file highlights, which is sometimes what you want and sometimes not.

- Rename identifier, again preferably non-dumb. Sure you can call out to a separate CLI tool if you don’t mind the lack of interactive feedback, but given the brilliant handling (theory, really) of multiple selections in Sam, I’m really frustrated Acme not only can’t accept multiple selection ranges from an external program, but doesn’t seem to support multiple selections at all.

- Autocompletion. While it is admittedly not essential for programming under Plan 9 (and that’s a good thing), in other environments unfamilliar libraries or horribly large APIs (looking at you, Google Apps Script) make it a necessity. As far as I can see, impossible to implement without forcing the programmer to take their hands off the keyboard.

- Debugger integration, or at least navigation through source files as the debugger steps through the program (showing variable values from the stack is good but optional). Should be implementable with a cooperating debugger, but once again not actually implemented as far as I’ve seen, and the lack of any way to highlight the current line will make it a bit unwieldy.

- VCS integration, at least a way to do `git add --interactive` (or equivalent) without going through a hundred questions in the terminal. Doesn’t really fit into how the UI works, unless I’m simply forced to edit patches manually. Even simply highlighting the dirty lines while editing would be tremendously useful, but the UI still can’t highlight lines.

- Syntax highlighting (yes, I went there). While you can indeed do without the classic syntax highlighting many people use, what I find helpful about it (even if I have to write my own syntax files) is that it can quickly highlight obvious syntactic programs that can result in pages of awful compiler spew: runaway strings, unbalanced parens inside a(n explicitly terminated) statement, etc. Jump to or highlight matching parenthesis is useful for the same reason, but I don’t consider it a must.

That’s a lot. Some of those things are possible, and many are, irritatingly, almost possible but not quite. But even if the UI admitted all of them, none of the tools that would implement them actually exist. Thus I conclude(d) that Acme is not a functional IDE, and while it is a good advance towards a more elegant “shell” (as GP called it) for one, the UI model is just a tad too restrictive in multiple directions. I suspect that trying to expand it in all of those directions, however, will ruin the elegance.

Just to be clear, this rant (I can’t seem to be able to produce anything else) is not an anti-Acme rant. Its point is not that Acme is a bad editor (it probably isn’t, it’s just that I can’t get the control scheme to click for me). Its point is that it is not a solution to the IDE bloat problem because it’s not an IDE. Perhaps we shouldn’t be solving the IDE bloat problem at all and just give up on the idea; but supposing that we want to, I don’t see how Acme accomplishes that.

P.S. I don’t use Emacs regularly either, but curiously the things for which I have used it in the past—Org mode, Agda mode, Paredit, and of course Dired—use its flexibility in such an essential way that not only are they impossible to implement atop Acme, they are probably impossible to do on top of the code editing widget in any other extensible editor except those that implement essentially the same ideology (Climacs, Edwin, et al.).