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

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

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


From: Michael Kifer
Subject: bug#844: 23.0.60; ediff-merge-revision: Buffer exceeds maximum size
Date: Sun, 31 Aug 2008 18:43:54 -0400


On Sun, 31 Aug 2008 23:40:13 +0200
"Lennart Borgman (gmail)" <address@hidden> wrote:

> 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?

I don't know -haven't seen this. But the main problem seems to have been that
diff -c produced a very large buffer, although I can't imagine  how big it
could have been in order to cause the "Buffer exceeds maximum size" error.
In any case, it seems to be a problem with diff or call-process, if at
all.

> > 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]