Good news--I finally see a problem.
At 2022-08-17T13:49:35+0200, Alejandro Colomar wrote:
I made the reproducer smaller, so that it's reasier to investigate. I
produced a one-liner file, and then script(1)ed the reproduction of
the bug (I made the terminal shorter, 80x3, to get less blank lines
In the future, when sending around a typescript that includes
screen-clearing escape sequences, it might be a good idea to capture
timing information. Modern script(1) supports this, or you can use the
classic tool beloved of NetHack players, ttyrec(1).
Attached you'll find the offense line, and the typescript log.
Yes, I see trouble.
Script started on 2022-08-17 13:47:53+02:00 [TERM="xterm-256color" TTY="/dev/pts/4"
~/tmp^GESC[01;32malx@asus5775ESC[00m:ESC[01;34m~/tmpESC[00m$ less -R
syscall(SYS_membarrier, int ESC[4mESC[22mcmdESC[24mESC[1m, unsigned int
Okay, that looks like a riot of noise, but the important thing is that
we can see around "cmd" pair of CSI escape sequences, 22 m and 24 m.
As discussed earlier in the thread, "22" restores the "intensity" to
"normal" (i.e., in this case, turns bold off) and "24" turns off
underlining. A CSI 1 m sequence, which turns bold back on, follows.
This is you doing your search.
ESC[1mint syscall(SYS_membarrier, int
ESC[4mESC[22mESC[7mcmdESC[27mESC[1m, unsigned int
This is the same line from the document, with the match now highlighted.
We see that after CSI 22 m, the pager has interpolated a CSI 7 m
sequence before the match and a CSI 27 m afterward. This makes sense;
again as discussed before, these are "inverse" and "positive"
But where's the CSI 24 m sequence we originally had?
This is the bug.