bug#9767: 24.0.90; gdb initialization on Cygwin

[Eli Zaretskii]

> Date: Sun, 16 Oct 2011 19:08:32 -0400
> From: Ken Brown <kbrown@cornell.edu>
> 
> Further info: It seems that initialization is actually completing, but 
> for some reason the buffer is not being redisplayed.  To test this, I 
> inserted (sit-for .1) at the end of gdb-update to force redisplay, and 
> that solved the problem.  Unless someone who understands redisplay can 
> figure out why redisplay isn't happening on Cygwin, I'm inclined to 
> apply the following patch:

My crystal ball says that redisplay isn't happening because Emacs
doesn't know that the GDB prompt has arrived.  The call to sit-for
causes Emacs to check its input descriptors, "discovering" that there
is input.

Please look around in wait_reading_process_output, and see what is
going on there, before and after the call to sit-for.  In particular,
does the call to `select' report that input has arrived from GDB?

> === modified file 'lisp/progmodes/gdb-mi.el'
> --- lisp/progmodes/gdb-mi.el    2011-10-06 16:11:38 +0000
> +++ lisp/progmodes/gdb-mi.el    2011-10-16 23:04:28 +0000
> @@ -1726,7 +1726,8 @@
>       (gdb-force-mode-line-update
>        (propertize "initializing..." 'face font-lock-variable-name-face))
>       (gdb-init-1)
> -    (setq gdb-first-prompt nil))
> +    (setq gdb-first-prompt nil)
> +    (if (eq system-type 'cygwin) (sit-for .1)))
> 
>     (gdb-get-main-selected-frame)
>     ;; We may need to update gdb-threads-list so we can use
> 
> Would this be reasonable?

I think it's not going to solve the real problem.  If Emacs misses
some of the output arriving from GDB, it will miss it again under
similar circumstances.