Formatting of Stacktraces

[yurivish]

(Originally posted in a different issue; moved here at @KristofferC 's suggestion)

I've noticed that it often takes me a while to orient myself when viewing a stacktrace -- and that the time could potentially be saved were the information presented in a a slightly different way.

Here's a screenshot of an error traceback:

One main purpose of a traceback during interactive development is to focus the user's attention on what went wrong and where it did so. From that perspective, the first useful piece of information above is in the row labeled [2] -- once you've seen that and correlated it back to the source line, you can start to understand the rest of the traceback.

In that light, I'm wondering how difficult it would be to emphasize the paths or lines indicating "user code", so they can draw your eye first and give you the context you need to interpret the rest of the stack trace?

There are a number of circumstances where the distinction between "user" and "non-user" code is less clear, such as when doing package development, or testing at the REPL code written elsewhere, but if there are simple rules that would work the majority of the time... Even just highlighting the "topmost" (non-REPL-internal) user-written code would notably improve the debugging experience and save people a lot of time.

Also, the white ) seems superfluous to me -- it catches the eye and doesn't supply any new information. Maybe just highlight the function name instead?

[KristofferC]

The white ) highlights that the function signature is over and that the line info is about to start, so I kind of like that.

Highlighting the first non Base frame is something I have thought about (also xref KristofferC/OhMyREPL.jl#24), but not sure how it is best done. Perhaps bold all stackframes that are not in Base... Would need some experimenting to feel it out.

[c42f]

Another thing which might be useful would be to use the display width for intelligent wrapping when printing frames in a terminal. At the moment functions with lots of arguments just overflow the line and spill into the first column which can be confusing.

[antoine-levitt]

Agreed that it would be very good to have this, see #22653.

[StefanKarpinski]

Slightly off-topic, but since we're interpreting debug/info/warn/error messages as markdown, would it make sense to print them wrapped and flowed like markdown output, taking into account the screen width? (Question for @c42f mainly, but @fredrikekre and @KristofferC also.)

[KristofferC]

It should be noted here that for the ConsoleLogger, the same backtrace filtering as the REPL does should likely be added which means that for this particular example only stackframe [1] and [2] would be visible.

[c42f]

@StefanKarpinski absolutely part of the plan, I may try this as part of #25370 (see also #25370 (comment) ). The tricky thing will be persuading the markdown formatter to do the right thing at the same time as adding some extra decorations.

[StefanKarpinski]

Not urgent, but will be nice in the fullness of time.

[pfitzseb]

In that light, I'm wondering how difficult it would be to emphasize the paths or lines indicating "user code", so they can draw your eye first and give you the context you need to interpret the rest of the stack trace?

Just as a reference: In Juno we highlight stacktraces in three different shades -- lowest opacity for stuff in base (lower two lines) and highest for user files (not in a package and not in base):

This is obviously difficult to do in the REPL due to the color limitations imposed by some terminals (especially on windows).

[KristofferC]

Closing this based on the new stacktrace formatting.