gleam-lang / gleam

⭐️ A friendly language for building type-safe, scalable systems!
https://gleam.run
Apache License 2.0
18.08k stars 758 forks source link

🎨 Format docs type signatures the same `gleam format` does for user code. #2202

Closed hayleigh-dot-dev closed 1 year ago

hayleigh-dot-dev commented 1 year ago

I find that the way that the documentation generates the type signatures does not match the way code is formatted by gleam format. Beyond being a bit triggering, I find it can hurt readability because of how the docs types get rendered.

Consider this function from nibble/pratt. In the source code it is formatted like so:

pub fn expression(
  one_of first: List(fn(Config(a, tok, ctx)) -> Parser(a, tok, ctx)),
  and_then then: List(Operator(a, tok, ctx)),
  dropping spaces: Parser(Nil, tok, ctx),
) -> Parser(a, tok, ctx)

But in the generated docs it is formatted as...

pub fn expression(one_of first: List(
    fn(Config(a, b, c)) -> Parser(a, b, c),
  ), and_then then: List(Operator(a, b, c)), dropping spaces: Parser(
    Nil,
    b,
    c,
  )) -> Parser(a, b, c)

This is significantly harder to read! It would be great if we just lift the approach taken by gleam format and make sure it is also applied to the docs generator.

lpil commented 1 year ago

This has been annoying me forever but I never get round to it. Lets get this fixed.

Currently the same function is used in the docs and the formatter to format a function head, I think they should be two functions so we can format them differently. This will be even more useful later when we add links to the type definitions