[TW-30] "excessive" colorization escape sequences

[taskwarrior]

steve rader on 2012-11-25T14:41:41Z says:

Example: Omitting ~ 315 bytes to write...

32                     1d 0.00548 Angry birds do bad things

...even it if is 256color is kinda crazy, IMHO.

The problem is that Taskwarrior (2.1.2) is omitting colorization start escape
sequences AND colorization stop escape sequences for every single column AND
every space between every column. Removing them compacts my example above to
~75 bytes (320% savings?!)

I don't really care about the I/O per se, but rather it'd be nice if Vit didn't
need to parse and render all that excess.

Maybe that could/should be fixed someday? Just "dont omit dups" eh.

[taskwarrior]

Migrated metadata:

Created: 2012-11-25T14:41:41Z
Modified: 2015-09-02T23:52:21Z

[taskwarrior]

Paul Beckingham on 2012-11-25T15:26:14Z says:

In principle I agree completely, and have had this task on my list for some time:

Name        Value                                           
ID          85
Description Implement optimized colored string concatenation
Status      Pending
Project     tw220                                           
UUID        af028a44-d09c-4ea3-9ce3-83e315b96c40
Entered     5/1/2011 10:38:17 (1.6 yrs)                     
Urgency     5

Date              Modification                            
7/4/2012 16:47:58 Project changed from 'tw210' to
                  'tw220'.

The inefficiencies are a sore point, particularly when certain (nameless) terminal emulators are measurably slow when handling this. I have been measuring this performance, as seen here:

http://tasktools.org/performance/perf_all.html
http://tasktools.org/performance/perf_list.html

In those charts, the rendering takes the longest, but that includes composition, and word-wrapping thousands of strings is the bulk of it.

Now of course, if it were simple, it would have been done already. One major complication is the support for padding the output, and (at)rc.color.alternate@:

task rc.column.padding=4 rc.indent.report=8 next

What is needed is an optimizer to strip out redundant color codes, or better yet, something that prevents them from being inserted in the first place. If we have two columns of output, we have this:

INDENTPADDING

But with additional color and row alternate color, we end up with this mess:

INDENTDATA
    PADDING
    DATA

Most of the time (but not all of the time) what we want is:

INDENTDATA PADDING DATA

So ... yeah ... it's complicated, but needs to be addressed. Stripping out the color codes is easy

$string =~ s/\033[^m]+m//g

But I suppose you are looking to interpret the codes, which means they are already in a nice compact form, just full of redundancies.

[taskwarrior]

Paul Beckingham on 2012-11-25T15:32:44Z says:

One simple filter would be to spot sequences like this:

ab

and just drop the codes, leaving:

ab

But this is a little misleading because color sequences don't really look like that. They look like this:

ab

So there is significant work involved in determining that

can be stripped. This is further complicated by the separation of attributes, such that (at)inverse@, (at)bold@, (at)bright@, (at)underline@, (at)fg@ and (at)bg@ are all independently mixable.

[taskwarrior]

steve rader on 2012-11-28T19:16:50Z says:

So there is significant work involved in determining that

Oh, sorry. But maybe...

    If the current colorization code == the previous colorization code
        don't print the current code
    else
        print the current code

...qed, I thought, so I brought up the subject.

[taskwarrior]

Paul Beckingham on 2015-09-01T21:46:55Z says:

Too hard.

[taskwarrior]

Tomas Babej on 2015-09-02T07:57:28Z says:

This is on my list. All hope may not be lost as of yet.

[taskwarrior]

Paul Beckingham on 2015-09-02T11:57:15Z says:

If you solve it, great. If you solve it with no more than one string copy, I'll push it. But this is a non-trivial task.

I believe the proper solution involves walking a UTF8 string, using a state machine to track active colors. Good luck.

[taskwarrior]

Tomas Babej on 2015-09-02T17:58:52Z says:

I love finite state machines.

[taskwarrior]

David Patrick on 2015-09-02T23:52:21Z says:

Could this bug be related to this vim-taskwarrior bug? ; blindFS/vim-taskwarrior#114

Task graphic reports used to open beautifully with vim-taskwarrior, using the current theme colors, but sometime this spring, something broke, and it's still broken.

I know that this is not the ideal place to discuss problems that satellite projects are having, but the developers can't seem to work around it. If these esc-char issues are related, I hope they can both get fixed, thanks