Re: [pushed] Fix PR tui/21216: TUI line breaks regression

[Pedro Alves <palves@redhat.com>]

Fixing this properly is turning out to be much trickier than
I expected.

The main issue is that the TUI/ncurses updates/refreshes to
the command window are done by drawing only what changed,
using cursor movement.

For example, with a small enough screen, we see:

 (gdb) PASS: gdb.tui/tui-nl-filtered-output.exp: set pagination on
 set height 2000

 (gdb) PASS: gdb.tui/tui-nl-filtered-output.exp: set height 2000
 printf "hello\nworld\n"^[[2A^[[23Dprintf "hello\nworld\n"

 hello                

 world^[[K

 (gdb) FAIL: gdb.tui/tui-nl-filtered-output.exp: correct line breaks

"2A" is move up two lines, "23D" is move left 23 lines, then
print "printf "hello\nworld\n"", then "hello\nworld"
then "K" to clear the line, and finally print the prompt.

I tried to work around it by forcing empty commands in between
commands, to force the screen to clear, but the "smart" refresh makes
the output of that even harder to match.

What you were seeing:

 (gdb) set pagination on^[[17D^[[K


 (gdb) set height 2000^[[15D^[[K


... that's moving the cursor to the start of the line, and then
clearing it, making room for the next command.  I.e., both commands
appeared on the same vertical coordinate on the screen, presumably
because the command window only fitted one line or two.

So in general, we can't just strip escape sequences.  

Maybe we could pull it off by implementing a virtual terminal
that is aware of the escape sequences, understands the cursor
movement, line clearing, etc., something like the
un_ansi_vt procedure here:

 [handling of ANSI terminals using Expect]
 http://wiki.tcl.tk/9673

We'd send the test command to gdb, and feed gdb's output to that
procedure in a loop, which builds an array of lines, and then check
if the rendered command "screen" (an array of lines) had the
command result we wanted.

We'd need to match the virtual terminal's "bounding" with
the command window's size.  Ideally, we'd be able to force
the exact size of command window we want, instead of inheriting
that from the terminal dejagnu is running on.

Or maybe do something different.  Maybe dump the screen using scr_dump
and compare to a dump previously saved.  I'd need to investigate
further.

So while I think it'd be neat to do any of this, it's a lot more work
and investigation than this new test is worth it.  So for now, I'm
going to simply remove it.

Thanks,
Pedro Alves