gdb/tui: fix issue with handling the return character

My initial goal was to fix our gdb/testsuite/lib/tuiterm.exp such that
it would correctly support (some limited) scrolling of the command
window.

What I observe is that when sending commands to the tui command window
in a test script with:

  Term::command "p 1"

The command window would be left looking like this:

  (gdb)
  (gdb) p 1$1 = 1
  (gdb)

When I would have expected it to look like this:

  (gdb) p 1
  $1 = 1
  (gdb)

Obviously a bug in our tuiterm.exp library, right???

Wrong!

Turns out there's a bug in GDB.

If in GDB I enable the tui and then type (slowly) the 'p 1\r' (the \r
is pressing the return key at the end of the string), then you do
indeed get the "expected" terminal output.

However, if instead I copy the 'p 1\r' string and paste it into the
tui in one go then I now see the same corrupted output as we do when
using tuiterm.exp.

It turns out the problem is that GDB fails when handling lots of input
arriving quickly with a \r (or \n) on the end.

The reason for this bug is as follows:

When the tui is active the terminal is in no-echo mode, so characters
sent to the terminal are not echoed out again.  This means that when
the user types \r, this is not echoed to the terminal.

The characters read in are passed to readline and \r indicates that
the command line is complete and ready to be processed.  However, the
\r is not included in readlines command buffer, and is NOT printed by
readline when is displays its buffer to the screen.

So, in GDB we have to manually spot the \r when it is read in and
update the display.  Printing a newline character to the output and
moving the cursor to the next line.  This is done in tui_getc_1.

Now readline tries to reduce the number of write calls.  So if we very
quickly (as in paste in one go) the text 'p 1' to readline (this time
with no \r on the end), then readline will fetch the fist character
and add it to its internal buffer.  But before printing the character
out readline checks to see if there's more input incoming.  As we
pasted multiple characters, then yes, readline sees the ' ' and adds
this to its buffer, and finally the '1', this too is added to the
buffer.

Now if at this point we take a break, readline sees there is no more
input available, and so prints its buffer out.

Now when we press \r the code in tui_getc_1 kicks in, adds a \n to the
output and moves the cursor to the next line.

But, if instead we paste 'p 1\r' in one go then readline adds 'p 1' to
its buffer as before, but now it sees that there is still more input
available.  Now it fetches the '\r', but this triggers the newline
behaviour, we print '\n' and move to the next line - however readline
has not printed its buffer yet!

So finally we end up on the next line.  There's no more input
available so readline prints its buffer, then GDB gets passed the
buffer, handles it, and prints the result.

The solution I think is to put of our special newline insertion code
until we know that readline has finished printing its buffer.  Handily
we know when this is - the next thing readline does is pass us the
command line buffer for processing.  So all we need to do is hook in
to the command line processing, and before we pass the command line to
GDB's internals we do all of the magic print a newline and move the
cursor to the next line stuff.

Luckily, GDB's interpreter mechanism already provides the hooks we
need to do this.  So all I do here is move the newline printing code
from tui_getc_1 into a new function, setup a new input_handler hook
for the tui, and call my new newline printing function.

After this I can enable the tui and paste in 'p 1\r' and see the
correct output.

Also the tuiterm.exp library will now see non-corrupted output.

gdb/ChangeLog:

	* tui/tui-interp.c (tui_command_line_handler): New function.
	(tui_interp::resume): Register tui_command_line_handler as the
	input_handler.
	* tui/tui-io.c (tui_inject_newline_into_command_window): New
	function.
	(tui_getc_1): Delete handling of '\n' and '\r'.
	* tui-io.h (tui_inject_newline_into_command_window): Declare.

gdb/testsuite/ChangeLog:

	* gdb.tui/scroll.exp: Tighten expected results.  Remove comment
	about bug in GDB, update expected results, and add more tests.

1 files changed, 39 insertions, 34 deletions

diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c
index 0a33d53..a2be4d4 100644
--- a/gdb/tui/tui-io.c
+++ b/gdb/tui/tui-io.c
@@ -991,6 +991,45 @@ tui_dispatch_ctrl_char (unsigned int ch)
   return 0;
 }
 
+/* See tui-io.h.   */
+
+void
+tui_inject_newline_into_command_window ()
+{
+  gdb_assert (tui_active);
+
+  WINDOW *w= TUI_CMD_WIN->handle.get ();
+
+  /* When hitting return with an empty input, gdb executes the last
+     command.  If we emit a newline, this fills up the command window
+     with empty lines with gdb prompt at beginning.  Instead of that,
+     stay on the same line but provide a visual effect to show the
+     user we recognized the command.  */
+  if (rl_end == 0 && !gdb_in_secondary_prompt_p (current_ui))
+    {
+      wmove (w, getcury (w), 0);
+
+      /* Clear the line.  This will blink the gdb prompt since
+	 it will be redrawn at the same line.  */
+      wclrtoeol (w);
+      wrefresh (w);
+      napms (20);
+    }
+  else
+    {
+      /* Move cursor to the end of the command line before emitting the
+	 newline.  We need to do so because when ncurses outputs a newline
+	 it truncates any text that appears past the end of the cursor.  */
+      int px, py;
+      getyx (w, py, px);
+      px += rl_end - rl_point;
+      py += px / TUI_CMD_WIN->width;
+      px %= TUI_CMD_WIN->width;
+      wmove (w, py, px);
+      tui_putc ('\n');
+    }
+}
+
 /* Main worker for tui_getc.  Get a character from the command window.
    This is called from the readline package, but wrapped in a
    try/catch by tui_getc.  */
@@ -1010,40 +1049,6 @@ tui_getc_1 (FILE *fp)
 
   ch = gdb_wgetch (w);
 
-  /* The \n must be echoed because it will not be printed by
-     readline.  */
-  if (ch == '\n' || ch == '\r')
-    {
-      /* When hitting return with an empty input, gdb executes the last
-	 command.  If we emit a newline, this fills up the command window
-	 with empty lines with gdb prompt at beginning.  Instead of that,
-	 stay on the same line but provide a visual effect to show the
-	 user we recognized the command.  */
-      if (rl_end == 0 && !gdb_in_secondary_prompt_p (current_ui))
-	{
-	  wmove (w, getcury (w), 0);
-
-	  /* Clear the line.  This will blink the gdb prompt since
-	     it will be redrawn at the same line.  */
-	  wclrtoeol (w);
-	  wrefresh (w);
-	  napms (20);
-	}
-      else
-	{
-	  /* Move cursor to the end of the command line before emitting the
-	     newline.  We need to do so because when ncurses outputs a newline
-	     it truncates any text that appears past the end of the cursor.  */
-	  int px, py;
-	  getyx (w, py, px);
-	  px += rl_end - rl_point;
-	  py += px / TUI_CMD_WIN->width;
-	  px %= TUI_CMD_WIN->width;
-	  wmove (w, py, px);
-	  tui_putc ('\n');
-	}
-    }
-  
   /* Handle prev/next/up/down here.  */
   ch = tui_dispatch_ctrl_char (ch);