Tamas, thank you for you reply.
Do I understand you correctly that you imply I should better abstain from further suggestions on this topic until I have better understanding of the Julia internals: just let the experts do the work and wait patiently for what comes?
No. Whatever gave you this idea?
If anything, you should consider contributing to the solution. This is primarily a user interface problem, which means that you don’t need to know about language internals to make improvements.
Even exploratory PRs that fix one minor thing can be a significant improvement. Eg color highlighting of matching {}s, or breaking lines in at meaningful chunks of type parameters, could be nice.
Is there a way to get the stacktrace as an object, I assume a vector of frames or something like that? That would be handy for prototyping solutions.
The error handling code is in base julia. Look eg at https://github.com/JuliaLang/julia/blob/master/base/stacktraces.jl, https://github.com/JuliaLang/julia/blob/master/base/errorshow.jl
I just want to mention that in general it looks as if fixing this kind of issues is technically very hard, and that any attempt to fix them will be met with institutional inertia. My experience is that is the opposite: it’s just that the people who routinely commit to julia are the people who are least bothered by this kind of issues because they are used to it and tend to be pretty busy anyway, and so this kind of things just doesn’t happen. I’m not familiar with julia’s codebase, nor am I an expert hacker, but still I was able to submit Duplicate include(::String) for nicer stacktraces by antoine-levitt · Pull Request #33087 · JuliaLang/julia · GitHub, which was very simple but still made my life better and got merged pretty quickly. Also a nice option for more disruptive changes is to make an external package (maybe that pirates base, eg by overloading Base.show_backtrace) to encourage people to try it out and polish it, and then merge it to base julia.
