[Bug tui/30388] New: [gdb/tui, TERM=ansi] first char of prompt in status line

[Bug tui/30388] New: [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

            Bug ID: 30388
           Summary: [gdb/tui, TERM=ansi] first char of prompt in status
                    line
           Product: gdb
           Version: 13.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tui
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider:
...
$ gdb -q -iex "set tui border-kind ascii" -tui
...

This gets us the expected lower border of src window, status line and prompt:
...
+----------------------------------------+
No process In:               L??   PC: ?? 
(gdb) 
...

With TERM=ansi, we have instead:
...
+----------------------------------------+
No process In:               L??   PC: ??(
gdb) 
...

This seems to have something to do with the status line window.

If I do:
...
diff --git a/gdb/tui/tui-layout.c b/gdb/tui/tui-layout.c
index 01d243ba9a1..5a860310856 100644
--- a/gdb/tui/tui-layout.c
+++ b/gdb/tui/tui-layout.c
@@ -1167,7 +1167,6 @@ initialize_layouts ()

   layout = new tui_layout_split ();
   layout->add_window (SRC_NAME, 2);
-  layout->add_window (STATUS_NAME, 0);
   layout->add_window (CMD_NAME, 1);
   add_layout_command (SRC_NAME, layout);


...
I get the expected:
...
+----------------------------------------+
(gdb) 
...

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
This seems to help in some cases, but not all:
...
-  waddstr (handle.get (), string.c_str ());
+  waddnstr (handle.get (), string.c_str (), width - 1);
...

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> With TERM=ansi, we have instead:
> ...
> +----------------------------------------+
> No process In:               L??   PC: ??(
> gdb) 
> ...

Good to note: ^L fixes this.

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
            Version|13.1                        |HEAD

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
Tentative patch:
...
diff --git a/gdb/tui/tui-stack.c b/gdb/tui/tui-stack.c
index 0a750187c26..4769a7706d1 100644
--- a/gdb/tui/tui-stack.c
+++ b/gdb/tui/tui-stack.c
@@ -183,10 +183,13 @@ tui_locator_window::make_status_line () const

   std::string string_val = string.release ();

-  if (string.size () < status_size)
-    string_val.append (status_size - string.size (), ' ');
-  else if (string.size () > status_size)
-    string_val.erase (status_size, string.size ());
+  size_t len = string_val.size ()
+  if (len < status_size)
+    string_val.append (status_size - len, ' ');
+  else if (len > status_size)
+    string_val.erase (status_size, len);
+
+  gdb_assert (string_val.size () == status_size);

   return string_val;
 }
...

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |normal

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #3)
> Tentative patch:

EWRONGPR, that was for PR30389.

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> This seems to help in some cases, but not all:
> ...
> -  waddstr (handle.get (), string.c_str ());
> +  waddnstr (handle.get (), string.c_str (), width - 1);
> ...

This case is fine:
...
$ TERM=ansi gdb -q -eiex "set tui border-kind ascii" -tui 
...
but this case still has the same problem:
...
$ TERM=ansi gdb -q -iex "set tui border-kind ascii" -tui
...

Also works fine with:
...
$ TERM=ansi gdb -q -iex "set tui border-kind ascii" -iex "tui enable"
...
and:
...
$ TERM=ansi gdb -q -eiex "set tui border-kind ascii" -iex "tui enable"
...

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #2)
> (In reply to Tom de Vries from comment #0)
> > With TERM=ansi, we have instead:
> > ...
> > +----------------------------------------+
> > No process In:               L??   PC: ??(
> > gdb) 
> > ...
> 
> Good to note: ^L fixes this.

Likewise:
...
diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c
index 7752701378e..267ddcb2d23 100644
--- a/gdb/tui/tui-io.c
+++ b/gdb/tui/tui-io.c
@@ -645,6 +645,7 @@ tui_redisplay_readline (void)
   TUI_CMD_WIN->start_line -= height - 1;

   wrefresh (w);
+  tui_refresh_all_win ();
   fflush(stdout);
 }

...

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
I'm close to giving up on this, I've played around quite a bit changing how the
status line is rendered, but the problem keeps reoccuring in different forms
and scenarios.

I'm starting to suspect that we're running 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.

I've a filed a new PR30419 - [gdb/tui] Support tui safe-mode on/off, to work
around this in a more generic fashion, with the idea of avoiding to run into
this
by hiding the last column, as readline does.

But it's possible that we have to classify this PR as not-a-bug: If you lie to
your application about the capabilities or your terminal, you may run into
trouble.

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Posted a proposal implementing "set tui hide-last-column on/off/auto" at 
https://sourceware.org/pipermail/gdb-patches/2023-May/199433.html .

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

[Bug tui/30388] [gdb/tui, TERM=ansi] first char of prompt in status line

[vries at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
If we observe what happens with script, we have the following sequence:
- +
- ^[[B
- ^[[39m^[[0;10m
- "(gdb) " 

------------------------------------------------------

The following is what ncurses expects to happen.

The "+" writes the bottom-right corner of the source window.

Since TERM=ansi has the am (auto_right_margin) capability:
...
$ infocmp -1 ansi | grep am
        am,
...
the cursors wraps to the next line, to the first char in the status window.

The  "^[[B" moves the cursor down, to the first char in the command window.

The "^[[39m^[[0;10m" resets the attributes to default foreground (39), and
selects ascii (10). 

The "(gdb) " writes the prompt at the top-left corner of the command window.

------------------------------------------------------

What actually happens is the following.

The "+" writes the bottom-right corner of the source window.

Since the actual terminal has xn/xenl/eat_newline_glitch, the cursor doesn't
wrap, but goes into the "ignore state".

Since the "^[[B" is a control sequence moving the cursor, three things happen:
- the "ignore state" is no longer active
- the cursor is repositioned at the last column (so, at the "+")
- the control sequence takes effect, moving the cursor to the last char in the
  status window

The "^[[39m^[[0;10m" resets the attributes to default foreground (39), and
selects ascii (10), as before.

The "(gdb) " writes the prompt, starting at the last char of the status window,
wrapping to the top-left corner of the command window.

------------------------------------------------------

So, why does the ^L help?

In that case we have the following sequence.

- +
- ^[[39m
- ^[[0;10;7m
- "None No process (src) In:                L??   PC: ?? "
- ^[[0;10m
- "(gdb) " 

What happens is the following.

The "+" writes the bottom-right corner of the source window.

The cursor doesn't wrap but goes into the "ignore state".

The "^[[39m" resets the foreground attribute to the default.

The "^[[0;10;7m" resets the attributes to the default (0), then switches on
ascii (10) and reverse video (7).

The status line is written.

On the first char, the following happens:
- the "ignore state" is no longer active
- the cursor wraps to the first char of the status line
- the char is written

On the last char, the cursor goes back into "ignore state".

The "^[[0;10m" resets the attributes to the default (0), then switches on ascii
(10).

The prompt is written.

On the first char, the following happens:
- the "ignore state" is no longer active
- the cursor wraps to the first char of the command window
- the char is written

------------------------------------------------------

In conclusion, the ^L helps, but that's not because we're missing some refresh
somewhere.

It's because the resulting refresh refreshes the screen in an order that's not
running into the newline glitch.

That does give a way in to try to address this in some way, by making refreshes
when the cursor might be in the "ignore state".

This particular problem is fixed by:
...
diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c
index 1b4cc82cce8..cf007396ade 100644
--- a/gdb/tui/tui-io.c
+++ b/gdb/tui/tui-io.c
@@ -605,6 +605,7 @@ tui_redisplay_readline (void)
   int c_line = -1;
   WINDOW *w = tui_cmd_win ()->handle.get ();
   int start_line = tui_cmd_win ()->start_line;
+  doupdate ();
   wmove (w, start_line, 0);
   int height = 1;
   if (prompt != nullptr)
...

After playing around with layout split and cycling focus through the windows, I
run into another problem which is fixed by:
...
diff --git a/gdb/tui/tui-wingeneral.c b/gdb/tui/tui-wingeneral.c
index de4ef52e6ce..fa392ef0fcf 100644
--- a/gdb/tui/tui-wingeneral.c
+++ b/gdb/tui/tui-wingeneral.c
@@ -89,6 +89,7 @@ box_win (struct tui_win_info *win_info,
           tui_border_hline, tui_border_hline,
           tui_border_ulcorner, tui_border_urcorner,
           tui_border_llcorner, tui_border_lrcorner);
+  wrefresh (win);
   if (!win_info->title ().empty ())
     {
       /* Emit "+-TITLE-+" -- so 2 characters on the right and 2 on
...

So that begs the question: do we want to implement, test, and maintain this
sort of workaround ?

The original idea about why this PR was relevant was to have some way of being
able to reproduce behaviour in the tuiterm in an actual terminal and vice
versa.

That was partly addressed by the proposed ansi-for-tui, which copied an ansi
terminfo entry and added the newline glitch to it, while adding that
functionality to tuiterm.

But we seem to be moving towards xterm support in tuiterm, so that starts to
look like the solution to that particular problem.

So I guess the answer is no.

I think there is value in having a centralized point that controls updating,
and having an option that controls how that's done for debugging purposes and
as workaround in case users run into trouble.  But that should be an
implementation-focused effort, not trying to solve this problem.  Perhaps, once
that's done, implementing a workaround for this could be a simple tweak. 
Perhaps not.

Either way, I'm closing this as not-a-bug.

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