ANSI escape sequence ^[[K processed by less -R but not most

Question

I'm writing a wrapper around ack to search for code locally with some additional lines of context piped to a pager.

Here's the wrapper script ackc. Between the different examples, I'll be varying what gets passed to ack as the --pager.

#!/bin/sh

ack -C 20 -i \
    --pager=most \
    --heading \
    --break \
    --color \
    --show-types \
    "$@"

With less (without the -R) as the pager, almost all of the escape sequences are rendered using the caret notation (don't know what that's called. ^[ is the exception. It is rendered as ESC with inverted background colors (colors not reproduced here).

Here's a sample of the output (produced by ackc with --pager=less and environment variables such as LESS, LESSPIPE etc cleared)

ESC[1;32m.local/lib/python2.7/site-packages/markupsafe/_speedups.cESC[0m
...
ESC[1;33m19ESC[0m:#define PY_SSIZE_T_MAX ESC[30;43mINTESC[0m_MAXESC[0mESC[K
ESC[1;33m20ESC[0m:#define PY_SSIZE_T_MIN ESC[30;43mINTESC[0m_MINESC[0mESC[K

The important escape sequence here is the ^[[K sequence at the end of each line containing a highlighted item. It is handled appropriately by less -R.

.local/lib/python2.7/site-packages/markupsafe/_speedups.c
...
19:#define PY_SSIZE_T_MAX INT_MAX
20:#define PY_SSIZE_T_MIN INT_MIN

most, however, does not seem to handle it very well.

.local/lib/python2.7/site-packages/markupsafe/_speedups.c
1-/**
...
19:#define PY_SSIZE_T_MAX INT_MAX^[[K
20:#define PY_SSIZE_T_MIN INT_MIN^[[K

It passes through the ^[[K sequence as-is.

This sequence is CSI (n) K -- EL -- Erase in Line. When given no argument, it erases to the end of the line. Presumably this is needed to clear stray bits of background color if the matched term appears at the end of the line.

Is there a reason why most doesn't understand this sequence? Can I configure it to process it correctly?

Answer 1

most's behavior is hard-coded. The source-code has several chunks like this for parsing after an escape character is received:

     if ((ch == 033) && (Most_V_Opt == 0))
       {
      while ((ch == 033)
         && (0 == most_parse_color_escape (&b, e, NULL))
         && (b < e))
        ch = *b++;
       }

Basically it says if it finds an escape character (033) and the -V option isn't set, then look for ANSI color escape sequences.

All of the clearing operations begin with an escape character as well, so most will not do what's asked.

By the way, I see that Davis made a change a couple of days ago as a workaround. Ultimately that will be in a packaged version...

Author: John E. Davis   2018-07-11 06:26:02
Committer: John E. Davis   2018-07-11 06:26:02
Parent: 97befd7b984520e80475bb1cb857b35650755a15 (pre5.1-20: Added support for Home/End keys)
Branches: master, remotes/origin/master
Follows: 
Precedes: 

    pre5.1-21: Added a work-around for programs that try colorize the output using the clear-to-end-of-line escape sequence (ESC[K) without regard for the value of isatty(fileno(sdout)).

+21. src/line.c: Added a work-around for programs that try colorize the
+    output using the clear-to-end-of-line escape sequence (ESC[K)
+    without regard for the value of isatty(fileno(sdout)).  Most will
+    ignore ESC[K unless invoked with -v.