purge doctest stacktraces

[KristofferC]

See discussion in #22075
cc @rfourquet

[rfourquet]

LGTM. What about leaving the Stacktrace: line to make explicit that only the stacktrace is omitted?

[KristofferC]

I had that first but then I removed it when I saw you had removed it hehe.

[KristofferC]

I will add the stacktrace header back.

[mschauer]

is this valid markdown?

[KristofferC]

Worked locally.

[StefanKarpinski]

❤️

[ViralBShah]

I'm late to this party, but it does appear that the stacktraces are useful.

[mschauer]

Ah, got it. So this is wrong, for example.

[KristofferC]

What does "it does appear" mean?

Also the stacktraces are kept when they either are relevant to the documentation or when the functions they contain are defined in the neighborhood.

It is hard for me to see the argument that showing six lines of internal functions in an example is a user friendly documentation.

[StefanKarpinski]

Yeah, I don't really get the pushback against this. 99% of the time no one cares about the stack traces so the default should be not including them. In the 1% cases where it's useful, we can still include it.

[tkelman]

Only one of these is showing 6 frames deep. The top handful of frames, up to the function that actually gets called, is useful to some people - it tells you where the definition is (especially when nicely linked like in IJulia) that's throwing the error in question. In a perfect world code examples in the docs would be shown as live notebook-style runnable snippets with [most of] the actual output. You might want to collapse long backtraces by default and have them easily expandable with a single click, but static markdown docs don't allow that level of interactivity.

[ViralBShah]

It appears as in as I looked at it, I felt that things looked better with stacktraces. But, I do not wish to have this PR be blocked because of my slight preference to see the stacktrace. I can imagine that having a 15 line stacktrace is not the best thing in 99% of the cases, but there are certainly cases where the stacktraces are useful to show in the documentation when the error happens.

Maybe, the thing to do is merge this, and introduce them in the 1% cases where they clearly may help.

[StefanKarpinski]

Since this is one of the main things preventing us from turning doc tests on, we should go ahead with this and if anyone feels that we really need the stack traces in some places, the onus is on them to implement the necessary Documenter.jl feature and insert the desired stack traces.