public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tui/30419] New: [gdb/tui] Support tui safe-mode on/off Date: Thu, 04 May 2023 07:29:41 +0000 [thread overview] Message-ID: <bug-30419-4717@http.sourceware.org/bugzilla/> (raw) 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.
next reply other threads:[~2023-05-04 7:29 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-04 7:29 vries at gcc dot gnu.org [this message] 2023-05-04 7:38 ` [Bug tui/30419] " vries at gcc dot gnu.org 2023-05-09 13:33 ` vries at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30419-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).