[Bug cli/30346] New: [gdb/cli] CLI in ansi terminal has off-by-one width problem

[Bug cli/30346] New: [gdb/cli] CLI in ansi terminal has off-by-one width problem

[vries at gcc dot gnu.org]

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

            Bug ID: 30346
           Summary: [gdb/cli] CLI in ansi terminal has off-by-one width
                    problem
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: cli
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Previously filed at PR30337 comment 3. ]

Say we have a terminal with:
...
$ echo $COLUMNS
40
...

For contrast, lets start with the terminal in xterm mode, and type 'a' for a
while:
...
$ TERM=xterm gdb -q
         1         2         3         4
1234567890123456789012345678901234567890
(gdb) aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aa
...
All 40 positions in the line are used, before we wrap to the next line.

Now we start gdb with the terminal in ansi mode:
...
$ TERM=ansi gdb -q
         1         2         3         4
1234567890123456789012345678901234567890
(gdb) aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aa
...

The line wraps after 38 chars.

Based on the readline behaviour of hiding one char to deal with the lack of
autowrap, we'd expect wrapping after 39 chars.

The problem is that we start out with COLUMNS=40, then ask readline how wide
the screen is, which replies 39.  Then we use the 39 to set the screensize
using readline, which results in an effective width of 38.

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

[Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem

[vries at gcc dot gnu.org]

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

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

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

[Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f1531d046178fbdd97e3440e3d454683440b75f9

commit f1531d046178fbdd97e3440e3d454683440b75f9
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Apr 21 17:12:23 2023 +0200

    [gdb/cli] Add maint info screen

    While working on PRs tui/30337 and cli/30346 I came across various notions
of
    width in gdb, as reported by gdb, readline, curses and the environment
    variables.

    As for gdb, readline and the environment variables, the way things work
    is:
    - Gdb asks readline to detect screen size,
    - readline sets the actual screen size in the environment variables
      COLUMNS and LINES,
    - readline reports back a screen size to gdb, which may have one column
      less than the actual screen size, to deal with lack of auto-wrap.
      This becomes gdb's notion of screen size (in other words the point where
      we can expect the gdb command line to wrap),
    - Gdb then explicitly sets readline's screen size, which readline itself
may
      adjust to deal with lack of auto-wrap.  This becomes readlines notion
      of screen size (well, internally the unadjusted one, but it'll report
back
      the adjusted one).

    Add a command "maint info screen" that prints these notions, both for width
    and height.

    For TERM=xterm we have:
    ...
    $ TERM=xterm gdb -ex "maint info screen"
    Number of characters gdb thinks are in a line is 118.
    Number of characters readline reports are in a line is 118.
    Number of characters curses thinks are in a line is 118.
    Number of characters environment thinks are in a line is 118 (COLUMNS).
    Number of lines gdb thinks are in a page is 27.
    Number of lines readline reports are in a page is 27.
    Number of lines curses thinks are in a page is 27.
    Number of lines environment thinks are in a page is 27 (LINES).
    ...

    And for TERM=ansi:
    ...
    $ TERM=ansi gdb -ex "maint info screen"
    Number of characters gdb thinks are in a line is 117.
    Number of characters readline reports are in a line is 116.
    Number of characters curses thinks are in a line is 118.
    Number of characters environment thinks are in a line is 118 (COLUMNS).
    Number of lines gdb thinks are in a page is 27.
    Number of lines readline reports are in a page is 27.
    Number of lines curses thinks are in a page is 27.
    Number of lines environment thinks are in a page is 27 (LINES).
    ...

    [ The fact that we have "characters readline reports are in a line is 116"
is
    is due to gdb making readline adjust twice for the lack of auto-wrap, this
is
    PR cli/30346.

    Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
    "maint info screen":
    ...
    Number of characters characters curses thinks are in a line is 110.
    Number of characters environment thinks are in a line is 111 (COLUMNS). ]

    And for TERM=ansi, with width and heigth set to 0:
    ...
    Number of characters gdb thinks are in a line is 4294967295 (unlimited).
    Number of characters readline reports are in a line is 32766 (unlimited -
1).
    Number of characters curses thinks are in a line is 118.
    Number of characters environment thinks are in a line is 118 (COLUMNS).
    Number of lines gdb thinks are in a page is 4294967295 (unlimited).
    Number of lines readline reports are in a page is 32767 (unlimited).
    Number of lines curses thinks are in a page is 27.
    Number of lines environment thinks are in a page is 27 (LINES).
    ...

    [ Note that when doing a resize by say maximizing or de-maximizing a
terminal,
    all reported values are updated, except for curses when not in TUI mode.

    Maybe that means there's a bug.  If not, then maybe we should not print
    the curses lines unless in TUI mode, or annotate those lines such that it's
    clear that the values may be not up-to-date. ]

    I'd like to use this command in the regression test for PR cli/30346.

    Tested on x86_64-linux.

    Reviewed-By: Eli Zaretskii <eliz@gnu.org>
    Reviewed-By: Tom Tromey <tom@tromey.com>

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

[Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4891c459927d9a9c0f516c35e2d9d4ce212dd06e

commit 4891c459927d9a9c0f516c35e2d9d4ce212dd06e
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri May 5 14:34:00 2023 +0200

    [gdb/testsuite] Add gdb.base/wrap-line.exp

    Add a test-case that tests prompt edit wrapping in CLI, both
    for TERM=xterm and TERM=ansi, both with auto-detected and hard-coded width.

    In the TERM=ansi case with auto-detected width we run into PR cli/30346, so
    add a KFAIL for that failure mode.

    Tested on x86_64-linux.

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

[Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f0f6df0a04fe521ff4df9b74981a624fa2583e3a

commit f0f6df0a04fe521ff4df9b74981a624fa2583e3a
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri May 12 11:43:41 2023 +0200

    [gdb/cli] Fix wrapping for TERM=ansi

    I. Auto-detected width (xterm vs. ansi)

    Say we have a terminal with a width of 40 chars:
    ...
    $ echo $COLUMNS
    40
    ...

    With TERM=xterm, we report a width of 40 chars:
    ...
    $ TERM=xterm gdb
    (gdb) show width
    Number of characters gdb thinks are in a line is 40.
    ...

    And with TERM=ansi, a width of 39 chars:
    ...
    $ TERM=ansi gdb
    (gdb) show width
    Number of characters gdb thinks are in a line is 39.
    ...

    Gdb uses readline to auto-detect screen size, and readline decides in the
    TERM=ansi case that the terminal does not have reliable auto-wrap, and
    consequently decides to hide the last terminal column from the readline
user
    (in other words GDB), hence we get 39 instead of 40.

    II. Types of wrapping

    Looking a bit more in detail inside gdb, it seems there are two types of
    wrapping:
    - readline wrapping (in other words, prompt edit wrapping), and
    - gdb output wrapping (can be observed by issuing "info sources").
      This type of wrapping attempts to wrap some of the gdb output earlier
      than the indicated width, to not break lines in inconvenient places.

    III. Readline wrapping, auto-detected screen size

    Let's investigate readline wrapping with the auto-detected screen widths.

    First, let's try with xterm:
    ...
    $ TERM=xterm gdb
    (gdb) 7890123456789012345678901234567890
    123
    ...
    That looks as expected, wrapping occurs after 40 chars.

    Now, let's try with ansi:
    ...
    $ TERM=ansi gdb
    (gdb) 78901234567890123456789012345678
    90123
    ...
    It looks like wrapping occurred after 38, while readline should be capable
of
    wrapping after 39 chars.

    This is caused by readline hiding the last column, twice.

    In more detail:
    - readline detects the screen width: 40,
    - readline hides the last column, setting the readline screen width to 39,
    - readline reports 39 to gdb as screen width,
    - gdb sets its width setting to 39,
    - gdb sets readline screen width to 39,
    - readline hides the last column, again, setting the readline screen width
to
      38.

    This is reported as PR cli/30346.

    IV. gdb output wrapping, auto-detected screen size

    Say we set the terminal width to 56. With TERM=xterm, we have:
    ...
    /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c,
    /data/vries/hello.c,
    ...
    but with TERM=ansi:
    ...
    /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /
    data/vries/hello.c,
    ...

    So what happened here?  With TERM=ansi, the width setting is auto-detected
to
    55, and gdb assumes the terminal inserts a line break there, which it
doesn't
    because the terminal width is 56.

    This is reported as PR cli/30411.

    V. Fix PRs

    Fix both mentioned PRs by taking into account the hidden column when
readline
    reports the screen width in init_page_info, and updating chars_per_line
    accordingly.

    Note that now we report the same width for both TERM=xterm and TERM=ansi,
    which is much clearer.

    The point where readline respectively expects or ensures wrapping is still
    indicated by "maint info screen", for xterm:
    ...
    Number of characters readline reports are in a line is 40.
    ...
    and ansi:
    ...
    Number of characters readline reports are in a line is 39.
    ...

    VI. Testing

    PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp
    and gdb.tui/wrap-line.exp, so remove the KFAILs there.

    I didn't manage to come up with a regression test for PR cli/30411. 
Perhaps
    that would be easier if we had a maintenance command that echoes its
arguments
    while applying gdb output wrapping.

    Tested on x86_64-linux.

    PR cli/30346
    PR cli/30411
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411

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

[Bug cli/30346] [gdb/cli] CLI in ansi terminal has off-by-one width problem

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
   Target Milestone|---                         |14.1

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed.

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