INDENT_WIDTH is 2 (bikeshed warning)

[dbohdan]

I am trying out lis format, and I see that it hardcodes the indent width to two spaces. It seems better to match either Rust (four spaces) or Go (one tab). Lisette programmers are likely to come from the Go and Rust communities. They will be used to one or both of those conventions and expect them in a crossover language.

[ivov]

Hi there!

Lis draws inspiration from Rust but doesn't seek to replicate it in every way. Indentation in particular comes from Gleam and should (I hope) be easy to adjust to, even if different from Rust and Go.

Converting to a GH discussion in case others would like to have a say.

[stormpat]

Related to this:

I really like formatters that avoid excessive configuration (for example, gofmt). However, one thing that makes code harder to read is enforcing a very small fixed line length. Right now this is hardcoded to 80 characters in crates/format/src/lib.rs.

In practice, this often causes otherwise simple code to become unnecessarily expanded vertically and harder to scan.

Example with the current 80 character limit:

let result = try {
  let rows = pool.Query(
      context.Background(),
      "select foo, bar from some_database_table",
  )?

  let data = pgx.CollectRows<Out>(
      rows,
      |row| pgx.RowToStructByName<Out>(row),
  )?

  rows.Close()
  data
}

Compared to a slightly wider limit:

let result = try {
  let rows = pool.Query(context.Background(), "select foo, bar from some_database_table")?
  let data = pgx.CollectRows<Out>(rows, |row| pgx.RowToStructByName<Out>(row))?
  rows.Close()
  data
}

The second example is still reasonably sized (the longest line is only ~95 characters), but is much easier to read because the logical flow is preserved without excessive wrapping.

I think it would make sense to either:

increase the hardcoded limit to something like 120 characters, or
allow configuring the line length in lisette.toml while keeping a sensible default.

For what it’s worth, Go’s go fmt does not enforce a line length limit at all (it doesn’t wrap lines), while rustfmt allows the line length to be configured.

[ivov]

Good feedback, thank you!

I'd prefer to keep the formatting canonical (non-configurable, non-steerable via trailing commas) but I'm open to revising the width upwards. Lisette often spends width budget fast because of qualified names and function signatures with generics and bounds. Ideally I'd love to calculate line width percentiles (p50, p75, p90, p99) across various Lis projects in the wild (in time, as users create them) to have a better sense of whether 80 is too tight.

[rsyring]

FWIW, our projects (mostly Python) have all standardized on 100 chars for the width and that's been working well for a decade or more.

Ironically, I find the width constrained version in the example above easier to read. But that's how it goes.

I do think the less configuration knobs the better to avoid bike-shedding. You could look at the Black project which started out trying to have very hard no-configuration rules but they gave on some eventually. Things like line length and single/double quotes come to top of mind. If lisette becomes popular you may find it's simpler to provide a small number of select knobs than to keep fending off people who want you to do it differently. :)

[enquora]

I am currently porting the Cappuccino Project toolchain to Golang and Lisette. Our house style is Allman - no other formatting is accepted,but this is enforced manually at the moment.

With respect to line length, objj and objc roll up their sleeves and say "hold my beer" to almost every other language.
The proper formatting places [message receiver:] pairs on individual lines when a single 80 column line is insufficient, but even Xcode regularly fails at respectable formatting.

A new formatter will enforce Allman style but allow unrestricted line length - until such time as the typographic subtleties of semantic line breaking can be automated reliably. I have non-trivial experience with typesetting and publishing but consider this the least important concern.

My own choice would be to enforce the author's house style via lis format but to allow unrestricted line lengths until pressing and important language work has been completed. If line length is indeed a problem at all. That I can work in Lisette without even thinking about K & R formatting (which is alien to myself) suggests adapting to any house style is a non-issue. Everyone is using editors which support EditorConfig, correct?