I have no time to work on something like this myself, but I'm sure a lot of people would find it useful, especially if it acted as a "first defense" before deployment. Curious what other HN'ers think about this.
I have no time to work on something like this myself, but I'm sure a lot of people would find it useful, especially if it acted as a "first defense" before deployment. Curious what other HN'ers think about this.
https://github.com/Miserlou/WhitespaceBot
Feel free to fork it to do whatever you want, that's why I made it.
Absence or presence of trailing whitespaces is sometime significant, such as in big ereg in re.VERBOSE mode in Python.
Therefore, it must be visible, and if it is visible it must be removed when it has no use.
" Remove any trailing whitespace that is in the file
autocmd BufRead,BufWrite * if ! &bin | silent! %s/\s\+$//ge | endif
which has some advantages (described in the README)
This plugin is better than using the builtin vim 'list' command because it
doesn't show an annoying highlight while you are typing in insert mode at the
end of a line. set list
set listchars=trail:•
In other people's code, use `set nolist` to prevent hyperventilation.In general, explore `help list`.
I use it to create useful indentation guides in Komodo. If the whitespace is stripped away, the indentation guides have gaps where there's a blank line in an indented block.
Maybe Komodo could use a different method to decide where to draw the lines that didn't depend on trailing whitespace. It looks like Sublime Text 2 has a different approach for its indentation guides - maybe the Komodo guys should look at that. But in the meantime I'm using Komodo as it actually works today, so the whitespace on blank lines is important. Let me keep it, please? :-)
I wouldn't mind stripping out trailing whitespace on nonblank lines - that wouldn't affect my precious indentation guides.
But wait a minute, what about Markdown? Two spaces at the end of a line to get a <br>, right? Does the bot skip Markdown files?
Finally, for the folks who have automatic whitespace removal in their editor settings... Please be careful: With this setting, you'll be very likely to make a commit that includes both significant code changes and a mass of whitespace changes in the came commit.
Those kinds of changes should be separated: one commit for the code itself, and a separate commit for the whitespace with a comment like "Whitespace cleanup, no code changes."
This allows people who diff the revision history to diff with whitespace significant most of the time, the only exception being when reviewing a whitespace-only change.
(Edited for friendlier tone...)
banned = ['.git', '.py', '.yaml', '.patch', '.hs', '.occ', '.md', '.markdown', '.mdown']so, thanks, but I'll keep my whitespace.
Would be nice if Github provided better documentation and a selection of validation templates to include in new projects. This would better leverage the power of Git and its distributed nature than a bot running on Github.
For some reference material check out:
http://book.git-scm.com/5_git_hooks.html
http://progit.org/book/ch7-3.html
And a couple simple examples: http://mark-story.com/posts/view/using-git-commit-hooks-to-prevent-stupid-mistakes
https://github.com/ReekenX/git-php-syntax-checker