Allow running multiple formatters in sequence

[r-zip]

First, thank you for this great package.

Unless I'm mistaken, there is currently no way to configure apheleia-mode to run multiple formatters on save. When working with Python files, I often run isort followed by black. It would be nice to automate this workflow using this package. Maybe the apheleia-mode-alist could be changed to, for instance:

((python-mode . (isort black))
 (js-mode . prettier))

and the package would run the list entries sequentially.

[raxod502]

Yeah, I agree, that would be a good feature. I like the proposed interface as well.

[shackra]

I started a fork and read the source code, but I don't really know what I'm doing TBH. I was thinking on approaching this by passing the symbols as a list and looping through, having each ran on the buffer or something along the lines, but I'm not confident to modify any function to implement this feature

[shackra]

I may try again if @raxod502 can orient me with the internals, the documentation in code is not good enough for my little brain, and maybe I'm too dense to figure how we should run each formatter in sequence.

[raxod502]

I think it would be sufficient to update the function apheleia--format-after-save. The tricky thing is that we want to take a flat list of formatters and turn them into nested callbacks since the Apheleia interface is asynchronous. The return value of apheleia--get-formatter-command would become a list of formatters to run, rather than just one. Then we would probably want to take advantage of lexical binding, and in the callback to apheleia-format-buffer, pop off the first formatter to run from that list, mutating it in place, and passing the same callback again recursively, until the list is empty. It's a bit hard to describe in detail without actually writing the code.

[shackra]

It's a bit hard to describe in detail without actually writing the code.

I kind-of follow what you are describing, it sounds a bit complex tho

[codygman]

I just needed this to run the Haskell hlint formatter followed by brittany. I'm not sure if I'll become motivated enough to implement what @raxod502 described or become annoyed enough by still having to run hlint manually...

but I'll let the thought of implementing that bounce around a bit.

Awesome package though. Linting should be automated away and programmers shouldn't have to run commands from a shell to fix it up.

[lassik]

Maybe the apheleia-mode-alist could be changed to, for instance:

((python-mode . (isort black))
 (js-mode . prettier))

and the package would run the list entries sequentially.

Format-all supports running more than one formatter in a chain; please check out how we configure it. If Apheleia uses the same alist format for configuration, people will have an easier time using the two packages.

We choose the formatters based on GitHub linguist language names instead of major modes. The language-id library maps Emacs buffers to language names.

[codygman]

Huh, integrating format-all-the-code and aphelia seems like an interesting idea. I'm guessing that format-all-the-code doesn't use the same RCS patch/dynamic programming algorithm to preserve point? If not, it seems integrating the two would be nice so that format-all-the-code users could get that improvement.

If it does then these packages are simply competing with one another 😄

[lassik]

Yes, and reformatter is a third package :p

As far as I can remember, the maintainers are in agreement that it would be nice to build all of these packages on top of each other somehow, but none of us have had time to delve into it.

[lassik]

The RCS patching is also useful outside of code formatters and a few MELPA packages roll their own. Someone (possibly Steve, reformatter's author?) was looking into how to extract the patching into a self-contained library that could be used by the other packages.

[raxod502]

If you just want to special-case running hlint followed by brittany, you could probably do something like this (untested):

(defun my-apheleia-hlint-and-brittany ()
  (interactive)
  (apheleia-format-buffer
   (alist-get 'hlint apheleia-formatters)
   (lambda ()
     (apheleia-format-buffer
      (alist-get 'brittany apheleia-formatters)
      (lambda ()
        (message "Formatted!"))))))

and then put it on an appropriate hook, possibly with some additional cleanup.

Doing it "properly" is just a matter of automatically generating code like the above from an arbitrary list of formatters.

[mohkale]

@raxod502

I see that for input we're creating a temporary file but I'm not seeing where we're deleting that file. None of the builtin formatters seem to use that option so I'm not sure whether that functionality has been tested but if you make a temp-file shouldn't apheleia delete it when the formatter is finished?

Edit:

For apheleia--run-formatter how should we handle when a we can't format one of the commands in a sequence. Say you want to run formatters 1, 2, 3 but 2 fails. Do we carry on and ignore 2, do we stop and only apply 1 or do we not apply any. The current approach is if the command can't be formatted we don't do anything but I'm not sure that'll work when we have multiple commands.

[mohkale]

Alright I've added a prospective implementation. See #51 for more details.

I've tested and this change should be backwards compatible with the existing implementation. I've tried out using black and isort at the same time and I'd say its working. Please test it out and let me know if you have any issues.

[mohkale]

@lassik

Format-all supports running more than one formatter in a chain

So from the looks of things lassik enumerates the entire configuration and if the same mode appears more than once it reads that as meaning use all of those formatters for the buffer. I'm not sure I'm a big fan of that implementation since my lazy self has a tendency to just push new entries onto configs instead of using setf and properly changing existing ones. Say for example I want to use something other than black in python-mode I'd just push a new entry onto the config, but since the default config already has python-mode associated with black I'd end up running both of them unintentionally. I say if that's the route we go down we should remove the default formatter associations to avoid confusion.