Bug in FIXDISK 2?

[John McMillan]

In article <21503 at rphroy.UUCP> tkacik at rphroy.UUCP (Tom Tkacik) writes:
>I recieved FIXDISK 2 last night and installed them looking forward to
>seeing what Lenny was talking about (Metermaid etc.).
>
>After rebooting and playing a little bit, I managed to lose the ksh that
>was running in a full screen window.  The working icon was lit, and nothing
>else worked.

	Lots of folks are running 'm' with no such trouble.
	'Probably some local fluke in the way your system went
	down... or the way it's administered.

:
>I have never seen this happen before, so I can only assume that this is
>a new bug introduced in 3.51m.  I do not know how to duplicate this.

	Is this a COMPLAINT?-)  You have a MOMENTARY problem and you
	WANT it to recur?  ...  Geee... there are LOTS of kernels
	on the back shelf if you want THAT !!!

>Also playing with the three-shift-key functions showed that they were
>acting kinda' flakey as well.  (They would not always toggle properly.)

	The code is particularly sensative to the RATE at which you
	toggle the keys: normal typing rates will cause some confusion
	in the triple-key handler.
	
	Methinks it's associated with the RE-DISPLAY of the STATUS
	information:  you're toggling it faster than it can re-display
	and it becomes temporarily confused.  This is difficult
	to avoid IF re-displaying is to occur here, and re-displaying
	seems better than leaving an out-of-date status line.
	
	NOTE: this is done within the kernel and within the keyboard
	interrupt handler.  If a complex routine were demanded to
	unravel the diversity of state transitions, all this would
	have been discarded!  The simple code has its limitations.

>Maybe these problems are related, I do not know.

	Distant cousins... hardly know one another....

john mcmillan -- att!mtune!jcm -- muttering for self, not THEM