Alternative to ws-butler

I was using `ws-butler` to automatic erase traillig whitespaces in Python files. But after an update of a lot of of my packages it doesn't seem to work anymore. I can enable it without error messagges but the whitespaces are still there. That behavior was different in the past. The [rep on GitHub](https://github.com/lewang/ws-butler) seems to be dead. Last commit was 2020. Are you aware of a good and easy alternative?

If you only care about Python code, I would recommend using the Black formatter. It will do more than whitespace trimming but it will keep your formatting consistent. You can search for "python black emacs" in your favorite search engine for more details.

What error message?

Emacs has some built in stuff for this. https://www.gnu.org/software/emacs/manual/html_node/emacs/Useless-Whitespace.html Which you can enable on save: https://stackoverflow.com/questions/14164292/my-emacs-deletes-trailing-white-space-how-can-i-disable-this-behaviour/14164500#14164500

The unique selling point for ws-butler is that it only takes care of lines you've actually touched, keeping the diff w.r.t. the original file in check.

I would argue that a focused 300 line utility doesn't need much maintenance, so a couple years of inactivity doesn't mean dead. How are you configuring it? I am using ws-butler and it's working fine. Have you ruled out your configuration being at fault? Alternatively, there may be a conflict with some other package you have recently added. Sometimes packages don't work well together, or require being loaded in a certain order.

You could try [hlissner's fork](https://github.com/hlissner/ws-butler), maybe for some reason it would work.

Works well here. Just tested it on a python file, and it reliably deletes all new whitespace lines. (And only those.) I have version "20201117" from [melpa](https://melpa.org/#/ws-butler) which points to the last commit of that repo.

both magit and github have an option to ignore whitespace changes, why care?

Many code base owners frown on commits that change a bunch of unrelated lines for whitespace cleanup. This helps keep code reviews focused on the actual change, and usually those options you refer to are not enabled everywhere, so this also reduces merge conflicts.

You could add `delete-trailing-whitespace` to `before-save-hook` on relevant buffers?

at the same time, it improves code quality

Ooh, that's actually pretty nice.

yeah, I have switched to running language formatters. Most languages have one now. Especially at work. No more useless formatting arguments.

The alternative I'm aware of is the older `ws-trim` which you can get from ftp://ftp.lysator.liu.se/pub/emacs/ws-trim.el It's more "eager" than `ws-butler`, but if the latter isn't working for you at all then I expect that's a trade-off you'll be willing to adapt to.

What impact trailing whitespace has on code quality, I decline to argue about. But when you're reviewing hundreds of lines of code in patches, every extraneous line makes it harder and slower. It's respectful of reviewers' time to keep such changes separate from meaningful ones.

I don't want to argue about why trailing whitespaces are bad at the first place (it's pretty obvious and there are lots of discussions on that). My point is if the code style doesn't allow trailing whitespaces, eliminating them improves code quality, period. > But when you're reviewing hundreds of lines of code in patches, every extraneous line makes it harder and slower. Fortunately, I don't review patches, I review diffs, and diff tools are pretty easy to configure to ignore all whitespace changes (in most cases it improves readability anyway).

I strongly not recommend "black". it does a lot more then keeping your code PEP8 consistent. It also destroys some constructs. I tried it. Especially for newbies (which I'm not) I recommand to correct your PEP8 errors by yourself. You learn something that way.

There is no error. It just ignores the whitespaces. It is enabled loaded. No errores.

Code formatters are a trade-off. They bring consistency on projects of all sizes in exchange of an opinionated formatting style that you can't deviate from. I have found this trade-off to be worth it.

The consistency doesn't come from tools like "black" but from humans how force themselfs (!) writing beautiful code. You need a linter before checking in code. This is part of the tool chain. Linters (e.g. flake8) can run in a CI or as part of a unittest. Only PEP8 will be commited. You don't need black for that.

I don't get your point in the first paragraph. Beautiful code has nothing to do with formatting guidelines. I think you are advocating for PEP8 as the definitive formatting guide for Python and to enforce it with a validator instead of a formatter. If it is the case, let's agree to disagree on this one.

PEP8 is not the "definitive formatting guide". It is a minimum consent between a lot of existing "guides".