michael@stb.UUCP (Michael) (08/22/88)
Bug report, window driver 3.51. Problem: When windows are switched, the window that was active has all of its keyboard input flushed. Repeat-by: cat /dev/window Type this into the new screen. <CR> <Suspend> (Notice the words are displayed on the original screen) Type this second line <Suspend> (Notice that it is not displayed) <Suspend> Type this third line. <CR> <Ctrl-D> (Notice that lines one and three are displayed by the cat program, but line 2 is not.) : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
richard@uhccux.uhcc.hawaii.edu (Richard Foulk) (08/24/88)
} Bug report, window driver 3.51. } Problem: When windows are switched, the window that was active has all of } its keyboard input flushed. It's in the manual so it must be a feature. Richard
bob@rush.cts.com (Bob Ames) (08/27/88)
In article <10552@stb.UUCP>, michael@stb.UUCP (Michael) writes: > Bug report, window driver 3.51. > Problem: When windows are switched, the window that was active has all of > its keyboard input flushed. I consider this a feature. This feature was included in all UNIX PC releases except 3.50. 3.50 would even (somehow) remember <Suspd> and <resum> keys (YUK!) through window changes. Thank goodness AT&T fixes 3.51 back to the old (2.0, 2.01, 3.0) way! |-) Bob Ames INET: bob@rush.cts.com Howard Publications, Inc. Bell: 208-733-0931 UUCP: {rutgers!ucsd, nosc, hplabs!hp-sdd}!crash!rush.cts.com!bob "I didn't expect the Spanish Inquisition!" "We each pay a fabulous price - for our visions of paradise." - Rush 1987 --- Bob Ames INET: bob@rush.cts.com Howard Publications, Inc. Bell: 208-733-0931 UUCP: {rutgers!ucsd, nosc, hplabs!hp-sdd}!crash!rush.cts.com!bob "I didn't expect the Spanish Inquisition!" "We each pay a fabulous price - for our visions of paradise." - Rush 1987
michael@stb.UUCP (Michael) (09/12/88)
In article <761@rush.cts.com> bob@rush.cts.com (Bob Ames) writes: >In article <10552@stb.UUCP>, michael@stb.UUCP (Michael) writes: >> Bug report, window driver 3.51. >> Problem: When windows are switched, the window that was active has all of >> its keyboard input flushed. > >I consider this a feature. This feature was included in all UNIX PC releases Well, I don't. It has the following effects: #1. Ctrl-s is lost when you change windows #2. If you type part of a command, switch windows to check the file name in another window, and then go back, there is a command line there that you typed but the system ignores. Now, the <SUSP> key was being remembered across window changes? You mean if you hit it fast enough, then when you re-enabled the window, that the window manager redisplayed its choice window? Or do you mean that hitting shift-susp fast enough caused the window to have a "stored next window" that activated the next time it was the active window. Both of these sound like window manager bugs to me. (After all, it is the one that receives the susp keys) Michael : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : Coff Coff <=== Stop smoking.
jr@amanue.UUCP (Jim Rosenberg) (09/19/88)
In article <10581@stb.UUCP> michael@stb.UUCP (Michael) writes: >In article <761@rush.cts.com> bob@rush.cts.com (Bob Ames) writes: >>In article <10552@stb.UUCP>, michael@stb.UUCP (Michael) writes: >>> Bug report, window driver 3.51. >>> Problem: When windows are switched, the window that was active has all of >>> its keyboard input flushed. >> >>I consider this a feature. This feature was included in all UNIX PC releases > >Well, I don't. It has the following effects: > >#1. Ctrl-s is lost when you change windows >#2. If you type part of a command, switch windows to check the file name in > another window, and then go back, there is a command line there > that you typed but the system ignores. Re #2: There seems to be some interaction with the termio state. In ksh if you are still "cooked" when you switch windows you will lose your command line, as reported. In my opinion what is really a bug here is that YOU GET NO VISUAL FEEDBACK that you've lost your command line. When you switch back to the window the eaten characters still show on the screen. This is very dangerous. Just imagine if the argument you first type on switching back is actually the name of a command, with perhaps nasty side-effects ... But what is interesting is that if in ksh I remember to type ESC before the window switch, woila, when I come back *NO* characters have been eaten. Hittng ESC causes ksh to consume all of the charaters typed before going into character-at-a-time I/O, so it appears that when the window manager flushes the line there is nothing to flush. One *can* make oneself learn the habit to hit ESC before a window switch, but it isn't easy! And of course this does you no good outside of ksh. [BTW: I use the vi mode of ksh; no flames please if the character to enter edit mode for emacs mode isn't ESC -- you get the idea.] -- Jim Rosenberg CIS: 71515,124 decvax!idis! \ WELL: jer allegra! ---- pitt!amanue!jr BIX: jrosenberg uunet!cmcl2!cadre! /
krohn@u1100a.UUCP (Eric Krohn) (09/20/88)
In article <404@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes:
] One *can* make oneself learn the habit to hit ESC before a window switch, but
] it isn't easy! And of course this does you no good outside of ksh.
]
] [BTW: I use the vi mode of ksh; no flames please if the character to enter
] edit mode for emacs mode isn't ESC -- you get the idea.]
I run ksh with set -o vi -o viraw. This forces all input to ksh to be done
in raw mode, with its inefficiencies (not that I care). I need not type ESC
before switching windows to preserve my typeahead. (This is probably why I
never noticed this bug that (most) everyone is yelling about! :-) The real
reason I run with viraw mode is so the ^W word erase and ^U (my line kill)
behave as in vi as soon as I start typing a command.
Emacs mode of ksh always runs in raw mode so no need for the ESC game to
switch from cooked to raw.
--
--
Eric J. Krohn
krohn@ctt.ctt.bellcore.com or {bcr,bellcore}!u1100a!krohn
Bell Communications Research, 444 Hoes Ln, Piscataway, NJ 08854ditto@cbmvax.UUCP (Michael "Ford" Ditto) (09/21/88)
In article <404@amanue.UUCP> jr@amanue.UUCP (Jim Rosenberg) writes: >But what is interesting is that if in ksh I remember to type ESC before the >window switch, woila, when I come back *NO* characters have been eaten. Hittng >ESC causes ksh to consume all of the charaters typed before going into [ ... ] >[BTW: I use the vi mode of ksh; no flames please if the character to enter >edit mode for emacs mode isn't ESC -- you get the idea.] [ I hope this isn't considered a flame: ] In emacs mode, ksh is always in raw mode so this doesn't happen. In vi mode, you can set the "viraw" option to make ksh always use raw mode, and then you won't have the problem (at a slight system performance cost -- not even worth worrying about on the Unix PC, if anywhere). As Jim pointed out, the above methods only help when sitting at the ksh prompt; when running programs in cooked mode the "bug" will still happen. If anyone's taking votes, I call it a bug and would fix it if it were up to me. -- -=] Ford [=- . . (In Real Life: Mike Ditto) . : , ford@kenobi.cts.com This space under construction, ...!ucsd!elgar!ford pardon our dust. ditto@cbmvax.commodore.com