Open iitalics opened 1 week ago
It is not clear to me that any change is desirable here. I can see some use-cases where breaking lines at 80 columns is undesired, but many use-cases where not breaking lines is undesired (because it makes the output unreadable), especially if users have observed the previous behavior and come to rely on it. I think that changing this behavior today would introduce more problems than it solves.
I don't think it is reasonable to expect users to post-process the output to implement a rendering layer. (For example there are newlines in string literals as well in the output). If they wanted to do this they would need a non-rendered intermediate representation instead of a string, at a more complex type than show
provide. Or we could think of alternative show
variants that bring more control on the pretty-printing logic, enabling to disable it or (for example) to set a different margin. Do you have a suggestion for how such an API could be introduced without breaking backward-compatibility? (Maybe a different deriver is the best route.)
show
is a very blunt tool that does a passable job at low cost. If you want something more precise in any given direction, the answer is probably going to be a recommendation to use something else instead.
When you use the generated function
show
it will break lines at ~80 columns, inserting newlines into the returned string:This is not desirable since semantically,
show
does not have any context for how the string will be used so it should not be making assumptions about a column limit.The reason is that the underlying formatting function
Format.asprintf
uses preconfigured formatting configuration which sets a max_indent margin.