CODEWITHSUNDEEP
gitvisual-studio-code
void.pointer
void.pointer

Reputation: 26415

How do I customize the subject line length for COMMIT_EDITMSG in VS Code?

I use VS Code for my core.editor when using Git Bash on Windows. There's an "invisible" 50-character line length limitation when editing COMMIT_EDITMSG. I say limitation, but really all it does is color the text red if you go beyond this limit:

enter image description here

How can I change this "hidden limit" so that the text will turn red at any line length I specify? For example, if I change this limit to 70, it should keep the text white until the 71st character, then turn red.

Here are a few things I've tried. First, I customized the [git-commit] language to set the column limit in VS Code settings.json:

  "[git-commit]": {
    "editor.rulers": [70]
  },

This did not affect the behavior. I also tried explicitly setting some git.* settings. In particular:

  "git.inputValidationLength": 70,
  "git.inputValidationSubjectLength": null

The docs for git.inputValidationSubjectLength state it uses the value of git.inputValidationLength if it is unset, but I did not see this change the behavior, either. I assume it's just for the GUI commit workflow.

I've Googled the heck out of this, I can't seem to find a solution. One may not exist, which is also an acceptable answer. At the end of the day I just don't want text color to change as I'm typing up to the longer line length limit I want.

Upvotes: 6

Views: 3540

Answers (2)

DanielT
DanielT

Reputation: 61

What you can do is update the git-commit.tmLanguage.json at:

/usr/share/code/resources/app/extensions/git-base/syntaxes/git-commit.tmLanguage.json

Change this line to your desired length

enter image description here

After this, you should restart vscode and you will get the desired warning color in the COMMIT_EDITMSG

Upvotes: 0

Phil
Phil

Reputation: 95

I use the 1Dark Raincoat (Bright Variant) theme. It's delightful for nearly every language with which I've used it, but the 50+ character commit subject warning renders in a nearly unreadable color by default. I've dealt with this for years, but recently decided to dive into the problem and solve this annoyance once and for all.

First, to respond to some of what you've tried:

I customized the [git-commit] language to set the column limit in VS Code settings.json:

"[git-commit]": {
  "editor.rulers": [70]
},

As you correctly noted, this does not affect this behavior. This is because the editor.rulers setting only affects the placement of vertical lines within editors, to indicate where that column lies for assistance with manual formatting by the user.

I also tried explicitly setting some git.* settings. In particular:

"git.inputValidationLength": 70,  
"git.inputValidationSubjectLength": null

You are correct that this only affects warnings displayed in the "Source Control" UI view, and so this also does not solve the problem.

I was able to find a solution by adding the following to my settings.json:

// settings.json

"editor.tokenColorCustomizations": {
  "[Your Theme Here]": { // replace with your theme name, surrounded by [ ]
    "textMateRules": [
      {
        "scope": "invalid.deprecated.line-too-long.git-commit",
        "settings": { "foreground": "FOOBAR" } // replace with your desired color's HEX value
      },
      {
        "scope": "invalid.illegal.line-too-long.git-commit",
        "settings": { "foreground": "#FF0000" }
      }
    ]
  }
}

This solution modifies the colors used for two specific tokens exposed by the default (built-in) git-commit language syntax:

  1. invalid.deprecated.line-too-long.git-commit affects the color of a commit subject line between 51 and 72 characters in length (inclusive)
  2. invalid.illegal.line-too-long.git-commit affects the color of a commit subject line that is more than 72 characters in length

As written, this solution scopes the custom token colors to only the theme you specify on the second line of my example JSON. To apply these custom color settings to all themes, use [*] instead. In this particular case I believe it would be safe to do so, because the tokens appear to be highly specific to the git-commit syntax's subject lines, but I have not tested this extensively.

For some further reading:

  1. Understanding Tokenization in syntax highlighting
  2. Using the Scope Inspector to discover the tokens in use in a particular file/location

Upvotes: 5

Related Questions