A wavy red underline is the established default for inline error reporting at this point, for better or worse. That's probably the best thing to use unless you're determined to make advances in graphical user interface layout, which — I hope it isn't rude to point out — doesn't seem to be a goal of Barliman, from looking at the screenshots.

If you're going to highlight errors with an error background color, I suggest blue, which contrasts better with green than red or yellow can, especially if you're somewhat red-green colorblind, like I am. Alternatively, maybe you could reduce the contrast on the whole pane except for the error, as if you were trying to scam the programmer into supplying their email address to continue reading an article.

Good point! I like the idea of using a wavy red line. Thanks!

Yeah the user interface is pretty budget right now. :) I've been teaching myself Swift and Cocoa programming, and still have lots to learn. And I've been concentrating more on the "under the hood" pieces of Barliman. But I do want to explore new interface and GUI ideas.

I suspect the interface will change completely in the future. Tom Gilray, for example, has suggested using just a regular editor window, which Barliman would parse to find the definitions, examples, optional type annotations, etc. This would be closer in spirit to the XCode interface.

One interface question is how to best specify the semantics for the language under interpretation (for example, "miniScheme"). Currently the semantics are specified by writing a "relational" interpreter in miniKanren. This is pretty low level, though. I'd like to have a much high-level specification language that looks closer to the math for operational semantics.