Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!yale!bunker!hcap!hnews!129!89!Carla.Campbell From: Carla.Campbell@f89.n129.z1.fidonet.org (Carla Campbell) Newsgroups: misc.handicap Subject: Re: Review Modes Message-ID: <18581@bunker.isc-br.com> Date: 10 Apr 91 18:00:12 GMT Sender: wtm@bunker.isc-br.com Reply-To: Carla.Campbell@f89.n129.z1.fidonet.org Organization: FidoNet node 1:129/89 - BlinkLink, Pittsburgh PA Lines: 136 Approved: wtm@bunker.hcap.fidonet.org Index Number: 14722 [This is from the Blink Talk Conference] AH> Here are some examples where I can compare ARtic "halt review," AH> with Ibm(s) "pointer," mode. Thanks, Al-- your thoughts were just what I was looking for. I have long seen the advantages of _having_ a "pointer mode"-- though you bring up some ways of using it and advantages which I had not considered. My "ideal world speech program" (Hereafter, MIWSP for short. ) would have both capabilities: allowing processing to continue or to obtrusively stop the world while I get off and look around a minute. While, as you say, a Dir or a type or any other command can be run with a /p or ">more" command, I'm lazy. I'm too lazy to have aliased the commands "dir" and "type" to "dir /p" and "type >more", much less to type them. (assuming that I used Dir and Type: in fact, I usually use SDir and Sqwint, but that's another story. I used Dir and Type as examples because they are more familiar than other utilities which I had in mind.) But that's trivial. If it bugged me enough, I'd alias it. My laziness _does_ have a threshhold, at least, beyond which I do myself a favor and fix things. The more usual use I have for halting processing is online. I do extensive work on systems with live conferencing capabilities. I use an external modem with a Tweedle-Dump on the cable (incidentally, I have had no trouble with this gadget and have found it to be very useful). I sometimes have to do other things while I wait for the system to do something or while I wait around for other users to appear and say something. What I do is to go into review mode. Then, I hear information coming in by the Tweedle-Dump's buzzing and can go get out of review and hear anything which came in whilst I was away from the keyboard. Since this is not like downloading, I have never had buffering problems with incoming data. If I used ctrl-s, ctrl-q, I would not know that anything had happened, since nothing would have come into my modem or come across my screen. If I simply turned off speech, I would have to go into review/activate the pointer and move around the screen, perhaps even having to scroll back a screen or two to catch everything when I ran over to turn it on again on hearing someting coming in The "Scroll-back, review and scrounge for new information" technique is slow with speech. I must be _fast_ with this work-- and am. Many people have no idea that I use speech synthesis. (While I do not _care_ who knows, I don't always like to spend my whole evening talking about talking computers and would rather just do a fast, efficient job of what I do and deal with the other matters at hand. I talk about speech synthesis plenty at my real job and here on the echo. ) I know the above is a very unusual situation, but MIWSP would deal with it, somehow. In the meantime, since no one is leaping forward to write MIWSP, I wonder if you've got any brilliant ideas of a good work-around, were I to be using a program with a 'non-intrusive review mode" or "pointer". You've got great ideas about using the pointer, so I figure you're gonna have something for me on this, too! Right? The more common use I have for the "system halting" review mode is just to catch the opening screen of a program, without missing the next data which passes across the screen, or to stop at log-on to a system to catch the bulletin info a second time. (this could be accomplished through a series of maneuvers of scroll-back and review mode, but again, I'm lazy.) I use it to catch messages which are flashed up on the screen oh-so-briefly, again, without losing the next data to be displayed. That sort of thing-- situations in which the program or utility has no way of pausing output are particularly of concern to me in this discussion. I cannot think of any way, save for your suggestion of yet another TSR (or internal script, in the case of Screen Reader) to run to "pause" the computer's processing. I would accept such as a viable solution if it were truly a well-behaved program which worked properly from inside other applications and did not interfere with other TSRs such as my speech software-- or, as per your suggestion, if it were simply a scripted extention of the speech program, itself. AH> Basically you want to do several things with this screen, AH> hit return, look for your job status changes, such as if lines AH> printed went down, and so on, but you don't want to go into AH> review, find the line, and then read it, with a nonintrusive, AH> you can leave your pointer mode on the line, and just read AH> after a return each time, or even make the program watch the AH> line you define. I can definitely see the use, here. To achieve the same goal, I would do one of two things. If that screen was the one I was going to be using all the time, I would, as you suggested, set a monitor (or hyperactive or wahtever we're calling them this week) window to look for changes and read them aloud when they're spotted. that way there's no key-press at all-- not even a move to pointer and read current word one. If, instead, the screen locations in which I was interested changed, I would go into review and use the "go back to last location" command or the "go to previously marked location" command and read the current word. (Willie, you wanted to know where people used macros-- this would be an example of a good place to use one!). That is more keystrokes than a pointer mode would use, and I admit I don't like it, either. Just describing how it might be dealt with, application willing. I prefer the monitoring option. AH> With Telix, or Procomm, and ARtic, I have noticed a easy AH> way to mess up a file transfer with zmodem, just go into AH> review, and for that matter, you can even mess it up by just AH> hitting the review-line key too many times. For that, I have defined a window that is very small-- the exact size of the area saying what is left to download-- elapsed time and bytes received-- I read the window with an alt-whatever and it does not seem to bog down the transfer. Dunno what it would do at 9600, but it's ok at 2400. I use it infrequently during any given transfer, but have found no problems with doing it that way-- unlike, as you describe, doing it the review mode way. I am not for a moment suggesting that my laziness ought to be catered to over someone's ability to use programs such as the 3278 emulator situation you described with ease... just wondering if ya can't, somehow, have your cake and eat it, too. I enjoy the different perspectives and ideas of work-arounds for speech-awkward situations that this sort of discussion uncovers. Thank you for taking the time to give me your thoughts on the matter! I am, if I was not before, convinced that pointers are useful critters-- now I'm just looking for time-efficient work-around ways of dealing with the things which I use review mode for before I start _wanting_ a pointer of my very own. Talk at ya soon. Cheers. --Carla ... Read what I mean, not what I write! -- Uucp: ..!{decvax,oliveb}!bunker!hcap!hnews!129!89!Carla.Campbell Internet: Carla.Campbell@f89.n129.z1.fidonet.org