bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

[Adrian Robert]

> Using "configure --with-ns" on Leopard: Using M-x gdb with gdb-many- 
> values set to t, the associated buffers, e.g., stack locals etc.  
> have an extra ^M at the end of each line

If you get a chance, could you see if this happens with an X11 emacs  
on OS X?  I'm not aware of any code in the Cocoa port that would set  
things relating to line endings (or anything else non-graphical -- it  
just renders glyphs and faces given to it by xdisp.c), but perhaps  
it's some kind of weird interaction with the system-detected line  
ending format?

Or are there some line-ending-related settings that gud does.. hmm, I  
see you are listed as the maintainer of progmodes/gdb-ui.el -- would  
you know anything about this?

bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

[Nick Roberts]

Adrian Robert writes:
 > > Using "configure --with-ns" on Leopard: Using M-x gdb with gdb-many- 
 > > values set to t, the associated buffers, e.g., stack locals etc.  
 > > have an extra ^M at the end of each line
 > 
 > If you get a chance, could you see if this happens with an X11 emacs  
 > on OS X?  I'm not aware of any code in the Cocoa port that would set  
 > things relating to line endings (or anything else non-graphical -- it  
 > just renders glyphs and faces given to it by xdisp.c), but perhaps  
 > it's some kind of weird interaction with the system-detected line  
 > ending format?

I can't test X11 emacs on OS X, but Carbon Emacs (as included in Leopard)
with a wrapper for running as a GUI works OK.

To be honest,  Carbon Emacs generally seems to work better, e.g., mouse-2
works.

What does Cocoa Emacs (NextStep Emacs?) have that Carbon Emacs doesn't?
(I'm a Mac OS X novice).

 > Or are there some line-ending-related settings that gud does.. hmm, I  
 > see you are listed as the maintainer of progmodes/gdb-ui.el -- would  
 > you know anything about this?

I don't think gdb-ui.el does anything special but the buffers might implicitly
misinterpret line-endings.

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

bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

[Stefan Monnier]

> What does Cocoa Emacs (NextStep Emacs?) have that Carbon Emacs doesn't?
> (I'm a Mac OS X novice).

A maintainer.


        Stefan

bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

[Nick Roberts]

Adrian Robert writes:
 > > Using "configure --with-ns" on Leopard: Using M-x gdb with gdb-many- 
 > > values set to t, the associated buffers, e.g., stack locals etc.  
 > > have an extra ^M at the end of each line
 > 
 > If you get a chance, could you see if this happens with an X11 emacs  
 > on OS X?  I'm not aware of any code in the Cocoa port that would set  
 > things relating to line endings (or anything else non-graphical -- it  
 > just renders glyphs and faces given to it by xdisp.c), but perhaps  
 > it's some kind of weird interaction with the system-detected line  
 > ending format?

I've done that now and can confirm that GDB related buffers have an extra ^M at
the end of each line with an X11 emacs too.

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

bug#1045: #1045 - 23.0.60; (Cocoa Emacs) - Emacs bug report logs

[Adrian Robert]

On Oct 20, 2008, at 4:02 AM, Nick Roberts wrote:

> Adrian Robert writes:
>>> Using "configure --with-ns" on Leopard: Using M-x gdb with gdb-many-
>>> values set to t, the associated buffers, e.g., stack locals etc.
>>> have an extra ^M at the end of each line
>>
>> If you get a chance, could you see if this happens with an X11 emacs
>> on OS X?  I'm not aware of any code in the Cocoa port that would set
>> things relating to line endings (or anything else non-graphical -- it
>> just renders glyphs and faces given to it by xdisp.c), but perhaps
>> it's some kind of weird interaction with the system-detected line
>> ending format?
>
> I've done that now and can confirm that GDB related buffers have an  
> extra ^M at
> the end of each line with an X11 emacs too.

OK, useful to know.  What happens if you hit <Ret> in a gdb buffer --  
do you get a ctrl-M then, or only when gdb itself (or gud?) outputs  
something?  If the former, it must be some setting for the buffer  
itself, and we could track that down.  If the latter, do you know  
which function gud is using to write to the buffer?

Also, is gdb run through a shell, and if so, which one?

I tried to replicate this myself, but cannot.  I did the following:

M-x gdb
<path-to-prog> <Ret>

The gdb buffer that results has no ctrl-m's, even if I run the  
program.  Could you provide a more precise recipe to induce the bug?   
(Or, I'm wondering if it depends on the shell...)

thanks,
Adrian