[Bug testsuite/30451] New: [gdb/testsuite] Implement newline glitch in tuiterm

[Bug testsuite/30451] New: [gdb/testsuite] Implement newline glitch in tuiterm

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

            Bug ID: 30451
           Summary: [gdb/testsuite] Implement newline glitch in tuiterm
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: testsuite
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

An idea suggested here (
https://sourceware.org/pipermail/gdb-patches/2023-May/199478.html ) is to
implement the newline glitch in tuiterm.

I wrote a script:
...
$ cat gen-ansi-xenl.sh
#!/bin/sh

o=ansi
n=ansi-xenl

f=$n.txt
infocmp -1 $o > $f
echo -e "\txenl," >> $f
description="ansi/pc-term compatible with color and newline glitch"

sed -i "s%^$o|%$n|%" $f

sed -i "s%|.*,$%|$description,%" $f

tic $f
...
that generates:
...
$ find ~/.terminfo/ -type f
/home/vries/.terminfo/a/ansi-xenl
...
and allows us to use TERM=ansi-xenl.

I changed this in with_tuiterm:
...
-           setenv TERM ansi
+           setenv TERM ansi-xenl
...
and ran the TUI tests (gdb.tui/*.exp and gdb.python/tui*.exp).

The only fall-out of this was:
...
FAIL: gdb.tui/wrap-line.exp: width-hard-coded: $gdb_width == [expr
$readline_width + 1]
FAIL: gdb.tui/wrap-line.exp: width-auto-detected: $gdb_width == [expr
$readline_width + 1]
...
which is expected, because the test has hardcoded expections about TERM=ansi,
so without xenl, and can trivially be fixed by updating the assert.

Surprisingly, this doesn't seem to be causing problems with any of the other
test-cases (we'd expect problems because we tell curses that tuiterm has the
glitch, but we haven't implemented it yet).

Apparently curses/gdb doesn't care too much about this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/30451] [gdb/testsuite] Implement newline glitch in tuiterm

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
OTOH, if we implement the glitch in tuiterm but keep using TERM=ansi, we might
be able to reproduce some of the problems we see with TERM=ansi on xterm-native
terminal emulators.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/30451] [gdb/testsuite] Implement newline glitch in tuiterm

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Tom de Vries from comment #1)
> OTOH, if we implement the glitch in tuiterm but keep using TERM=ansi, we
> might be able to reproduce some of the problems we see with TERM=ansi on
> xterm-native terminal emulators.

IIUC it seems to me that the glitches must be the result of having
TERM disagree with the capabilities of the actual terminal.  Is that
correct?  If so I think we probably don't want to try to support that.
Instead the idea would be to implement the glitch and whatever else
is needed, and then run the TUI tests with TERM=xterm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/30451] [gdb/testsuite] Implement newline glitch in tuiterm

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
https://sourceware.org/pipermail/gdb-patches/2023-May/199768.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/30451] [gdb/testsuite] Implement newline glitch in tuiterm

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #2)
> (In reply to Tom de Vries from comment #1)
> > OTOH, if we implement the glitch in tuiterm but keep using TERM=ansi, we
> > might be able to reproduce some of the problems we see with TERM=ansi on
> > xterm-native terminal emulators.
> 

I've actually managed that, and was able to write a unit test for the newline
glitch from that.

> IIUC it seems to me that the glitches must be the result of having
> TERM disagree with the capabilities of the actual terminal.  Is that
> correct?

AFAIU, yes.

> If so I think we probably don't want to try to support that.

I may have expressed myself poorly, I just was looking for a way to trigger the
glitch, I was not trying to suggest to have tuiterm be out-of-sync with the
TERM setting.

> Instead the idea would be to implement the glitch and whatever else
> is needed, and then run the TUI tests with TERM=xterm.

I've worked for a bit on TERM=xterm support in tuiterm (which mostly consisted
of recognizing sequences and then ignoring them), but gave up because it looked
like too much work.

In the patch series I've proposed there's a new termcap entry,
TERM=ansi-for-tui, which works for both tuiterm and xterm, which meets my main
goal of being able to use TUI in the same way in tuiterm and xterm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug testsuite/30451] [gdb/testsuite] Implement newline glitch in tuiterm

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30451

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14900
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14900&action=edit
WIP patch adding some TERM=xterm support to tuiterm

(In reply to Tom de Vries from comment #4)
> I've worked for a bit on TERM=xterm support in tuiterm (which mostly
> consisted of recognizing sequences and then ignoring them), but gave up
> because it looked like too much work.

FWIW, WIP patch (part of a series, so doesn't apply cleanly) adding some
TERM=xterm support to tuiterm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.