The recent discovery that the only "official" form for extended colors uses colons as separator (bug 791456), plus the introduction of 4:3 and friends for curly and other underlines (bug 721761) and the possible extension of this pattern to other attributes as well (bug 789597) somewhat ask for a bit of refactoring around SGR parsing.

It's ugly that 4 without parameters and 4:x with parameters are handled elsewhere. They should be handled at the same place, under the outer "case 4" there should be an inner branch based on further parameters (or lack thereof).

In order to do that, probably table.cc shouldn't build up an array containing a mixture of scalars as well as array of scalars; but rather it should be an array of (scalar, array) tuples: the initial number, followed by all its arguments. (Or always an array of arrays.)

E.g. "CSI 1;3;4:3;38:5:100m" currently builds up
  [1, 3, [4, 3], [38, 5, 100]]
which is cumbersome to handle. It should instead build up either
  [(1, []), (3, []), (4, [3]), (38, [5, 100])]
(maybe NULL instead of []), or
  [[1], [3], [4, 3], [38, 5, 100]]

This way only the semicolon format of extended colors, such as 38;5;100m will need special handling or code duplication.

Probably this should only be done for SGR (aka. "character_attributes" in caps-list.hh) and not for other kinds of escape sequences. Probably we'd need a new macro in addition to "%m" that does such parsing.

Alternatively, leave the currently generated data structure, and make the outer switch in seq_character_attributes() switch on (is-it-an-array ? the-array[0] : the-number).

Might be too much work for too little gain at this point, maybe having 4 and 4:x handled at different places is much better for now than the additional complexity this change would bring in.