I remember seeing a Github bot a couple weeks ago that strips out whitespace and adds a .gitignore file to a repo (I also remember this really rubbing some people the wrong way). This search indicates that it would probably be useful to have a linter bot running on Github for all the popular languages. It would find syntax errors, common mispellings, and compilation issues, and then submit pull requests to fix the issues.
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.
Hey, some of us actually use trailing whitespace! :-)
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.
If you create a JS macro that is triggered on file open, with the contents "komodo.view.scimoz.indentationGuides = komodo.view.scimoz.SC_IV_LOOKBOTH", it should give you the indentation guides without the whitespace actually there. http://www.scintilla.org/ScintillaDoc.html#SCI_SETINDENTATIO... has some explanation of the possible values.
Is there any equivalent of the robots.txt standard for public code repositories? Being able to opt-in to certain bots might be helpful (opt-out being the default, of course).
Ah, aggressive trailing whitespace removal. That I can completely get behind. I've already got command-s bound to a custom macro that strips trailing whitespace in TextMate for myself and my co-workers; but this would be an even more inclusive solution.
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.
If you use Vim from the terminal to edit text (which I do), trailing whitespace shows up as big white blocks. It's slightly visually distracting, but it's really just an OCD thing.
Perhaps it would be more productive to advocate the use of local pre-commit hooks. Git makes it very easy to configure validation locally long before anything gets sent to Github.
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.
I actually just replied with a suggestion that Github should implement some built-in functionality for simple error-checking. I think it's a great idea. It would be really helpful if you got a simple little list of notifications for a commit indicating possible error points.
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.