I'm so sorry for the big delay.  I was not able to use computers these
days.

> > 2. The command "shell" is broken: In M-x gdb,
> >
> > shell ps aux | grep emacs
> >
> > results in no output; but in a "real" gdb, the output looks like this:
> >
> > shell ps aux | grep emacs
> > &"shell ps aux | grep emacs\n"
> > xgp 4886 1.3 0.1 80796 25900 pts/1 T 09:38 0:08 emacs
> > xgp 4936 0.3 0.1 77688 22568 pts/10 T+ 09:39 0:02 ./emacs
> > xgp 5209 0.0 0.1 28128 16548 pts/6 Ss+ 09:46 0:00 /usr/local/bin/gdb -i=mi emacs
> > xgp 5353 0.4 0.1 28184 16584 pts/1 S+ 09:49 0:00 gdb -i=mi emacs
> > xgp 5354 0.0 0.0 52800 976 pts/1 S+ 09:49 0:00 bash -c ps aux | grep emacs
> > xgp 5356 0.0 0.0 51124 688 pts/1 S+ 09:49 0:00 grep emacs
> > ^done
>
> Output of GDB's shell command goes as is straight to the terminal
> without being prefixed by stream identifier (~, @, & etc.) Thus it's
> harder to distinguish where this output should go (to GUD buffer, to MI
> parser etc.) I managed to produce a small patch which does the trick for
> simple shell commands like yours, but don't expect it to work with
> `top(1)` for example. I've attached the patch. Let me know if you notice
> that it breaks something.

I see.  The patch works very well.

I got an idea of how to catch the output of `top(1)': Setting up the
gud buffer to make it behave like a shell buffer temporarily during
the execution of the `shell' command, and switching back to make it
behave in the gdb way after seen `^done'.  However, this seems not to
be worthy implementing, because normally only simple shell commands
are executed via the `shell' command.

> > 3. Previously, typing directly RET at the M-x gdb prompt repeats the
> > last command in history. This is also what a "real" gdb does. But in
> > the new implementation, this does nothing now.
>
> I've fixed the code which mimicks RET behaviour for GUD buffer.

It works for me, thank you.

And here's another three problems:

4. Killing a gdb buffer won't send the `detach' command to the gdb
process, leaving the debugged process permentally being stopped.  This
is often unconvenient.

5. The commands like `while' and `if' cannot be handled correctly.
Combined with problem #4, this leads to a bad use case: After typing
such a command, the gdb process hangs, so the gdb buffer has to be
killed.  Then, the debugged process hangs and has to be killed.  As a
result, both the debugger and the debugged process have to be
restarted.

6. Completion should be done with the emacs completion feature,
i.e. try-completion, completing-read etc.

Regards,
Guanpeng Xu


_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/