ANSI sequences in completions additionally escaped

[vladimir-kotikov]

When I adding ANSI codes to completions using clink.match_display_filter the output looks broken. Consider an example of running the following code (where color_text is a function that just prepends text with corresponding ANSI code):

local function test()
    clink.match_display_filter = function ()
        return {
            color_text("red", color.RED),
            color_text("green", color.GREEN),
            color_text("blue", color.BLUE)
        }
    end

    return { "red", "green", "blue" }
end

clink.arg.register_parser("test", test)

Expected: completions should be colored
Actual: the result of typing test {TAB} looks broken:

The issue repros in both clean Clink and ConEmu + Clink.

After some investigation it seems that the reason of such behaviour is Readlines fnprint function, which performs an additional escaping of ANSI codes in lines 735-744

Not sure whether this is a bug or a feature (and if feature - what is the use case for it), but it would be great if there was an option to avoid this Readline's behaviour.

[mridgers]

Thanks for the details - made it easy to quickly set up a repro. You are correct that it is because fnprint is expanding unprintable characters instead of passing them through to the terminal. Unfortunately it just looks like Readline doesn't support unprintable characters like ANSI control codes in matches what-so-ever. I'm not sure how best to address that.

[piotr-cz]

I'd love to be able to colorize parser's table output, for example to differentiate between arguments and flags or to indicate importance.

[jods4]

👍
I would love colorized matches to highlight that they come from two different sources, see vladimir-kotikov/clink-completions#74

[chrisant996]

I think really we want it to parse the command line while drawing it, and apply colors while drawing (rather than embedding colors in the command line). That way it also can color recognized flags and arguments even if they were entered manually.

That's what I'm planning to eventually implement in the chrisant996/clink fork, but there's a lot of other work that needs to happen first.