Description
Ref #172
The high level problem I ran into with integrating annotate-snippets into Rust---and specifically, an upgrade from 0.9 to 0.11---was that trimming long lines automatically inserts a .... This is somewhat problematic in Python specifically because a ... is itself valid Python and not that uncommon. For example, with ..., it's hard to tell the difference between a line being trimmed and an actual line. Here's an actual example where it's ambiguous:
use annotate_snippets::{Level, Renderer, Snippet};
fn main() {
// Taken from: https://docs.python.org/3/library/typing.html#annotating-callable-objects
let source = "def __call__(self, *vals: bytes, maxlen: int | None = None) -> list[bytes]: ...";
let src_annotation = Level::Error.span(4..12).label("annotation");
let snippet =
Snippet::source(source).line_start(1).annotation(src_annotation);
let message = Level::Error.title("").snippet(snippet);
println!("{}", Renderer::plain().term_width(83).render(message));
}I futzed with the terminal width here a bit to make it ambiguous for this specific snippet, but I think this gets the idea across.
In #172, I tried to approach this problem by making it possible to override the indicator to something else. For us, we're thinking of using … (U+2026 HORIZONTAL ELLIPSIS) since it gets the same idea across, but should hopefully be less confusable with actual Python syntax. Of course, I think it's true that any choice here could always risk being confusable, but ... is far less likely to result in ambiguity for, e.g., Rust code than it is for Python code.