Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 20 Mar 2010 15:45:59 -0400, Stefan Monnier <address@hidden> said:

>> +   ;; Workaround for some Apple versions of GDB that add ^M at EOL
>> +   ;; after the command "server interpreter mi -stack-info-frame".
>> +   (if (string-match "(Apple version " gdb-first-output-line)
>> +       (let* ((process (get-buffer-process gud-comint-buffer))
>> +         (coding-systems (process-coding-system process)))
>> +    (set-process-coding-system process
>> +                               (coding-system-change-eol-conversion
>> +                                (car coding-systems) 'dos)
>> +                               (cdr coding-systems))))
>> + 

> Actually, detecting the CRLF itself would be better.  But at least this
> seems "safe for GNU".  So I think it's acceptable for 23.2.

Strangely, the EOL style suddenly changes from LF to CRLF after the
command "server interpreter mi -stack-info-frame", .  I.e., the first
output line ends with LF.  Maybe I'll improve the comment.

>> +       (if (not (string-match "\n" gdb-first-output-line))
>> +      (setq gdb-first-output-line
>> +            (concat gdb-first-output-line
>> +                    (if (string-match "\n" output)
>> +                        (substring output 0 (match-end 0))
>> +                      output))))
>> output)))
  
> Rather than string-match, you can
> (eq ?\n (aref gdb-first-output-line (1- (length gdb-first-output-line))))

Currently, gdb-first-output-line is initialized to "".  And I thought

  (and (not (string= gdb-first-output-line "")
       (eq ?\n (aref gdb-first-output-line
                     (1- (length gdb-first-output-line))))

a bit awkward and doubted its merit because it involves more
bytecode-level operations.  Of course, one can initialize the variable
to some dummy non-empty string, but it doesn't look natural.

                                     YAMAMOTO Mitsuharu
                                address@hidden