Cocoa Emacs (2)

Cocoa Emacs (2)

[Nick Roberts]

In Cocoa Emacs using TAB in the GUD buffer (gud-gdb-complete-command) causes
Emacs to freeze (C-g frees it).  It gets stuck waiting in accept-process-output
in gud-gdb-run-command-fetch-lines.

TAB in the GUD buffer using Carbon Emacs that comes with Leopard (22.1?) works
fine, although this might be comparing apples with pears.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs (2)

[Adrian Robert]

Nick Roberts <nickrob <at> snap.net.nz> writes:

> In Cocoa Emacs using TAB in the GUD buffer (gud-gdb-complete-command) causes
> Emacs to freeze (C-g frees it).  It gets stuck waiting in accept-process-output
> in gud-gdb-run-command-fetch-lines.

I can't replicate it (Emacs -Q, M-x gud RET TAB) on Leopard.
Any special config details or anything else I should know?

Re: Cocoa Emacs (2)

[Nick Roberts]

 > > In Cocoa Emacs using TAB in the GUD buffer (gud-gdb-complete-command)
 > > causes Emacs to freeze (C-g frees it).  It gets stuck waiting in
 > > accept-process-output in gud-gdb-run-command-fetch-lines.
 > 
 > I can't replicate it (Emacs -Q, M-x gud RET TAB) on Leopard.

TAB needs to be used as a completion.  Maybe you mean this, but just to be
clear, asssuming you have an executable called myprog:

M-x gdb<RET>
Run gdb (like this): gdb --annotate=3 ~/myprog

Then in the GUD buffer, doing:

Current directory is /home/nickrob/
GNU gdb 6.6-debian
...
(gdb) b m<TAB>

should complete on "m" if there is just one completion, e.g malloc@plt, or
generate a completions buffer if there is more than one.

YMMV but I have found this quite a good mode to debug Emacs itself.

 > Any special config details or anything else I should know?

I don't think so, but I, as I say, I don't really know what I'm doing on
Mac OS X.  I'll have another look.  Meanwhile, does anybody else see/not see
this?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Cocoa Emacs (2)

[Adrian Robert]

On Aug 1, 2008, at 6:30 PM, Nick Roberts wrote:

>>> In Cocoa Emacs using TAB in the GUD buffer (gud-gdb-complete- 
>>> command)
>>> causes Emacs to freeze (C-g frees it).  It gets stuck waiting in
>>> accept-process-output in gud-gdb-run-command-fetch-lines.
>>
>> I can't replicate it (Emacs -Q, M-x gud RET TAB) on Leopard.
>
> TAB needs to be used as a completion.  Maybe you mean this, but just  
> to be
> clear, asssuming you have an executable called myprog:
>
> M-x gdb<RET>
> Run gdb (like this): gdb --annotate=3 ~/myprog

OK, running M-x gdb will lead to the bug, but M-x gud does not,  
despite running same line (gdb --annotate=3 src/emacs in my case).   
One difference I noticed is that when running via M-x gdb some status  
is shown in the modeline, while via M-x gud does not.  I don't know a  
tremendous amount about gud/gdb.. could there be some difference in  
process-listening between the two different invocations?

Re: Cocoa Emacs (2)

[Nick Roberts]

 > OK, running M-x gdb will lead to the bug, but M-x gud does not,  
 > despite running same line (gdb --annotate=3 src/emacs in my case).

OK, I see.


 > One difference I noticed is that when running via M-x gdb some status  
 > is shown in the modeline, while via M-x gud does not.  

M-x gud-gdb is the old 'text-command' mode as in Emacs 21, while M-x gdb
gives the GDB Graphical Interface as described in the manual.


 >                                                       I don't know a  
 > tremendous amount about gud/gdb.. could there be some difference in  
 > process-listening between the two different invocations?

I think M-x gdb fails because of the extra ^M characters that are printed by
gdb, as I reported earlier in:

http://lists.gnu.org/archive/html/emacs-devel/2008-07/msg01421.html

It appears that Mac different line endings to normal Unix/Linux just as
w32 does, but this doesn't appear to cause a problem/be visible with
Carbon Emacs.


-- 
Nick                                           http://www.inet.net.nz/~nickrob