Synesthesia uncleanly processing ANSI escape sequences

[AlchemicRaker]

I'm not sure to what extent this is synesthesia's fault necessarily, but when synesthesia pipes into a second synesthesia, the final output is full of broken ANSI escape sequences.

$ tail -f /var/log/nginx/access.log | synesthesia "[0-9]+" | synesthesia -b "[a-z]+"
m202m.m131m.m97m.m247m - - [m21m/Jul/m2014m:m15m:m24m:m14m +m0000m] "GET /x/x/x.aspx? HTTP/m1m.m1m" m200m m59m "http://www.x.com/blog/default.aspx" "Mozilla/m5m.m0m (Windows NT m6m.m1m) AppleWebKit/m537m.m36m (KHTML, like Gecko) Chrome/m36m.m0m.m1985m.m125m Safari/m537m.m36m"

In this example, the coloring from the first synesthesia process is garbled and lost, and the coloring from the second synesthesia process renders properly.

[cromo]

What's happening here is that ANSI escape sequences are mostly made out of printable characters, and this can cause a simple regex - such as [a-z]+ in your example - to modify and break pre-existing escape codes by putting escape codes within them.

In order to make this work, synesthesia would need to remove all existing escape sequences while remembering where they were relative to the plain text, color it, perform the same extraction on the new coloration, and then reconcile any overlaps.

I think the least surprising way to perform sequential colorations is to keep all characters the same color they were before unless a new match changes the color of that character. This includes when a new match winds up in the middle of an old match, meaning that the old color codes must appear after the clear color escape sequence for the new match.