Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gvlf3.gvl.unisys.com!faatcrl!jprad
From: jprad@faatcrl.UUCP (Jack Radigan)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: Features I'd like to see in JRCOMM
Message-ID: <947@faatcrl.UUCP>
Date: 7 Feb 91 12:55:55 GMT
References: <1991Feb3.075026.1923@ckctpa.UUCP> <910203.083436@lerami.lonestar.org> <26681@uflorida.cis.ufl.EDU> <52363@sequent.UUCP> <26743@uflorida.cis.ufl.EDU>
Organization: FAA Technical Center, Atlantic City NJ
Lines: 26

jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes:

>A)  You would have to save the buffer to open it in another screen.
>(This takes more time, especially when you are on a BBS which
>has a time out value...)

  Regardless of the few seconds wasted, the *big* win is that the capture
file being read by your choosen text reader, not my idea of one.  Besides,
I've got a reader that I use all the time already, there's little motivation
for me to waste time duplicating it for private use in JR-Comm.

>B)  Snap does NOT work across all fonts.

  It works with the fonts in JR-Comm and with the system fonts.

>I trust Jack to write it well... :)  Jack could make
>Jr-Comm internally multitasking.  Else, once could still save
>the capture buffer (as he would have to in order to follow
>your proceedure) but one one would not be faced with the 
>time it takes as per your method.

  What's with all this "internal" multitasking talk?  The *only* change I
had to make, and it's in there for the 1.02 release, is to close the capture
file before the file transfer is started.

  -jack-