DavHau

In general I'm also not a big fan of the `let`'s being pulled up into the preceeding line. I think the following layout is always preferable: ```nix { something =...

Another argument in favor of the `squashed`/`not indented` layout is, that whenever you refactor code and add a `let..in` statement where there wasn't before, then all the existing code gets...

It would be really nice if this was solved. I think this is a major issue impacting readability. I think, a multi-line `let..in` should always start in a new line...

Sorry my bad. My actual input was different than what I posted. input: ```nix { getSourceSpec = pname: version: sources."${pname}"."${version}" or ( throw "The source spec for ${pname}#${version} is not...

Sure, I can do that, and it isn't really a problem for me. I just think for large code bases it might be better if alejandra did this automatically and...

Maybe alejandra could catch herself while doing this by formatting each file twice and raise an error/warning if the result changes twice. This would make it easier for people to...

I just noticed that this can be prevented by putting parentheses around the expression which should not be split. This example is not modified by alejandra: ```nix (type == "path")...

Thanks for the detailed explanations and experiments. I now understand that alejandra cannot reason about the string context and therefore doesn't know which is the right position for the closing...

> We can have the best of both worlds: enforcing the newlines, which means there is still one single style being allowed Should this be a universal rule, or just...

Currently the way to inject dependencies manually is using the `inject` parameter as seen in the example of the main readme. This is currently injected at evaluation time after translation....