You missed the other sentence in the bug report, though: "There's a bunch of these ED.cmcode(self.loc) expressions in many of the wf-errors' render-reason methods." Take a quick look to spot other redundant ones, if you can.

Will do. Is there an easy way to test render-fancy-reason? I noticed some that appear redundant there, but can't tell if they're potentially used to parse the errors in the UI, so I held off from changing those

As far as I can tell, all of the remaining duplicate loc's are in the render-fancy-reason method, so I tested code.pyret.org locally with the duplicate loc's removed and it seems to change the behavior substantially. A local version running my pyret is on the left, production version with both loc's is on the right:

Maybe it's worth keeping the duplicate locs since it seems like it makes the UI nicer? At least in the context of larger programs, the code block display seems handy

Ideally we would use cmcode in the render-reason methods, too, and the CLI would display code snippets there too. Unfortunately, CLI error display rendering system doesn't any way to render snippets and it didn't seem trivial to add last time I looked into it, iirc.

In the absence of such a mechanism, any appearance of cmcode in render-reason (but not render-fancy-reason) should be regarded as a bug.

Why wasn't this merged?