Gabriel Scherer

My impression is that this issue is not in fact actionable: - the error messages produced are a bit long and require some training to parse - this comes from...

I think it's not so representative to compare an OCaml error message that requires a non-trivial explanation (because we unfold definitions to explain what is going on to the user)...

> the separation between the section should be clearer, perhaps using some pretty ascii art or at the very least some line breaks. That's a good point! I think we...

Regarding 'diagrams overlaid on top of code': I don't want to give the idea that we are doing "as well as Rust" on this specific thing, we clearly are not:...

Note after thinking a second more about the idea of including a blank line after error messages. Actually I think that the output we observe in the original post (with...

One interesting aspect of Rust error messages is the inclusion of a short identifier for the error, `E0412` in the example. This is something that I vaguely considered proposing for...

(Reviews are already welcome.)

I added some tests. While playing with `#show` in presence of module aliases or module type synonyms I encountered some strange behaviors ```ocaml # module U = Stdlib.Unit;; module U...

This small PR is ripe for review. I you look at the code, it is useful to compare it with the code of `#show_module` above: https://github.com/ocaml/ocaml/blob/adcf2cb2c6bea7701d399e7ec8734b55403584a3/toplevel/topdirs.ml#L539-L561

#8531 ended up closed, so maybe the smaller change proposed here would still be of interest? (But then @xavierleroy criticism of code-size increase still stands.) cc @gretay-js @xavierleroy . (I...