No other window to side of this one

Thread View: gnu.epoch.misc

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Jerry Thu, 29 Oct 1992 20:10

#10

Author: Jerry
Date: Thu, 29 Oct 1992 20:10

44 lines
2070 bytes

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

infinite-beep-mode

#11

Author: Brian L. Kahn
Date: Fri, 30 Oct 1992 20:31

26 lines
1723 bytes

I get a very annoying problem with epoch once in a while.  I'm
wondering if anyone else has seen this behavior.

Every once in a while, I'll click on something in epoch and find that
I've accidentally entered infinite-beep-mode.  The message area
displays "marker does not point anywhere" and the keyboard beeps
forever.  Epoch is hung, and so is the keyboard, and the Xserver, and
life, the universe, and everything.  Well, the mouse still moves, but
focus no longer follows the mouse and clicks are ignored.  There is no
way to stop the beeping without logging in from another terminal and
killing processes.  Sometimes the beeping stops about a hundred beeps
after I've killed the offending epoch, sometimes I have to reboot.

As you might imagine, this is very embarassing during a demo I do for
VIPs which uses epoch.  "Oops, have to shut down the machine, that
happens sometimes."  Really professional.

The evidence makes me suspect that epoch has gone into some loop with
the server, generating errors that somehow generate new events.  Since
reading the mouse position can generate new events sometimes, I
suspect the loop is in that area.  Anyone else seen this behavior?


--
B<   Brian Kahn   blk@mitre.org   "may the farce be with you"

Re: infinite-beep-mode

#20

Author: Jim Brewer
Date: Mon, 02 Nov 1992 20:19

10 lines
969 bytes

In article <BLK.92Oct30153115@vanity.mitre.org> blk@mitre.org (Brian L. Kahn) writes:
>I get a very annoying problem with epoch once in a while.  I'm
>wondering if anyone else has seen this behavior.

  I have a couple of times.  I get exactly the same behavoir as Brian.
I'll try Lynn's function to see if it helps, but I get this so rarely
(about once every 2 months) that I don't know if I'll be able to tell.

  -Jim

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads