[palette-] prevent interpretation of markup in go-col-name

[midichef]

The palette choosers for & + and gc have some minor display inconsistencies with the way longnames are displayed in exec-longname. The first two commits in this PR fix those inconsistencies.

The third commit fixes a bug in gc where a column name had markup interpreted, so 'Customer[:5]' was shown as Customer, and cell contents had markup interpreted, so a cell of [:bold]asdf[/] was drawn as asdf in bold. However, to properly display the column name as a literal with no markup, I had to turn off the bolding of the column name that was just added in the first commit (40d4243).

[midichef]

Hmm. Turning off formatting in go-col-name was a bad idea. Now it fails to interpret the coloring of the match. So for a colname like Customer. When I type C I see: [:match]C[/]ustomer. So we have to trade off between: coloring matches, vs. correctness for column names that contain pseudomarkup like [:text].

What would be a good way to escape visidata markup?

[midichef]

Perhaps we can escape vd markup by wrapping every open bracket [ between some no-op markup that has no color bound to it, like: [:literal] and [:]. I think it should work, judging by the working of iterchunks() and internal_markup_re. But the idea needs to be double-checked for validity, in case I have missed any important case.

def escape_vdcode(s:str) -> str:
    return re.sub(r'\[', '[:literal][[:]', s)

def unescape_vdcode(s:str) -> str:
    return re.sub(r'\[:literal\]\[\[:\]', '[', s)

If this works, I would discard the changes in f19d7ba and change go-col-name to escape the colname and the cell contents.

[saulpw]

Oof, that escape might work, but it feels like it's overmuch for the task at hand.

What if we injected non-displaying ASCII (or unicode) characters to mark the start/end of literal text? Like this from
https://en.wikipedia.org/wiki/Unicode_control_characters:

Three formatting characters provide support for interlinear annotation (U+FFF9 INTERLINEAR ANNOTATION ANCHOR, U+FFFA INTERLINEAR ANNOTATION SEPARATOR, U+FFFB INTERLINEAR ANNOTATION TERMINATOR). This may be used for providing notes that would typically be displayed between the lines of other text.

This 'literal' usage would be the exact opposite of its intent, but otherwise these characters seem to have the right vibe. Otherwise we could coopt some underused ASCII control characters like 14/15 (Shift Out/Shift In). What do you think about this approach?

[midichef]

Sure, using the Unicode interlinear annotation characters seems like a good solution. The resulting escaped strings will be shorter.

However, since it requires changing internal_markup_re, as well as wraptext() and clipstr_middle() that make use of that regex. So I'll put together a set of changes. For the wraptext() change in particular, I may wait till #2991 is merged, to avoid a conflict.