-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reorder error message parts for single source lines #9
Comments
This is a good comment. I'm not sure how best to handle the formatting. I think it's mildly orthogonal from the RFC, but still worthy of consideration in general. @estebank may have thoughts here! |
I see a few solutions to this, none of them exactly nice:
Of all of these, I'm partial to the first one, as it is the easiest to read. Diagnostics could have a flag stating that the readability is heavily reliant on the order of the spans. If it is set and the span labels would be rendered out of order, use that presentation, so that we get the more compact representation for:
|
Funny, this is what we used to do, but we moved away, because it was kind of hard to read -- it felt easier and lighterweight to see the labels "in context". |
What about numbering them?
In that case my vote would be for something like this, where both the numbering and ordering of the text make it very clear (at least to me) of how to read the text:
|
Isn't that the wrong ordering for the narrative structure? It should be:
|
Numbering is an interesting idea, though:
Note that this particular case -- a function call -- is the "worst case" in terms of violating expectations. The others work more smoothly. |
Coming back to this, I don't think the following looks too bad:
|
IMO that one combined with numbering would be the easiest to follow. |
I don't know that this is the level of detail that matters yet, but here goes.
The single-line errors don't follow the narrative structure in the order that they're displayed:
It would be easier to understand if the vertical lines connecting the spans to the messages could be tweaked somehow to allow the messages to be vertically ordered to match the code's execution order.
The text was updated successfully, but these errors were encountered: