Improve visibilty of line location in stacktrace e.g. Ability to override/disable muted colour in stacktraces

[nickrobinson251]

Having updated to use the new Julia v1.6 release, i see that there's improved stacktrace formatting.

I really appreciate that Julia tries to make these kind of usability improvements! The colouring of modules, for example, is a really helpful addition for more easily seeing the source of errors.

I know that making somewhat opinionated choices about UI, especially colours, is a tricky business, and from looking at the issues and PRs, a lot of care and effort has gone in (#36026 / #36134 / #37773).

However, i do have a bit of an issue and am wondering if something in Base can help:
I now find it difficult to read the filepath/line location of errors, due to the muted grey (:light_black) colour of this info. (Unlike the module colour change, i find this change makes it harder for me to see the source of errors)

This is a significant drop in useability for me. For context, i work as a full-time Julia programmer and basically live in the terminal, so am spending tens of hours a week in the Julia REPL. And it being difficult to read where errors come from is something that effects my day-to-day work. Which is to say, i don't just want to be picky about colour-schemes - i'm opening the issue because it's a change that effects my work quite a bit and because i'm hoping there will be a simple way to avoid it.

I'm wondering if there could, for example, be a way to "opt-out" of various bits of colouring, and just have the colour set to :normal? Essentially, i'd like to be able to set everything that's :light_black to use :normal instead.

I see there are already various environment variables for customising the new stacktrace printing (JULIA_STACKTRACE_EXPAND_BASEPATHS, JULIA_STACKTRACE_CONTRACT_HOMEDIR, JULIA_STACKTRACE_LINEBREAKS).

I wonder if it would be possible to add one (or two) extra?

• e.g a JULIA_STACKTRACE_COLOR_LINES which could default to true, but could be set to false to have :normal used .
  • we may then want a JULIA_STACKTRACE_COLOR_MODULES to match (again, i've no personal need for this; i'd leave this set to the default true)

i'm not hoping/expecting to have full customisability in Base, but the ability to "opt-out" and instead get the more conservative error printing that was in the previous Julia v1.x versions would be appreciated.

---

Some more detail:

My terminal has a fairly standard dark background and looks very much like the image from the v1.6 announcement blog:

I believe is I use ITerm2's default Dark theme. (I think ITerm2 is the most commonly used terminal on MacOS). It looks like this (apparently a little less dark than the one above):

I find e.g. the text ~/.julia/packages/Tables/UxLRG/src/tofromdatavalues.jl:42 difficult to read, where tofromdatavalues.jl:42 is usually really useful info that i'm looking for.

i just mention this for the sake of being specific :) And, in case it's relevant, to say i don't have a really unusual, highly colourful theme. Also i suspect that for lots of people the lines are easy enough to read, and I have no qualms with this being the default appearance. I don't have great vision (i wear glasses), but beyond sometimes bumping up the font size don't usually have problems reading stuff in the terminal or elsewhere.

I really don't want to get into a debate about which colours to use, or to try to find a colour-scheme that works with every possible terminal theme (which isn't possible). i'd just prefer to find a way to set 'normal' colour for this text.

Thanks for any help!

[nickrobinson251]

If we were open to tweaking the default printing, changing the underlined text to be printed in :normal would resolve this issue.

i.e. instead of

we could have

The fact we underline this already suggest this is more useful info than the rest of the line, and changing the print this in the 'normal' colour would actually simplify the UI: rather than 4 greys (underlined-light_black, light_black, normal, bold) we'd have 3 (light_black, normal, bold).

Code-wise, this would be a one line change in src/errorshow.jl, to replace print_underlined(args...) with printstyled(args...; color=:normal

Would this be acceptable?

[mcabbott]

• Notice that the constructor Dataframe isn't printed in bold, in frames [5] and [6] of this example, that's a bug I think. fixed.
• Should the location printed by e.g. @error "msg" 1+1 match more closely? At the moment it isn't underlined, perhaps it should be. And stack traces are changed, should its file name also be printed :normal?

[nickrobinson251]

Would you mind opening another issue about any current inconsistencies? You might be quite right, but I'd really prefer not to get into a discussion about the possible general aesthetics of the printing in this issue. I'd like if possible to find a way to work around the issue i now have of not being able to easily read info that i rely on for daily work (while appreciating that the new/current defaults might well be a great choice for most). If we can find a solution to that, then ideally it'd apply consistently all contexts (e.g. filename/line location from @error as well as stacktraces), but for stacktraces alone would be good enough for me.

[nickrobinson251]

Related: #38730

[nickrobinson251]

Here's what the default stacktrace printing looks like in the default GitLab CI view

[bencottier]

I also find it difficult to read, and most of all in the default GitLab CI view. The line locations are very often what I need to focus on to debug an error.

[dpo]

I concur that the current stack traces are unreadable when using a dark theme.

[matthieugomez]

+1. I use the dark solarized theme in Mac Terminal. Line location is the most important thing for me and it's almost invisible.

[linwaytin]

I run into the same issue described by the OP. The paths and line numbers are so dim that I can barely see it. Is there any way to change the color?

Thanks.

[nickrobinson251]

I see that this got closed -- that's great! thank you to everyone who's worked on a solution for this!

The linked PR (and description) looks... complex 😅 Can someone summarise how it closes this specific issue, perhaps sharing a snippet of code?

i.e. How specifically can a user change how the file:line info appears in all stacktraces?

[tecosaur]

#49586 took us halfway to resolving this, but we still need to apply it to stacktraces