Proposed Improvements for line length handling

[thargy]

I found your plugin after trying to find a solution to this common issue with VSCode. i.e. the lack of an easy way to auto line wrap (50 chars for subject, 72 chars for body).

I see that someone else has raised the problem too - #22

Using your plugin and following settings helps:

	"commit-message-editor.view.rulers": [
        50,
        72
    ],
    "commit-message-editor.view.useMonospaceEditor": true,

However, you still have to manually do a line wrap, and this doesn't work with the forms.

Secondly, you cannot use monospaced or rulers with the forms. Rather than adding that support, what would be nicer would be an option to specify an auto-wrap-line-length [[number]] setting per field, which, if set, would automatically wrap lines over that length for that field. That way the subject field could be set to 50 and the body field to 72. When the 'save' occurs it could format the values appropriately, splitting lines based on the character length.

It would be even better if you had an auto-wrap-subject [[bool]] which did the same but got the length from the git extensions builtin git.inputValidationSubjectLength setting, and a corresponding auto-wrap [[bool]] which did the same but got the length from the git extensions builtin git.inputValidationLength setting (which default to 72 and 52 respectively). These are what generate the warnings when entering messages directly into the commit dialog box in VSCOde.

Further, it would be nice to default commit-message-editor.view.rulers to include these 2 git settings, and set the default for commit-message-editor.view.useMonospaceEditor to true for the text view. That way a user can see when they are exceeding the recommended line lengths.

You may wish to add a auto-git-format setting for the text view, which auto wraps the first line to git.inputValidationSubjectLength, ensures a blank line on line 2 (by adding if necessary) and then wraps subsequent lines to git.inputValidationLength.

Finally, it would be nice to have a use-monospace-font [[bool]] settings for each field.

[bendera]

Hi,

Thank you for your feedback.

That way the subject field could be set to 50 and the body field to 72

It would be a bit problematic because the subject and the body can contain more fields. For example, in the default config, there are three fields in the subject: type, scope, short description. The number of the available characters in a field would depend on the content of other fields. (However, the maxlength property will be added to the fields. There is a PR that waiting for approval. A single-subject field can be configurable with this option.) But in the text view, an auto-wrapper function would be great.

it would be nice to default commit-message-editor.view.rulers to include these 2 git settings

I agree with that.

and set the default for commit-message-editor.view.useMonospaceEditor to true for the text view

In the first iteration of this project, I just wanted a large, comfortable textarea instead of the built-in source control inputbox, which looks like the built-in inputbox but bigger. (Btw. a new pet project was born because of this demand.) The code editor-like textarea was introduced later. That's the reason why the simple inputbox is the default. But I will consider your idea.

[thargy]

But in the text view, an auto-wrapper function would be great.

The proposal I gave:

You may wish to add an auto-git-format setting for the text view, which auto wraps the first line to git.inputValidationSubjectLength, ensures a blank line on line 2 (by adding if necessary) and then wraps subsequent lines to git.inputValidationLength.

Would be applied on save anyway (most logical time to do it otherwise it would be confusing), so it wouldn't matter if your were editing in text or form view. It would be nice to expose it as a check box too on the view (like amend), so it can be turned on and off more easily.

This would be the easiest to implement too, and have the biggest impact. There's quite a demand for the functionality so having it (and posting to the associated VSCode issue would possibly gain your more traction.

[bendera]

How would you handle the subject line if it was longer than the allowed length?

1:

The quick brown fox jum...
<empty line>
...ps over the lazy dog
<empty line>
Body text

2:

The quick brown fox jum...
<empty line>
Body text

3:

The quick brown fox jum
<empty line>
Body text

(Or should it be configurable?)

[thargy]

I'd take the MVP approach and KISS. Remember that whatever you do the text can always still be edited before committing. So, if auto-git-format is set, option 1 is best as it's non-destructive and a 'valid' format.

If a user types a long single line message, not realising that the setting is in, the other formats will lose that message, whereas option 1 will preserve it - and it can be 'undone' easily.

Making it configurable adds complexity without adding much more, (the user can always delete the rest of the line once formatting splits it) and better to get the MVP into the wild first 👍

If you were to add options it might be something akin to auto-git-format-subject-mode with the following options:

• truncate - strip everything after the character limit.
• truncate-ellipsis - if character limit reached, truncate and replace last 3 with ellipsis (don't forget to handle small character limits here!).
• split - splits exactly on the character limit, moving the rest to the next line (or the 3rd line if this a heading and there's an option to enforce a blank line 2).
• split-ellipses - splits, with ellipses before and after split.
• split-ellipsis-before - splits, with ellipsis before split on the first line (so will have to ensure there are sufficient characters, i.e. actually splits at line length - 3).
• split-ellipsis-after - splits, with ellipsis after split.

Also, another option for split-mode

• char - split on nearest character
• word - only split on white-space.
• hyphen - like word but if >3 characters left and word length >5 split word with hyphen. [[default]]

As you can see these support all the options (and more).

For a auto-git-format-subject-mode, the default should be split-ellipses which is how GitHub shows long titles now. For auto-git-format it should be just split.

Finally, you can always add an enforce-blank-line-after-subject boolean, to ensure line 2 is always blank, this is pretty easy, if you do if after splitting, etc., if 2 isn't blank just insert a blank line. The three settings together give you everything you need.

[thargy]

Updated proposal to be a bit cleaner and easier:

I suggest the simplest solution is you just implement the following new settings:

• git.splitFormat - one of none, truncate, truncate-ellipsis, split, split-ellipses, split-ellipsis-before, split-ellipsis-after see above for explanation (note none turns off splitting and is equivalent to missing setting). When set it will split based on the git.inputValidationLength if set; otherwise defaults to 72.
• git.splitFormatSubject - same as above but applies to subject line and respects git.inputValidationSubjectLength if set; otherwise fallback to git.inputValidationLength.
• git.splitFormatMode - one of char, word, hyphen, defaults to hyphen if unset.
• git.splitFormatSubjectMode - one of char, word, hyphen, defaults to hyphen if unset.
• git.ensureBlankLineAfterSubject which default to false and inserts a blank line (if not present) at line 2, after all splitting is complete.

To get the recommended git settings:

Settings	Recommended Value	Default/Unset
git.inputValidationLength	72	...
git.inputValidationSubjectLength	50	...
git.splitFormat	split	none
git.splitFormatMode	hyphen	hyphen
git.splitFormatSubject	split-ellipses	none
git.splitFormatSubjectMode	hyphen	hyphen
git.ensureBlankLineAfterSubject	true	false

When installing the plugin, I would set the settings to the recommended values, and the user can delete them to basically restore existing functionality. This will also improve the discoverability of the settings.

Hope you find that helpful.

[bendera]

Hi,

Thank you for the great explanation!

I'm going to omit the hyphen option from the MVP because it's not trivial to implement.

[thargy]

Hi,

Thank you for the great explanation!

I'm going to omit the hyphen option from the MVP because it's not trivial to implement.

That's a good choice anyway, as it's easy to add in a second release once you stabilise the first implementation. 👍

It's actually not too hard to do, as it relies on the same count back logic as ellipsis. Effectively, you store break points (last whitespace) as you go. When you reach a line limit, you check the format, and if ellipsis you move back 3 chars, you then check the mode, if char you split where you are, if word, you move back to the last whitespace (it you haven't gathered a whitespace, you technically should move forward to the next whitespace as you shouldn't really split a word in preference to preserving length limits - because you shouldn't break long urls etc.). If the mode is hyphen, there are several options, my preference is to first check if you passed a whitespace less than 3 chars away, if so, split there. If not, look ahead by 3 chars, if you find a whitespace, split as per word (this stops hyphens with only 1 char on next line), finally split 1 char from end of line and add hyphen.

I'm rushing the summary, but that's the gist.

[jckw]

Any updates on this? It's a great feature that I've been missing from VSCode for a while! Love the implementation ideas here too.

[bendera]

commit-message-editor-0.20.0-pre.1.zip

Pre-release version to test.

[bendera]

To everyone who follows this thread:

Today I published a new extension dedicated to this issue: https://marketplace.visualstudio.com/items?itemName=adam-bender.commit-message-formatter

The core functionality is a standalone npm package, it will be integrated later into this extension.