Kelimion
commented
2 weeks ago I thought I'd try it out and hit a bug right away. :-)
package main
main :: proc() {
foo := 4, 2
}W:\Odin\src\error.cpp(475): Assertion Failure: `line_length_bytes >= 0` Bounds-checking error: line_length_bytesAs for the example that started it, it renders the chevrons as >< before the identifier in question.
W:/Odin/bug/bug.odin(5:9) Error: 'växjö' declared but not used
><växjö := City { "foo" }
W:/Odin/bug/bug.odin(5:25) Error: Cannot convert '"foo"' to 'int' from 'untyped string', got "foo"
växjö := City { >>"foo"<< } These bugs aside, I much prefer the old ^~~~^ visual style. It's much more subdued than the gaudy yellow chevrons. Even without the colors, >>here<< just comes off a bit shouty, tbh. I've used that style before when I'm tracing a particularly hard to track down problem, but it's a bit much for regular syntax errors.
Now unfortunately that means that without the chevrons we can't rely on the SGR wiggle code and must align and print them as before.
But I'd be remiss not to commend you for the test suite you put together. It's going to come in very handy in putting this issue to bed.
gingerBill
Feoramund
UPDATE: Alright, I went the long way around, but this new fix should satisfy everyone.
I've re-implemented the squiggles, except this time I'm using a library I wrote based off all the Unicode grapheme cluster parsing code I wrote for the Odin core library collection, ported to C, then stripped down to fit into the Odin compiler with some adjustments.
In short, the squiggle length and position are now calculated off of real visual width based on the Unicode standards I've cited before. It's the same code powering the Unicode support in
core:text/tablenow, just in C, inside the Odin compiler.To be clear, not much has changed visually. I made the squiggles trail off
^~~~ ...if the error line trails off with ellipses as well.(Everything below this line applies only to the old solution. I've left it intact, in the event the ideas are useful to someone in the future.)
The Joy of... Appreciating Errors?
Well, maybe.
I didn't want to leave the notes on #3755 or the core issue of #3743 left alone, so I thought for a bit on how to best solve this. As has already been stated, calculating Unicode visual width is difficult.
So why not approach the issue from a different angle? I can't say it's a new one, but it's underused, for sure.
The terminal already gives us everything we need to underline ranges of any size or character encoding. It could be Latin-1 or Shift-JIS for all we know. Simply insert the right ANSI SGR codes at the start and end. Let the terminal figure it out; it has all the font, glyph, and styling information already.
I know Rust, Clang/LLVM, et cetera use padded out
^~~^, and there's some precedent for that style, but I think this is the simpler solution.There is only one caveat to this solution. It's minor but worth noting. Because we (1) don't calculate visual width, but we (2) do perform truncation, there's a chance for the displayed line to be longer or shorter than the
MAX_LINE_LENGTHvalue.Everything will still be aligned though, because there is nothing to align.
I'm open to styling suggestions. Try this out in your terminal with your own font and colour configuration. It's likely to look different from the picture. One old terminal emulator I tried misinterpreted the wiggly underline as a slow blink, so that was interesting. The rest supported it with no problem. I did spend a while trying out different colours, colour combinations, marker characters (1 or 2, ASCII or Unicode dingbats), et cetera. I found this to be the most appealing without being burdensome, but I also have been testing it for some hours, so I'm a bit saturated.
This is the test suite I used.