🚀 go-pugleaf

Using Epoch 4.2, SunOS 4.1.1, compiled with bundled `cc -O,' running
under OpenWindows 2.0 with olwm.

To generate the error in the subject line, do

  epoch -q -nm
  M-x vm
  now resize epoch before vm finishes getting your mail

Here's the (ASCII part of the) traceback:

Signalling: (error "No other window to side of this one")
  shrink-window(18 t)
  byte-code("[arg t nil shrink-window] 3)
  shrink-window-horizontally(18)
  vm-proportion-windows()
  vm(nil nil)
* call-interactively(vm)

and the offending piece of code from vm, below, coupled with the
behavior described above, indicates that screen-width is updated
immediately upon resizing, but buffer-width does not catch up until
after (vm) returns control to the keyboard.  The result is that vm
thinks I have a vertically split window to the side of the current
window because window-width <> screen-width.  Solving this problem
should help solve the related minibuffer size problem when resizing
Epoch while the minibuffer is the active window.

---------------- from vm-proportion-windows -------------------------

(let ((mail-w (get-buffer-window (current-buffer)))
	       (n (- (window-width (get-buffer-window (current-buffer)))
		     (/ (* vm-mail-window-percentage (screen-width))
			100)))
	       (old-w (selected-window)))
	   (if mail-w
	       (save-excursion
		 (select-window mail-w)
		 (shrink-window-horizontally n)
		 (select-window old-w)
		 (and (memq major-mode '(vm-summary-mode vm-virtual-mode))
		      (vm-auto-center-summary)))))

-Jerry