Formatter truncates and duplicates .items lines with long metadata (>1000 chars)

[MatzeMuc86]

Bug Description

When using editor.formatOnSave: true, the openHAB Alignment Tool (v2.1.6) silently corrupts .items files that contain very long lines (>1000 characters). The formatter truncates lines at approximately 700 characters and merges the remainder with the next line's content, producing duplicate item definitions on a single line.

This is a data-destroying bug – the corrupted file is syntactically invalid and causes openHAB to fail loading the items file entirely.

Symptoms

1. Truncation: Long item lines (~1100 chars) with complex metadata (stateDescription + listWidget + actionOptions) are cut off mid-content
2. Line merging / duplication: The truncated remainder is merged into the following line, producing two item definitions on a single line
3. The resulting file cannot be parsed by openHAB

Reproduction

Environment:

• VS Code (latest)
• openHAB Alignment Tool v2.1.6
• openHAB Extension v1.0.0
• editor.formatOnSave: true in workspace settings
• File association: "*.items": "openhab"

Steps:

1. Create a .items file with item definitions that have long metadata blocks (e.g. stateDescription=""[options="..."] combined with listWidget="oh-label-item"[action="options",actionOptions="..."]), resulting in lines over 1000 characters
2. Save the file (triggers Format on Save)
3. Observe: Long lines are truncated at ~700 chars. The cut-off content is merged into the next line, creating duplicate item definitions on a single line.

Trigger: Lines become long when stateDescription options and listWidget actionOptions both contain the same long comma-separated list (e.g. a list of Sonos favorites repeated in both places).

Root Cause Suspicion

The item parser likely fails to handle lines where the metadata / {...} block itself is very long. The regex or column-based splitting appears to have a length limit or misparses the nested brackets when the metadata exceeds a certain length.

Related

This appears to be a regression or variant of #42 ("Comments at the end of line causes weird duplication of item"), which showed the same symptom (duplication within a line) but was triggered by trailing comments. The underlying parsing issue seems not fully resolved for all edge cases.

Workaround

Disable Format on Save for openHAB files in VS Code settings:

"[openhab]": {
    "editor.formatOnSave": false
}