> So yeah, I guess no beautiful theory on error recovery.
People tried, believe me: back when running compilers as batch jobs i.e. non-interactively was the norm, it was expected for them to find as many syntax errors as possible in one go, so the programmer could fix as much of his program as possible before resubmitting it.
But yes, simple "when parsing list of X, skip until you find something that looks like the end of X (or start of another X/whatever is expected after the list of X) and try to parse another X" works surprisingly well, especially in statement-oriented (block-oriented?) languages: you can almost always reliably detect an end of the block/function or a start of top-level declaration and start from that point.
The most difficult to sensibly catch error, in my experience, happens inside the lexer: the case of a run-away string. Add a random quote mark in the middle of program text and suddenly, everything after it produces completely different, mostly nonsensical, stream of tokens.
Having just this week gone through reviewing (with AI etc) an old vim plugin of mine[1] that tries to add worthwhile features to an editor, that is, vim, and knowing tonsky's Clojure work for a long time (formerly possibly having featured him, don't remember the details, on a '14 clojure open source newsletter I used to run, the one linked below being a spiritual successor to that one), I have the deepest respect for him and open source authors greatly improving the dev experience for everyone else, especially on Emacs and vim, but before learning vim I used to use Sublime and I gotta say I miss the sleek factor, and this post actually made me want to use that again along with this repl impl to get some Clojure hacking done again, after so long away from it. Clojure is a real blessing, I wonder it has really fallen so much out of favor since the heyday in 2014, maybe to Elixir, can anyone comment?
I really appreciate the author's quest for better Clojure tooling. But I don't like their advocacy for "one code format to rule them all". Imposing single uniform code formatting standards is a common refrain from tidy software engineers -- but it is a little too tidy -- and invites criticism. My favorite response comes from a Meat Beat Manifesto song, https://www.youtube.com/watch?v=1PPuRuKVc6k, where toward the end you can clearly hear a relevant sample a few emphatic times: "Make them dance the same dance". I tend not to enjoy goosestepping myself, and prefer to choose to move in a way that feels more natural and personal.
Seems like building off of a Lezer grammar for Clojure would have been the way to go. It's lightweight, fast, and supports very fast incremental re-parsing. [0]
If anyone wants a fun project, adding Parinfer [1] support to lang-clojure [2] for CodeMirror 6 would be welcome.
