bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#843: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size


From: Lennart Borgman (gmail)
Subject: bug#843: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
Date: Sun, 31 Aug 2008 23:40:13 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666

Michael Kifer wrote:
> 
> On Sun, 31 Aug 2008 15:40:21 +0200
> "Lennart Borgman (gmail)" <address@hidden> wrote:
> 
>> When I just made a checkout of Emacs from CVS I got a merge conflict
>> which I used ediff-revision to resolve. I then got the following back
>> trace when I did "wb" to save the corrected file:
>>
>> Debugger entered--Lisp error: (error "Buffer exceeds maximum size")
>>   call-process("diff" nil #<buffer *ediff-custom-diff*> nil "-c"
> 
> This says that the output of diff -c exceeds the buffer size.
> 
> It is unclear how this is related to ediff per se, since ediff merely calls
> call-process with the above command.
> 
>> "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M"
>> "c:/ecvsnew/bld/emacs/src/w32term.c")
>>   apply(call-process "diff" nil #<buffer *ediff-custom-diff*> nil ("-c"
>> "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M"
>> "c:/ecvsnew/bld/emacs/src/w32term.c"))
>>   ediff-exec-process("diff" #<buffer *ediff-custom-diff*> synchronize
>> "-c" "c:/DOCUME~1/LENNAR~1/LOCALS~1/Temp/ediff282470M"
>> "c:/ecvsnew/bld/emacs/src/w32term.c")
>>   ediff-compute-custom-diffs-maybe()
>>   ediff-save-buffer(nil)
>>   call-interactively(ediff-save-buffer nil nil)
>>
>> Looking into ediff-custom-diff I can see there is some problem with ^M:
> 
> Can you explain what the problem is? It is unclear from the included text 
> below.

Sorry, I thought the part of the output below should show it, but of
course the ^M characters I saw is gone here...

Lines somewhere below the middle of the output below had extra ^M at the
end of them.

I can't reproduce the problem now, maybe it was some kind of temporary
problem - perhaps a bad checkin to the CVS at that time?

> In any case, I deed to be able to reproduce it in order to be able to 
> determine
> if something needs to be fixed in ediff. Right now it does not look like
> an ediff problem.
> 
> michael
> 
> 
>> !    emacs_event->part = scroll_bar_handle;
>> !    y = 0;
>> !    break;
>>         case SB_BOTTOM:
>> !    emacs_event->part = scroll_bar_handle;
>> !    y = top_range;
>> !    break;
>>         case SB_THUMBTRACK:
>>         case SB_THUMBPOSITION:
>> !    if (VERTICAL_SCROLL_BAR_TOP_RANGE (f, XINT (bar->height)) <= 0xffff)
>>             y = HIWORD (msg->msg.wParam);
>>
>> !    bar->dragging = Qt;
>>
>> !    emacs_event->part = scroll_bar_handle;
>>
>>
>>
>> !    /* "Silently" update current position.  */
>>
>> !    {
>>
>> !      SCROLLINFO si;
>>
>>
>>
>>
>> This was with my patched version, but I do not think I have any patches
>> that comes in here:
>>
>> In GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>>  of 2008-08-28 (patched)
>> Windowing system distributor `Microsoft Corp.', version 5.1.2600
>> configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include'
>>
>>
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]