Feature request: Colour feedback for commit summary length indicator

[jknlsn]

Is your feature request related to a problem?

When writing commit messages, the existing length indicator shows a plain number but doesn't make threshold borders obvious. I find myself doing quick math very often to check if I'm getting close to 50 or 72 characters.

Describe the solution you'd like

Add colour to the commit summary length indicator for visual feedback:

• Yellow when past warningLength (default 50)
• Red when past hardLength (default 72)
• Optional current/limit display (e.g. 42/50) via showLimit

The existing gui.commitLength.show remains the main on/off switch. Colours apply by default using the 50/72 thresholds (matching autoWrapWidth's pattern); setting either threshold to 0 disables that colour. The showLimit format is opt-in.

Describe alternatives you've considered

• Hardcoded 50/72 thresholds — simpler, but teams differ on conventions (some use 60/80, some don't care about hard limits at all).
• Custom commands — not applicable here; this is internal UI rendering, not a git operation.

Why this fits lazygit

VISION.md says that lazygit values discoverability ("use visual elements to make things obvious") and simplicity ("use sensible defaults"). This adds a small visual cue without changing commit flow or adding prompts.

I've seen that VISION.md also warns about config proliferation. The three new options (showLimit, warningLength, hardLength) are justified because:

1. The colour change works out of the box with sensible defaults, most users won't touch config.
2. Teams that do differ on conventions can adjust once and forget.
3. Setting thresholds to 0 disables them entirely for users who don't want this.

Open question: defaults

Two reasonable approaches:

1. Colours on by default: warningLength: 50, hardLength: 72. If you're showing the indicator, you probably want the feedback. Matches the convention lazygit already nudges toward with autoWrapWidth: 72.

2. Colours off by default: warningLength: 0, hardLength: 0. More conservative, doesn't change existing behavior for current users who have show: true. Requires explicit opt-in.

I like option 1 better, but either would work in my view. I'm not sure which would be a better fit for the project so would welcome input.

Additional context

I know incoming PRs are closed by default as mentioned in CONTRIBUTING.md, so I'm opening this issue first to check whether this would be considered and discussed before opening a PR.

I'm using this myself in my own fork the last few days and am finding the feature very useful.

Screenshots

Sidebar

Minor side note: the feature request template still encourages opening a PR, but CONTRIBUTING.md says PRs are auto-closed.