When using atddiff to compare two revisions of the same file with git (git difftool -x atddiff), we don't have a convenient copy of each file at hand. They are passed to atddiff as temporary files but once atddiff exits, they're lost. Currently, atddiff, like all the other atd tools, only prints error locations as
File "path/to/file.atd", line 42, characters 13-17:
This works fine when the IDE parses the error message and opens the file at the correct location. In other situations, it requires obtaining a copy of the file and opening it manually. It is tedious in the following situations:
when using atddiff with git difftool as mentioned above;
when reading logs from a CI job.
To improve the situation, I think we should print a few lines of context, with some highlight for the region of the error. I did this before and it is sufficiently hard to do well that a standalone library may be warranted. Features of such a library should include:
support multiple sources of input: file, string
specify region by line range, line/column range, or byte offset range
ignore out-of-bounds errors when requesting invalid ranges
use color if terminal allows
support caret highlighting as a fallback (^^^) - ok if it doesn't work correctly with non-ascii or non-monospace characters
minimal external dependencies so that most compilers or file analyzers can use it
bonus: avoid breaking multibyte character sequences
bonus: provide options allowing for HTML output or similar
When using atddiff to compare two revisions of the same file with git (
git difftool -x atddiff), we don't have a convenient copy of each file at hand. They are passed to atddiff as temporary files but once atddiff exits, they're lost. Currently, atddiff, like all the other atd tools, only prints error locations asThis works fine when the IDE parses the error message and opens the file at the correct location. In other situations, it requires obtaining a copy of the file and opening it manually. It is tedious in the following situations:
git difftoolas mentioned above;To improve the situation, I think we should print a few lines of context, with some highlight for the region of the error. I did this before and it is sufficiently hard to do well that a standalone library may be warranted. Features of such a library should include:
^^^) - ok if it doesn't work correctly with non-ascii or non-monospace characters