Nim's autoformatter situation

** only works in BASH if globstar is enabled: $ shopt -s globstar Run It seems to work in fish shell by default.

Nim's autoformatter situation

[nimfmt](https://github.com/FedericoCeratto/nimfmt) is based on nimpretty and add a couple of features. The most important one is detecting is the same variable or proc appears with inconsistent style (myVar, my_var, myvar) and optionally fix it. It can be configured to prefer a specify style

Nim's autoformatter situation

Sorry. A double negative with a great deal of textual distance. "No that..." is meant to also apply to "cannot be". Not exactly wrong, but also not very clear.

Nim's autoformatter situation

> @moigagoo's **/** expressions cannot be saved in a file. I don't get it. Yes they can.

Nim's autoformatter situation

I believe Zsh pioneered `**` back in the mid 1990s but it was a long time before you could say `**.nim` instead of `**/*.nim`. (Then it was a very short time to grow triple-`*` to chase symlinks.) It surprised me _how much_ more I liked double-`*` vs `**/*`. `**` _feels_ much more than twice

Nim's autoformatter situation

Ah yes, so the answer to “what's wrong” is “Windows”.

Nim's autoformatter situation

Not sure if it's helpful, but on Windows you have PowerShell which allows for all sorts of cool things: $ ls -R tests *.nim | %{nimpretty $_} Run or, if you prefer the `**` syntax: $ ls tests/**/**.nim | %{nimpretty $_} Run You can

Nim's autoformatter situation

> Anything wrong with `nimpretty **.nim`? Yes, it simply does not work: > nimpretty **.nim Error: cannot open file: C:\p\steamworks\tests\**.nim Run I think `**` its a shell expansion which windows does not have.

Nim's autoformatter situation

You just need a good default. Nothing thrown back at the programmer, only options given.

Nim's autoformatter situation

> pretty the whole dir tree at once recursively, so you can just type > morepretty in the root to pretty the whole project. Anything wrong with `nimpretty **.nim`? > alphabetizes imports Might be troublesome if the imports have side effects.

Nim's autoformatter situation

I think nimpretty is fine. But I have made small improvements as `morepretty` ( ) that basically a runner for `nimpretty` \+ extra: * pretty the whole dir tree at once recursively, so you can just type `morepretty` in the root to pretty the whole

Nim's autoformatter situation

There's a simple algorithm that works well for identifiers of all lengths, and works similar to how humans reason about the problem, and therefore gives results humans generally like - it works like this: * every "expression" is converted into a single "virtual" line (for example, a function

Nim's autoformatter situation

> Preferences would make everyone happy :) preferences make everyone unhappy - you add preferences when you don't have a good, natural solution, and instead dump the problem on the poor programmer who then has to argue with the rest of the internet.

Nim's autoformatter situation

The idea of rendering the AST back seems to work well for other languages, so I'm not sure why it wouldn't work for Nim. Maybe some hacky macros that abuse Nim's syntax would look ugly, but I'd say that's worth it.

Nim's autoformatter situation

I definitely won't be working on this any time soon, but if somebody is interested in creating a Black for Nim I would encourage them. The challenge of actually implementing it may seem easier than it actually is though, this is a good article I read a while back about the subject:

Nim's autoformatter situation

Preferences would make everyone happy :)

Nim's autoformatter situation

Before we had nimpretty, we had tools based on rendering the AST back. They were terrible IMHO, but feel free to write such a tool or use one based on this idea. But don't expect good results -- it's the wrong idea.

Nim's autoformatter situation

> Nimpretty doesn't do that by design, it assumes that if you took the effort > to type in newlines, it's because they are meaningful to you and that you > want it this way. The problem with this is that you will end up with inconsistent formatting. I do also wish for a Black for Nim. As a

Nim's autoformatter situation

I like to reason about code independently of its textual representation. So for me, it's more important that there's a kind of “canonical” formatting for every AST. It allows for the following properties: * If you do multiple changes to your code, it will always look the same no matter what

Nim's autoformatter situation

Myself I want this style of formatting: logMessage(myLogFile, error, "This is a test log message) Run If the lines go too long (over 80 chars): logMessage( myLogFile, error, "This is a test log

Nim's autoformatter situation

My nimpretty does reformat `foofoofoofoofoofoofoofoofoofoo(barbarbarbarbarbarbarbarbarbar, bazbazbazbazbazbazbazbazbazbaz, asdfklasjdfasdfsadff)` just fine. And your shorter example with `--maxlineLen:60`.

Nim's autoformatter situation

For example, consider this code: foofoofoofoofoofoofoofoofoofoo(barbarbarbarbarbarbarbarbarbar, bazbazbazbazbazbazbazbazbazbaz) Run Black will automatically change it to: foofoofoofoofoofoofoofoofoofoo( barbarbarbarbarbarbarbarbarbar,

Nim's autoformatter situation

So what feature do you miss in nimpretty? I simply don't understand what is there to "format" in an indentation based language.

Nim's autoformatter situation

nimpretty and nimfmt really don't match up to the level of actual usefulness as Black at all, really. I just don't think there is anything that matches other language's toolings, but I think that nim will be focusing more on this in the future, and nimskull does have a better nimpretty as one

Nim's autoformatter situation

See

Nim's autoformatter situation

I really like “opinionated” code formatters like [Black](https://forum.nim-lang.org/! python black), [Prettier](https://prettier.io/) or [StyLua](https://github.com/JohnnyMorganz/StyLua). They make it very easy to get code formatted in a consistent and readable way without having to bikeshed