[Bug tui/30419] New: [gdb/tui] Support tui safe-mode on/off

[Bug tui/30419] New: [gdb/tui] Support tui safe-mode on/off

[vries at gcc dot gnu.org]

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

            Bug ID: 30419
           Summary: [gdb/tui] Support tui safe-mode on/off
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: tui
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When I use TUI in a terminal emulator like konsole or gnome-terminal, TERM is
set to xterm or some such and everything works fine.

In the testsuite we use TERM=ansi because that's what tuiterm (our terminal
emulator in the testsuite) supports.

When looking into problems in TUI test-cases, I try to replay the scenario
outside the testsuite, on an actual terminal emulator, but using TERM=ansi,
because that matches what happens in the test-suite.

The idea is to use this as a tool to direct investigation, whether the problem
is in tuiterm or gdb.

I've found both types of problems and fixed a few of those.

However, I've now started run into other type of problems, where gdb is not
really doing something wrong, and the tuiterm is also correct:
- PR30370, where we run into the problem addressed by NCURSES_NO_UTF8_ACS
- PR30388, where we run into the problem that setting TERM to something
  changes the capabilities reported to the application, but not the behaviour
  of the terminal emulator itself.  More specifically with xterm we have the
  am and xn capabilities set, with ansi just am, but the terminal will
  behave the same regardless.

In both these cases doing something about it by default will degrade the
experience in a regular terminal emulator with TERM=xterm.

Furthermore, the solution I proposed here (
https://sourceware.org/pipermail/gdb-patches/2023-April/198982.html ) for
PR30370 handles it by exposing the problem in an existing setting, and doing
that for each problem in a different setting will likely make things look a bit
confusing for the user.

So, I'm thinking of a tui safe-mode on/off setting (or something sounding a bit
less dramatic), off by default, where:
- off means current behaviour, and
- on means:
  - handling PR30370, by eliminating the border-kind acs, unless the user
    set NCURSES_NO_UTF8_ACS to 1 to indicate curses should apply the
    workaround, or set to 0 to indicate curses doesn't need to apply the
    workaround.  Or to make things more simple, just eliminate it regardless.
  - handling PR30388, by, as readline does, eliminating the last column from
the
    equation, so only allow curses windows that are wide one less than screen
    width.

The advantage of controlling things in a single setting is that this doesn't
leak into the existing settings in an intrusive way, and it could be used in
bug reports, asking the reporter to verify whether a problem also reproduces in
safe mode, which would then eliminate a class of known problems.

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

[Bug tui/30419] [gdb/tui] Support tui safe-mode on/off

[vries at gcc dot gnu.org]

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

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

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

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

[Bug tui/30419] [gdb/tui] Support tui safe-mode on/off

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
I implemented a first version, but wasn't happy with the result.

I've now posted a patch that implements part of the functionality as "set tui
hide-last-column on/off/auto", and I'm playing around with a patch that
implements set tui profile default/ascii, where by doing "set tui profile <p>"
we apply a coherent collection of settings.

Then we could implement an alternative to "set tui safe-mode on/off" by
implementing a profile safe-mode (or, conservative, or basic or some such) that
does:
- set tui hide-last-column on, and
- set tui border-kind ascii.

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