Bug 30370 - [gdb/tui] tui border-kind acs looks weird for TERM=ansi and LANG=en_US.UTF-8
Summary: [gdb/tui] tui border-kind acs looks weird for TERM=ansi and LANG=en_US.UTF-8
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: tui (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-04-18 15:44 UTC by Tom de Vries
Modified: 2023-05-04 07:41 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Tentative patch (999 bytes, patch)
2023-04-18 22:40 UTC, Tom de Vries 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2023-04-18 15:44:24 UTC 
When using gdb's TUI with TERM=ansi and LANG=en_US.UTF-8, I get a weird border:
...
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³                                                                            ³
³                                                                            ³
...

This is with the default tui border-kind acs.

I tracked this down to not using NCURSES_NO_UTF8_ACS=1, with which I get instead:
...
┌────────────────────────────────────────────────────────────────────────────┐
│                                                                            │
...

I wonder if we should consider this an ncurses problem or a gdb problem.

In the latter case, I wonder if GDB can detect this problem, and set NCURSES_NO_UTF8_ACS=1 before initializing ncurses.
Comment 1 Tom de Vries 2023-04-18 22:09:53 UTC 
(In reply to Tom de Vries from comment #0)
> and set
> NCURSES_NO_UTF8_ACS=1 before initializing ncurses.

That seems to be possible, this has the desired effect:
...
diff --git a/gdb/tui/tui.c b/gdb/tui/tui.c
index 3604194a760..9bb9b1e73ef 100644
--- a/gdb/tui/tui.c
+++ b/gdb/tui/tui.c
@@ -402,6 +402,7 @@ tui_enable (void)
       if (!gdb_stderr->isatty ())
        error (_("Cannot enable the TUI when output is not a terminal"));
 
+      putenv (strdup ("NCURSES_NO_UTF8_ACS=1"));
       s = newterm (NULL, stdout, stdin);
 #ifdef __MINGW32__
       /* The MinGW port of ncurses requires $TERM to be unset in order

...
Comment 2 Tom Tromey 2023-04-18 22:24:07 UTC 
IIUC this env var is a workaround for buggy terminals and/or
incorrect termcap entries.  I tend to doubt gdb should unilaterally set it.
Comment 3 Tom de Vries 2023-04-18 22:40:58 UTC 
Created attachment 14840 [details]
Tentative patch

My best guess at how this could work.
Comment 4 Tom de Vries 2023-04-18 22:54:00 UTC 
(In reply to Tom Tromey from comment #2)
> IIUC this env var is a workaround for buggy terminals and/or
> incorrect termcap entries.  I tend to doubt gdb should unilaterally set it.

I understand the reasoning.

It's just that TERM=ansi is used in the TUI testsuite, so I'm using that all the time when debugging TUI test-cases on an actual terminal (rather than the ansi terminal emulator in the testsuite), and each time I run into this PR (both on openSUSE Leap 15.4 and Ubuntu 22.04) I end up using "set tui border-kind ascii" to work around it (but as I've just learned, I could also use NCURSES_NO_UTF8_ACS=1).

So, my attempt at a rationale for fixing this PR would be that if we use TERM=ansi in the testsuite, we should try to make that work as expected on the average terminal emulator.
Comment 5 Tom de Vries 2023-04-19 13:38:57 UTC 
Tried another approach, submitted RFC "[gdb/tui] Add set tui border-kind acs-or-space/acs-or-ascii" here ( https://sourceware.org/pipermail/gdb-patches/2023-April/198982.html ).
Comment 6 Tom de Vries 2023-05-04 07:41:22 UTC 
See also PR30419.