FR: Configurable wrapping column for git commit messages, default 72

[rmunn]

• VSCode Version: 1.10.2
• OS Version: Linux Mint 18 (based on Ubuntu Xenial 16.04.2)

I'm asking for #2718 to be reopened, or for further discussion on the feature to be had in this issue. #2718 was closed because wrapping arbitrary-language text is really difficult (e.g., Thai has no spaces between words, and there is no algorithmic way to correctly break lines in between words; you have to have a Thai dictionary built into your program if you want correct linebreaks in Thai). However, there are two factors that make this an unimportant consideration for Git commit messages:

1. Any programming team that has more than one native language among the programmers in the team has probably already standardized on a single language, and that language is almost always English where spaces between words are normal.

2. There are very good reasons for NOT splitting lines in commit messages if those lines do not contain spaces, because those lines are probably URLs.

So the rule for Git commit message word wrapping should be very simple:

1. First line warns if it's more than 50 columns. (This is the current behavior).
2. Second line warns if it isn't blank.
3. Rest of the commit wraps on spaces (or on any whitespace, but I recommend sticking with plain 0x20 space characters only for simplicity) at a user-configurable column, defaulting to 72 since that's the current standard recommended by Git.
4. Any line in the commit that does NOT contain spaces does not wrap, but a warning pops up (similar to the warning if the first line is > 50 columns) saying "Your commit message contains # long line(s) which could not be wrapped because they do not contain spaces. If these lines are URLs, that's probably okay, but otherwise you should consider adding spaces so that the lines can be wrapped. Your settings are currently set to wrap any lines longer than 72 characters in your commit message." (With #, of course, being substituted for the actual number of too-long lines in the message.)
5. That warning can be disabled in the user or workspace config settings, for the sake of any teams who have standardized on languages like Thai which do not use spaces in the language. The word-wrapping behavior can also be completely disabled if the user so desires, but it starts configured to be ON.
6. (Optional). If the long line starts with the regex [a-zA-Z][-a-zA-Z+.]+: (see RFC 3986), it is assumed to be a URL and no warning is issued for that line, since it's usually not desirable to split a URL across two or more lines.

This would go a long way towards making VS Code's Git message editor usable. As of right now, I avoid using VS Code's Git integration because it doesn't format Git messages correctly according to the coding standards of just about every project I've worked on. So despite the fact that VS Code has pretty good Git integration for most things, I still just Alt-Tab to a terminal and write my Git commits in Vim, where I can set it up to do the right thing for commit messages (wrap at 72 columns, or at 70 for one project I work on that has slightly stricter rules than most).

P.S. Also, as a side effect, I'd like to ask that the Git commit window NOT visually wrap lines that aren't truly wrapped (e.g., the only thing that causes text to go to the next line in the commit window is a real linefeed or CR/LF in the commit message). Instead, if the text goes past the end of the available window size, give us a horizontal scrollbar, which will serve as a cue to resize the Git sidebar to be large enough to fit 72 characters horizontally. And perhaps also there could a button that will automatically resize the Git sidebar to fit the text already in the commit message -- though that's a more "bells and whistles" feature, rather than core functionality.

[joaomoreno]

You could simply have answered in #2718

[rmunn]

I wasn't sure if closed issues still notified anyone, and it seemed somehow rude to post in a closed issue when I was basically proposing something different (the OP in #2718 said he wasn't proposing changing the appearance of the text in the commit message, whereas I AM proposing that.)