The trailing-whitespaces hook should explain why it is not fixing .md files by default

Hi,

Currently this hook display an error but does not auto-fix Markdown files. Hence a user will repeatedly get the following output

Trim Trailing Whitespace................................................................Failed
hookid: trailing-whitespace

Fixing README.md

The Fixing bit of the message is especially misleading: the hook actually does NOT try to remove extra trailing whitespaces in Markdown files, unless you pass it a --no-markdown-linebreak-ext argument.

Would you agree to improve the message here ?

[dupuy]

Reviewing this issue a bit further, I’m not sure about the possibly bigger problem, which is that the exit status indicates failure in the case that there is any trailing two-space line-break (even though it is not “fixed” unless an additional flag is given - and there is no way to leave it “unfixed” without reporting failure). That really does feel like a bug to me - but my recollection of the code is pretty clear that the exit status is determined separately from the actual fixing code, and handling the trailing two-space line break specially only in files with markdown extensions would be a bit tricky there (which is why I didn’t do that in the first place). There might need to be a more significant refactoring (of at least the exit status handling in the trailing whitespace plugin) to solve that problem cleanly. Before I get into that, I’d like to know if there is a consensus that either

A. “fixing” plugins should (without any special options) fix anything that would cause a failure (so that after staging automatic changes, a second run would not fail - I’m not sure this is strictly true for existing plugins) meaning that failure should only be indicated when changes have been made (output messages might still be present, although much less likely to be read), or

B. if there should be another (mutually exclusive) option that not only preserves the trailing two-space line break but also suppresses the failure in that case (as there is a chance that the trailing whitespace is not intentional or even functional, depending on the markdown dialect and documentation style in use).

I would kind of lean towards B but am not totally convinced that forcing that additional user interaction (choose explicit ‘allow’ or ‘fix’ for trailing two-space line breaks) to prevent recurring failure is really necessary, as leaving the trailing two-space line break without a failure by default is probably going to pass unnoticed and without complaint (even with a non-failure warning about the fact they are not fixed) and has pretty much no functional downside. (I strongly suspect that this issue would never have been opened if the trailing two-space line break had not caused this plugin to report failure and abort the commits.)

[peterhil]

Anyone coming to this issue later on, and wondering what the trailing-whitespace actually fixed on Markdown files should look at the diff after running pre-commit or git commit with diff:

git diff --ws-error-highlight=all

There is a really good SO answer about using these git diff options and configuring them.

I spent a long time wondering why args: ["--markdown-linebreak-ext=md,markdown"] did not seem to have any effect until I realised the Markdown files has both on and two trailing spaces in them and trailing-whitespace fixed those correctly, leaving the two trailing spaces there.