Does the lack of "native" support for real-time linting, debuggers, formatters, etc get in your way? Did you manage to integrate such features in your workflow?
Go tooling actually works surprisingly well in Acme, because the tools tend to print out files with line numbers for errors, then when you click on that line number Acme will take you directly to the line in question.
Here's a sample workflow: I'm hacking on some code in /home/john/foo. I have a directory window open in /home/john/foo, plus the files foo.go and foo_test.go open. I make some changes in foo.go, then in the directory window I type `go test`, select it with the mouse, and middle-click. This runs `go test`, creating an "Errors" output frame in the rightmost column. If the tests pass, this frame just says "PASS". If the tests fail, it'll say something like `./foo.go:27:10: undefined: xyz`. I right-click on `./foo.go:27:10` and Acme immediately takes me to that like in the appropriate file. I make a change, execute "Put", and then middle-click `go test` again to try the tests once more.
The delve debugger also prints line numbers that work with Acme. I run delve in an Acme terminal, and when I e.g. print a backtrace, I can simply right-click any of the line numbers to jump immediately to that code (Acme will open the file in question if it's not already open).
acmego will run gofmt and automatically add/remove imports as necessary every time you save the file, which is a huge convenience.
There's no syntax highlighting, which is a huge dealbreaker for some people. Personally, I find it distracting to watch huge swathes of my file change colors because I typed ", then change back as soon as I close with another ", so the lack of highlighting is great for me.
Edit: in my sample workflow above, I mentioned typing `go test` right in the directory window, but that's just ephemeral... you'll lose the commands if you refresh the file list, etc. A more permanent thing is to drop useful commands into a "guide" file in that directory; that way you can keep a whole suite of commands to run tests, run benchmarks, build & deploy, etc. right at your fingertips.
One of the main argument for Acme was that keyboard navigation is tends to be one dimensional, whereas navigating with mouse is two dimensional.
I find it curious that a higher-than-one dimensional representation of a program is not present: proper syntax highlighting makes debugging much faster.
Say, I want to see some expression with deeply nested parenthesis (lisp-style, or nested function calling in Python) is matching. I can do that with my eyes, checking the color of the beginning and the ending parenthesis. Same goes for, say, if I want to find a string in my program. I don't have to care about the quotation mark, I can just look at its color being different from the rest.
Executing commands with the mouse is heavily underrated and is a behavior I fail to faithfully replicate in i3 - or even Emacs, for that matter - but only if you guys had syntax highlighting...
I consider the lack of highlighting part of a "calm" interface: the only thing that changes as I type, are the characters that I type. But maybe that's just Stockholm Syndrome after 15 years of Acme! :)
When I need to check nesting levels, I use a little acme-trick: double-click on the closing mark (works for parentheses, curly brackets, quotes, probably more) and it'll highlight everything contained within that level. So if I type (some (big (lisp (expression)))) and want to make sure I got the right number of parentheses at the end, I just double-click on the last one and make sure the whole expression gets highlighted. Here's a screenshot: https://i.imgur.com/Qyvv2K9.png
I don't find I need to do it particularly often when writing Go, though, and if I do... well, I start to think about refactoring to make my function invocation less obtuse, or whatever.
Interesting! But you see all of the benefits of syntax highlighting and real-time linting is about being steered towards a working code in a gradual and unmotivated way, prior to actually intending to check whether the code works... Although I'm not sure how critical this really is. My personal argument for them might really `only` be habit.
Does the lack of "native" support for real-time linting, debuggers, formatters, etc get in your way? Did you manage to integrate such features in your workflow?