Merge apheleia and/or format-all-the-code and/or reformatter

[raxod502]

trafficstars

Hey @lassik and @purcell, per https://github.com/raxod502/apheleia/issues/31#issuecomment-823406583 I thought I would open a discussion about merging these three packages together, i.e. selecting one to be the basis for development, then adding in the features that are provided by the others, and finally adjusting the remaining ones so that they call into the primary one as a dependency. I'm willing to spend some time on this because it seems like it would be great for the community, regardless of whether it's Apheleia or one of the other two packages that ends up being the basis for the combined package.

Does that sound like a good idea to you? If so, I can make a list of the features provided by the various packages, so that we can decide if it is workable to make a single package that provides all of them.

[lassik]

@raxod502 Thanks for opening the thread!

I'm strongly in favor of merging all these packages, and happy to do what I can to help. Don't let me stand in the way of any progress on that front.

Unfortunately I'm very busy at the moment, so it's hard to find time for technical work on moving this forward.

The best approach from my point of view would be if I grant write access to the format-all repo to someone (or several people) who knows what they're doing. They could then make whatever changes are needed to format-all.

[lassik]

Of note is that format-all has generally favored a KISS approach ("Keep It Simple, Stupid") to problem solving, and has generally been reliable for that reason. In particular:

• Only format code stdin->stdout. Never touch disk files directly. Never use tempfiles.

• Use formatter exit status (zero vs nonzero) as the sole condition of figuring out whether the formatting succeeded or failed. (There are a couple of exceptions to this which we should get rid of.)

• Use only synchronous subprocess communications on the Emacs side.

I've always favored talking to the maintainers of a formatter to add the required features instead of adding hacks to format-all. That improves things for other editor plugins, too.

[lassik]

At some point we should sync our stuff with https://github.com/unibeautify -- there should be a standard configuration syntax for code formatters. UB has an RC file syntax from which we could start.

The standard config syntax is by far the most important problem to solve in this design space.

[raxod502]

Awesome, I'll start working on some documentation about a proposed way to merge the packages, for review by you and the community. Will update here when that is complete.

[lassik]

Thanks, sounds great!

[lassik]

I have a spec for a formatter definition DSL (S-expression-based, but doesn't rely on Emacs) which I designed by converting all the format-all formatters to it. That could be used as the basis for generating formatter definitions for multiple programming languages (or multiple Emacs packages).

The thing is who to contact about this stuff. I've worked with Unibeautify's author but he's busy and probably won't have time to work on a standard in this space (though it's been a while, we could ask again).

[purcell]

Hey guys, I haven't really known how best to contribute to this discussion. For the simple cases (stdin/out, no temp files etc) reformatter works very nicely: it supports more fiddly cases, primarily due to eslint's quirks, but I'm not super keen on them (for similar reasons to @lassik), and when I've tinkered with refactoring for more generality, the code gets messy quickly. I don't really get anyone saying it doesn't work for their use case.

[lassik]

stdin/out, no temp files

IMHO we should insist on that. Everything else is a recipe for problems. There are very few formatters that don't support stdin; we should put some pressure on the holdouts :)

[raxod502]

Here's my write-up: https://nextcloud.intuitiveexplanations.com/s/HxL5CnXKdAqwyPj [note: moved from Google Drive to Nextcloud]

In case the Nextcloud document ever disappears for some reason, I have saved it on an Internet archive site: https://archive.ph/MN2HB

Let me know what you think, @lassik and @purcell.

I have a spec for a formatter definition DSL (S-expression-based, but doesn't rely on Emacs) which I designed by converting all the format-all formatters to it. That could be used as the basis for generating formatter definitions for multiple programming languages (or multiple Emacs packages).

Curious if we could see what that looks like! It might be a good starting point for what I'm proposing in the doc.

[doolio]

Any progress on this effort?

[lassik]

No, unfortunately. It would take me about 2-3 full days to work out the details, and it's hard to find the time.

[doolio]

Of course. I appreciate you taking the time to respond and for maintaining these packages in the first place.