All of the other tests already check that the output ends with the expected
output and isn’t exactly equal to it. This is because I don’t have enough
control over (or don’t know enough about) the output Emacs and other packages
generate. In order to prevent false-positives from happening as is happening
with ‘scheme-mode’, I don’t check what’s before the output I expect.
The false-positive that’s happening with ‘scheme-mode’ is an issue that it seems
like ‘geiser’ has started complaining that it can’t find ‘guile’, which is
expected.
In bats, when you print to stdout during a test, if the test fails bats will
show the output that was generated. If everything succeeds it hides the output.
At work I have to work with a lot of files that other people work on as well.
Other people don’t usually have their editor set up to remove all trailing
whitespace, and we’re not allowed to make a change that includes a lot of extra
whitespace changes[1]. So I end up having to revert a lot of whitespace changes
just before submitting. And if I then have to make more changes, for example
because something was pointed out in a code review, I have to do it again.
‘ws-butler’ promises that it will still prevent me from submitting extraneous
whitespace, but will not touch lines that I haven’t changed, so that would
prevent me from having to revert them all the time.
[1]: This is good, having a lot of whitespace changes can distract from or even
completely hide the actual change you’re trying to make.
Apparently in the docker container that’s running the tests, reading from the
command-line makes it a multibyte character (105 776 127 130), but defined in
Emacs it’s a unibyte character (61442). This might have something to do with
UTF-16 vs UTF-8?
