Show rulers in commit message textbox for max lengths

[CombeeMike]

Usability issue

When writing commit messages I'm missing the following information (at 1 glance):

• How much more can I write in the current line?
  This is kind of available by the "x characters left message" but I find it easier to recognize a line which is "coming closer" than a decreasing written number.

• Do all lines of a multi line commit meet the desired max line length?
  I can already move the cursor through all lines and wait for the "validator" to turn orange or stay green but I find that very laborious mainly for 2 reasons:

  • There's no way to tell at one glance if the whole message is valid.
  • When moving the cursor 1 line up or down, I always have to wait for the "validator update" and if it doesn't change I'm always left with the feeling of "did it maybe not update correctly"?

Solution/Request

• Monospaced font in the commit message textbox (by now possible with setting scm.inputFontFamily)
• The textbox should not "auto-wrap" but show a horizontal scrollbar if needed
• 2 rulers at the values from settings Input Validation Length & Input Validation Subject Length

I see that this is at least related to #2718 but created a dedicated request since I'm not looking for any "auto correction" but only a better visual guidance.

[CombeeMike]

I also just noticed that the textbox performs a "auto wrap" which is quite troublesome to me since this wrap is no real line separator but only a "visual wrap" which in turn makes it even harder to realize how long the line really is...

I've therefore added a 3rd point to my "solution" above...

[KUGA2]

I 100% agree.

Auto wrapping is bad if the author did an 80 char alignment. This turns this (which is wrong but not terrible)

word word word word word word word word word word word word word word 72word w80
word word word word word word word word word word word word word word 72word w80
word word word word word word word word word word word word word word 72word w80

into this which reads very bad:

word word word word word word word word word word word word word word 72
word w80
word word word word word word word word word word word word word word 72
word w80
word word word word word word word word word word word word word word 72
word w80

I additionally propose to enforce these rules:

1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how

From here: https://chris.beams.io/posts/git-commit/
(Sorry, did not want to hijack your request)

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[ChadBailey]

Just want to add a +1. I came here with the explicit intent of creating a feature request just like this. Glad I'm not the only one who desires it.

I will say that finding this was very challenging, I nearly filed a bug report of my own simply because it's difficult to express in words what it was I was after. Searching bugs specifically for "git ruler" is what found it. I suspect there would be much more support for this feature with higher visibility/easier discoverability.

[KUGA2]

@ChadBailey What did you search for first? Adding this "keywords" might help others find this :)

[ChadBailey]

That's a valid suggestion, however, I think the problem mostly existed in my head lol. I didn't actually try a whole lot of search terms, but went through lots of combinations in my head before deciding on searching open issues for "git ruler" since i figured those were the two most unique terms to this problem.

That said, I looked up my initial search (on Bing) which was vscode git commit reason ruler . This resulted in so many unrelated results I was sure that further searches would be futile lol.

[shoffmeister]

Some projects (rightfully so) insist on nicely formatted commit messages - i.e. wrapped in a useful fashion.

Currently it is nigh impossible to create such a message inside the vscode commit message box because a variable width font, instead of a monospace font is used. This then results in the following mess.

[will-stone]

Hi @shoffmeister I think this can be changed using scm.inputFontFamily.

[shoffmeister]

Dang. Learn something new every day:

And with that setting turned on, the first item of the requested set of features from above, "Monospaced font in the commit message textbox" has been addressed.

Which "only" leaves no-wrap (horizontal scrollbars), rulers. For me, to be honest monospace is good enough.

[will-stone]

Glad I could help 😄 I have that turned on but I'd love a ruler too.

[antekone]

Having the ruler would of course be helpful, but it's also possible to invoke the "Git commit" action from Ctrl+P action palette, and it will be possible to write a normal Git commit message using normal editor, which has all the needed rulers visible.

[sanmai-NL]

Switch to the editor from the text field. See https://www.youtube.com/watch?v=xGZ7OJYVFuY

And have these settings:

  "[git-commit]": {
    "editor.rulers": [
      72,
      50
    ],
    "editor.wordWrap": "wordWrapColumn",
    "editor.wordWrapColumn": 72
  }

[lszomoru]

Thanks @sanmai-NL, for bringing it all together in your comment. At the moment we have no plans on adding rules to the commit input field in the "Source Control" view, but as pointed out in the previous comment, the full editor can be used for authoring a commit message as well, where rules/wrapping can be configured.

[CombeeMike]

@lszomoru This is very disappointing to hear. Whilst the full editor is a viable option for some situation it's not really suitable as a "daily driver" for me, mostly for the following reasons:

I tend to write commit messages not only right before committing but oftentimes already during coding, so this is kind of a living document for me. When doing this with the full editor I'd have to always keep the tab open to not lose its state which would needlessly clutter my editor area.

Also, in the commit input field I can navigate between recent commit msgs using up/down arrow keys (even without losing a "draft") which is something I use rather often and doesn't work in the full editor as far as I know.

However, thanks for the update. It is always good to know what can be hoped for and what not!

[CombeeMike]

FYI, I just created a new feature request which is only about an option to turn off auto wrap for the textbox:
#200884

Maybe less implementation effort & therefore something you'd consider instead of this.

[lszomoru]

With the latest version of VS Code Insiders you can use language specific editor configuration to specify rulers and disable word wrapping. Rules only really make sense if you are using scm.inputFontFamily to specify a monospace font.

  "[scminput]": {
    "editor.rulers": [
      50,
      72
    ],
    "editor.wordWrap": "off"
  }