Feature request: `colorcolumn` supporting multiple values (only in `settings.json`)

[aureliojargas]

Having multiple highlighted columns is useful in some cases.

For example, Git commit messages usual practice: first line 50 columns, body text 72 columns.

    "ft:git-commit": {
        "colorcolumn": [50, 72]
    },

In Python, the black formatter defaults to 88 columns for code, but for the docstrings and comments, our team prefers breaking them at 80 columns.

    "ft:python": {
        "colorcolumn": [80, 88]
    },

In general, 80 columns is what I like to have, for any other file type.

    "colorcolumn": 80

This is a similar request to the rejected #2694, but my proposal here would be simpler: no new/renamed commands, no user-noticeable changes on the use of set colorcolumn.

We could keep the interactive use as it is, aiming for the simple/common case: set colorcolumn <integer> to set it to a specific column, or zero to turn it off. No changes here.

But, if the user has manually changed the settings.json file and set the value to a list of numbers, those will be respected.

If this makes more sense, maybe it could be valid only for scoped settings (ft: and glob), since those are already not changed by the interactive set command.

Would that be acceptable?

[dmaluka]

Just came across this feature request. I think it would be a fine feature. Although I think the value of colorcolumn should be not an array of numbers but a simple comma-separated string of numbers, for compatibility and user convenience reasons.

    "colorcolumn": "50,72"

This is not a high priority for us right now, but this should be easy to implement, so maybe let's add it to the v2.0.14 milestone right away.

[dmaluka]

Although I think the value of colorcolumn should be not an array of numbers but a simple comma-separated string of numbers, for compatibility and user convenience reasons.

Hmm, actually even that would not be backwards compatible, since currently the value of colorcolumn in settings.json is a number, not a string, and currently micro requires any standard option's value to have the same type all the time, it doesn't provide "dynamic typing" for that. So it's not so easy.