Auto Format - Can

[cerulean barn]

Is there a way to disable the Gleam VsCode extension from automatically formatting newlines? I want all the other features (adjust indents, spaces, labeling types, etc) but I want to it leave my newlines alone. (There's value to consistent formatters. Is there an alternate formatter if there's no easy toggle?)

In the example (from Advent of Code) the top function is clear at a glance: it does something to the text, and then something similar to each line. The bottom function -- arranged by the formatter and no longer balanced across lines -- takes me about 3x longer to read.

[fringe trail]

no, to both questions

[robust valley]

fn parse(text) {
  use line <- list.map(string.split(text, on: "\n"))
  use col <- list.map(string.split(line, on: "  "))
  int.parse(col)
}

the answer is always to add more newlines, not less

[autumn tusk]

bleh use and list.map /j

[foggy barn]

use here is fine imo but i always feel bad when the last thing is just one function call

[robust valley]

I mean if you look at the types I'm pretty sure this won't be the final version anyways ^.^

[charred adder]

[autumn tusk]

i think my preferred format would actually be

fn parse(text) {
  text
  |> string.split("\n")
  |> list.map(fn(line) {
    line
    |> string.split("   ")
    |> list.map(int.parse)
  })
}
```tbh

[robust valley]

fight me use with lists is good

[charred adder]

I'll fight you, when and where? 😂

[robust valley]

fosdem

[fringe trail]

yeah, I think the general idea is that either everything should be on one line or everything should be on separate lines, mixing and matching ends up looking weird

[charred adder]

[autumn tusk]

it's because of the anonymous function - them being on one line has higher precedence than splitting pipe operators from my experience

[charred adder]

Maybe unpopular but

fn parse(text) {
  string.split(text, on: "\n")
  |> list.map(fn(line) {
    string.split(line, on: "   ")
    |> list.map(int.parse)
  })
}

[autumn tusk]

that's fine as well

[robust valley]

[autumn tusk]

i find that equally as readable as mine, i just prefer piping everywhere because it's more consistent on my eyes 🤷‍♀️

not everywhere*

sometimes it doesn't make sense lmao

[charred adder]

I'm just not a huge fan of "variable |> piped call"

We'll ignore the README of glexer for this point

[cerulean barn]

wow this is a powerful one

[robust valley]

HAH I WIN

[autumn tusk]

😭

[robust valley]

💕

[charred adder]

BUT AT WHAT COST 😭

[bleak crescent]

Best

[cerulean barn]

Instead of int.parse I used my super illegal assert_as_int function which either parses correctly or dies. So the type comes out as int.

[charred adder]

I guess I win

[bleak crescent]

You shouldn't hide let assert inside functions, assertions should be at the top level.

[charred adder]

honestly fine for AoC (if this is what you're doing), otherwise not

[robust valley]

tbh that was expected 😂

[bleak crescent]

AoC and stuff, yeah sure.

[autumn tusk]

list.map(int.parse) |> result.values() <3

[proud goblet]

• Beginner: Pipes? 👶
• Intermediate: str |> string.length() |> int.add(5) |> case(... 😭
• Advanced: Pipes? 😐

[foggy barn]

list.try_map ftw

that way you save the extra iterating to collect all the okays

[autumn tusk]

true!

there's so many cool functions that i forget about half of them 😅

[foggy barn]

i find i don't use try_map or try_fold very often but they come in handy whenever im messing with results

[foggy barn]

yep... remembers fondly stressedly to when the stdlib list module had like 8 functions

[autumn tusk]

i've only been here since march 😄

[robust valley]

time to deprecate them all

[autumn tusk]

💀

indeed

just a few deprecations recently

[robust valley]

TIL you can do o+e instead of ambersand file descriptor number

[autumn tusk]

it's nushell

[robust valley]

. 😦

[hybrid cave]

in github actions it says 1k+ lines all about deperecated functions

[bleak crescent]

Can we stop saying this over and over please