Michał Muskała

This indeed does look quite concerning. There's nothing that immediately jumps to my mind that could cause this. It would be very useful, if I had a chance to reproduce....

Thank you for the analysis. This looks quite concerning. A good long-term fix would probably come with https://github.com/erlang/otp/pull/4719, however I'm not exactly sure how to help with this short-term. We...

I just had an idea - what if we called `IO.iodata_to_binary(:io_lib:fwrite_g(num))` to convert early those parts - perhaps we won't accumulate as much extra memory in this case, if the...

`{0:0}` is not valid JSON, it has to be `{"0":0}`. Keys are only allowed to be strings

FWIW in erlfmt we support supressing the formatting for an entire form with a preceding [`%% @erlfmt-ignore` comment](https://github.com/WhatsApp/erlfmt#ignoring-formatting). Doing it per-form is significantly simpler than supporting arbitrary ranges - in...

Yes, the tendency to format code in a narrow column far to the right is a major issue of the algorithm used in `prettypr`. I don't think it can be...

Would this optimise something like the following (which is how I'd decode varints or Unsigned LEB128 - common in many compact networking protocols): ```erlang varint() -> continue(Rest, Len); varint() ->...

This looks great! Thank you for explaining. It's a shame the two sub-byte reads are separated - I assume always reading full bytes is more efficient. In this case in...

@fisher then you'd be happy that this proposal does not make this work, moreover it would make this fail at compile-time, rather than runtime as it does today. The compiler...

I looked into what could be the best way to do this and I'm not really sure. Right now, it seems, the order is handled by each formatter separately. Should...