jprad@faatcrl.UUCP (Jack Radigan) (02/04/91)
231b3678@fergvax.unl.edu (CS 231 section 2) writes: >Here's a small list of the includes I'd like to see to jrcomm: >1) In the file transfer window have % efficiency for transfer. Is this *really* neccesary? You've already got a chars/sec. I mean, do I need to post every possible kind of stat that can be computed? >2) Have a scratchpad so I can put all my miscellaneous stuff on it like > > :-) is a smilie > (402)421-1963 SWL BBS 6316 files! > Dr.Death is also known as Mr.Death > > Prefferably a huge screen of string gadgets (like the MACRO editor). > Pasting and clipping can be used with SNAP!! :-) Clipboard support will be added. As for this, it may be better to just save this to a file and massage it into a script to load the macro keys (for the 1.1 version, which will have scripts). >3) Have a complete status feature. It keeps track of how many times > you've called a BBS, the number files you've up/downloaded from the BBS, > the files you transferred, > the date and time you last called it, the length of the session, and the > accumulative total of your PHONE BILL! Preferrably stuck in the phonebook, > like click the STATUS button and click the BBS you want info on. A complete call/usage tracking facility will eventually wind its way into JR-Comm, doubtful for 1.1 though. >4) Scripting (but who needs it! If you're that despirate for script languages > just use NCOMM the few times you want to use it) Yep, 1.1 will have scripts and ARexx. >5) Make the VIEW-buffer a task, so we can STILL scroll around in it > and read it s while we're up/downloading (Z-Term allows this! :-( The 1.02 version will close the capture file prior to starting a file transfer so that you can load it into the text reader of your choosing. It will also reopen the capture file (append mode) after the transfer completes. Is that sufficient? I can't see incorporating the code into JR-Comm for what would essentially be my idea of a text reader, which is almost surely not your idea of what one should be... -jack-
231b3678@fergvax.unl.edu (CS 231 section 2) (02/04/91)
In article <926@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >231b3678@fergvax.unl.edu (CS 231 section 2) writes: > >>Here's a small list of the includes I'd like to see to jrcomm: > >>1) In the file transfer window have % efficiency for transfer. > > Is this *really* neccesary? You've already got a chars/sec. I mean, do I >need to post every possible kind of stat that can be computed? > >>2) Have a scratchpad so I can put all my miscellaneous stuff on it like >> >> :-) is a smilie >> (402)421-1963 SWL BBS 6316 files! >> Dr.Death is also known as Mr.Death >> >> Prefferably a huge screen of string gadgets (like the MACRO editor). >> Pasting and clipping can be used with SNAP!! :-) > > Clipboard support will be added. As for this, it may be better to just save >this to a file and massage it into a script to load the macro keys (for the >1.1 version, which will have scripts). > >>3) Have a complete status feature. It keeps track of how many times >> you've called a BBS, the number files you've up/downloaded from the BBS, >> the files you transferred, >> the date and time you last called it, the length of the session, and the >> accumulative total of your PHONE BILL! Preferrably stuck in the phonebook, >> like click the STATUS button and click the BBS you want info on. > > A complete call/usage tracking facility will eventually wind its way into >JR-Comm, doubtful for 1.1 though. > >>4) Scripting (but who needs it! If you're that despirate for script languages >> just use NCOMM the few times you want to use it) > > Yep, 1.1 will have scripts and ARexx. > >>5) Make the VIEW-buffer a task, so we can STILL scroll around in it >> and read it s while we're up/downloading (Z-Term allows this! :-( > > The 1.02 version will close the capture file prior to starting a file >transfer so that you can load it into the text reader of your choosing. It >will also reopen the capture file (append mode) after the transfer completes. >Is that sufficient? I can't see incorporating the code into JR-Comm for what >would essentially be my idea of a text reader, which is almost surely not your >idea of what one should be... > > -jack- Yeah, but is the VIEW buffer stored to a file, not the CAPTURE file? ===== Well, as long as you incorporate AREXX, my options I wished for can easily be added! I never considered using AREXX to do this until you said the new version would have it! Now I can assign F10 (or menu item) to load up the ScratchPad etc! (of course it'll load up some 200k wordprocessor to accomplish what a small 3k addition would do...... :-) wow! Phil Dietz --- I don't like to flame! Phil Dietz You know what? 231b3678@fergvax.unl.edu Newton and Leibniz suck big time! Univ. of Nebraska
231b3678@fergvax.unl.edu (CS 231 section 2) (02/04/91)
Oops...I forgot to say something on my last post.
Make sure that the JRCOMM screen will be PUBLIC so my Arexx screens
can popup on it (and make the Arexx options professional.)
See Ya
Phil Dietz
---
University of Nebraska Phil Dietz //
Computer Science 231b3678@fergvax.unl.edu \\// out the
235b4271@fergvax.unl.edu \/ Amiga!jprad@faatcrl.UUCP (Jack Radigan) (02/05/91)
231b3678@fergvax.unl.edu (CS 231 section 2) writes: >Yeah, but is the VIEW buffer stored to a file, not the CAPTURE file? Of course it will, that's one of the functions that is performed when you close the capture file already. >Well, as long as you incorporate AREXX, my options I wished for can easily >be added! I never considered using AREXX to do this until you said the >new version would have it! > >Now I can assign F10 (or menu item) to load up the ScratchPad etc! (of course >it'll load up some 200k wordprocessor to accomplish what a small 3k addition >would do...... :-) Well, having CED hotstarted is much more convienent for ARexx use, but to each his own... -jack-
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/05/91)
In article <926@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >231b3678@fergvax.unl.edu (CS 231 section 2) writes: >>5) Make the VIEW-buffer a task, so we can STILL scroll around in it >> and read it s while we're up/downloading (Z-Term allows this! :-( > > The 1.02 version will close the capture file prior to starting a file >transfer so that you can load it into the text reader of your choosing. It >will also reopen the capture file (append mode) after the transfer completes. >Is that sufficient? I can't see incorporating the code into JR-Comm for what >would essentially be my idea of a text reader, which is almost surely not your >idea of what one should be... > Jack, here's a suggestion. Take a look at the Review Buffer in Telemate 2.11 on the IBM. It's a damn nice setup. While downloading, you can hit Alt-B to pop up a box with a scrollable buffer of your session. Take the mouse, hold down the left button, drag across a file name in a listing, and then move the mouse pointer down to the main screen. Press the right button and it pastes that highlighted name. This type of intuitionized clipboard would make interactive downloading quick, easy, and fast. I think this is along the lines of what CS 231 section 2 was asking for. Personally, I'm more concerned with scripts and Kermit (XPR) use. When 1.1 (or whatever it's number is) comes out with these features, I know I'll be switching over to Jr-Comm and registering it. (And the thing I mentioned above would swing a lot of people over from what I've heard in circles of users....) -- John M. Adams --***-- Professional Student /// Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) (02/06/91)
jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: < >231b3678@fergvax.unl.edu (CS 231 section 2) writes: < >>5) Make the VIEW-buffer a task, so we can STILL scroll around in it < >> and read it s while we're up/downloading (Z-Term allows this! :-( < [ Description of cut-and-paste feature of Telemate deleted ] I would suspect that if JRComm (or any other comm program) supports some form of capture file, then you have all the tools you need to do file name cutting and pasting. For example, you log into a BBS or other system to download. You open the capture file, then list the appropriate files. Now, you toggle to WB, where you load the capture file into your favorite speedy-whiz-bang text-file viewer, and find the file you want. Using Snap, you select the filename, toggle back to the comm program, and paste it in. The real beauty of this scenario is that you aren't limited by the comm program author's notion of what makes 'good' navigation through a view buffer. Not to mention the fact that now you have a permanent record of the file listing from the BBS, so you can review it later to find some other file you might have missed, and you CAN still scroll around in it while a download is in progress. Remember, the Amiga has a feature called multitasking. Use it. Regards, Chris -- Chris (Insert phrase here) Seaman | ___-/^\-___ cseaman@gateway.sequent.com <or> | //__--\O/--__\\ nI' yIyIn 'ej yIchep. ...!uunet!sequent!cseaman | // \\ The Home of the Killer Smiley | `\ /'
jerry@truevision.com (Jerry Thompson) (02/06/91)
In article <26681@uflorida.cis.ufl.EDU> jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >buffer of your session. Take the mouse, hold down the left button, >drag across a file name in a listing, and then move the mouse pointer >down to the main screen. Press the right button and it pastes >that highlighted name. This type of intuitionized clipboard That's what Snap is for. If you have been using telcomm software without snap, you need to get a copy. -- Jerry Thompson | // checks ___________ | "I'm into S&M, I loved the peace and solitude | \\ // and | | | | Sarcasm and so much, I invited my friends. | \X/ balances /_\ | /_\ | Mass Sarcasm."
amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) (02/06/91)
In article <1991Feb03.221430.19135@hoss.unl.edu>, CS 231 section 2 writes: > Here's a small list of the includes I'd like to see to jrcomm: > [lots of features deleted :-] And a feature I (and all european users) miss very much in JRcomm: vowel mutation (or in german - "Umlaute") Bye, Andreas -- Andreas M. Kirchwitz, Seesener Str. 69, D-1000 Berlin 31, FRG, +49 30 873376 / __ Domain: amk@zikzak.in-berlin.de, IRC-Nick: 'bonzo' /___(oo)_________________________________ Bang: ...!unido!fub!unlisys!zikzak!amk " "
jprad@faatcrl.UUCP (Jack Radigan) (02/06/91)
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: >The real beauty of this scenario is that you aren't limited by the >comm program author's notion of what makes 'good' navigation through >a view buffer. Not to mention the fact that now you have a permanent >record of the file listing from the BBS, so you can review it later >to find some other file you might have missed, and you CAN still >scroll around in it while a download is in progress. >Remember, the Amiga has a feature called multitasking. Use it. <clap clap clap>... -jack-
lordbah@bisco.kodak.COM (Lord Bah) (02/06/91)
> 3) Have a complete status feature. It keeps track of how many times > you've called a BBS, the number files you've up/downloaded from the BBS, > the files you transferred, > the date and time you last called it, the length of the session, and the > accumulative total of your PHONE BILL! Preferrably stuck in the phonebook, > like click the STATUS button and click the BBS you want info on. I use Perl scripts on the jrcomm.log file to generate some of these, and could get the rest that way too. What I'd like to do is to get the scripts run from crontab on the first of every month, but for some unknown (to me) reason Perl objects to being run from crontab and produces no output. > 4) Scripting (but who needs it! If you're that despirate for script > languages just use NCOMM the few times you want to use it) Has anyone gotten NCOMM to play nicely with the AmigaUUCP Getty? -------------------------------------------------------------------- Jeff Van Epps amusing!lordbah@bisco.kodak.com lordbah@cup.portal.com sun!portal!cup.portal.com!lordbah
jprad@faatcrl.UUCP (Jack Radigan) (02/07/91)
amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes: >And a feature I (and all european users) miss very much in JRcomm: > vowel mutation (or in german - "Umlaute") Set the keymap variable in the general parameters requester and *poof* umlates, whatever. Deadkeys are fully supported in JR-Comm 1.01... -jack-
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/07/91)
In article <52363@sequent.UUCP> cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: >I would suspect that if JRComm (or any other comm program) supports >some form of capture file, then you have all the tools you need to do >file name cutting and pasting. For example, you log into a BBS or >other system to download. You open the capture file, then list the >appropriate files. Now, you toggle to WB, where you load the capture >file into your favorite speedy-whiz-bang text-file viewer, and find the >file you want. Using Snap, you select the filename, toggle back to the >comm program, and paste it in. Problems: 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...) B) Snap does NOT work across all fonts. > >The real beauty of this scenario is that you aren't limited by the >comm program author's notion of what makes 'good' navigation through >a view buffer. Not to mention the fact that now you have a permanent >record of the file listing from the BBS, so you can review it later >to find some other file you might have missed, and you CAN still >scroll around in it while a download is in progress. 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. > >Remember, the Amiga has a feature called multitasking. Use it. > Well, let's see. I run Paragon (or did you miss my .signature) so I usually have about 30 tasks online. I think I utilitize multitasking... -- John M. Adams --***-- Professional Student /// Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/07/91)
In article <1991Feb5.224154.19498@truevision.com> jerry@truevision.com (Jerry Thompson) writes: > >That's what Snap is for. If you have been using telcomm software without >snap, you need to get a copy. > Yes, I use Snap 1.4. Two problems though: A) I've seen Snap crap out on some fonts. B) Will Jr-Comm do a split screen on the review buffer? And if so, will it comply with Snap's need to have the destination window active, instead of the review buffer? -- John M. Adams --***-- Professional Student /// Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
t22918@ursa (Matt Ranney) (02/07/91)
jimb@faatcrl.UUCP (Jim Burwell) writes: >downloads, just run Snap, and point and click away right on Jr-Comm's screen, >or in the scrollback buffer, or on any other screen or window in the system What is Snap? I've never heard of it before. It sound like something I'd really be interested in. Is it PD? >Repeat this as many times as necessary: The Amiga is NOT an MS-DOS machine. amen. I'd like to suggest an improvement to the transfers routines: when a download is started, there could be something to check for enough disk space for the file to fit. With auto Z-modem, it easy just to start a DL to a floppy that you THINK has enough room, only to find out 10 minutes later that it's full. I know it's easy enough just to pop back and check the status yourself, but it would add (IMHO) to the overall slickness of the program. Plus, since we're all sitting on Santa's lap anyway, I thought I'd throw in an excerpt from my wish list. Keep up the good work, Jack. -- Matt Ranney "There are a few occasions where you do t22918@ursa.calvin.edu need to use a 'GOTO'... but... well mranney@wybbs.mi.org you didn't just hear me say that." mranney@pogo.ai.mit.edu -Dr. Joel Adams
jma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/07/91)
In article <935@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: >transfer is in progress. If you want to point and click on filenames for >downloads, just run Snap, and point and click away right on Jr-Comm's screen, >or in the scrollback buffer, or on any other screen or window in the system >which has the text you're interested in. As I said in a previous posting, this option takes too much time. I would like it native in the terminal program. >Repeat this as many times as necessary: The Amiga is NOT an MS-DOS machine. No sh*t Sherlock. That's why I *BOUGHT* an Amiga. >Don't try to use it like one, when there are usually much more elegent ways >to do what you're trying to do. The key to productivity on the Amiga is >the realization that the programmer of the application doesn't have to GIVE >you the features you want. They can usually be had easily by taking advantage >of the Amiga's built in multitasking. I'm not. I want something that is quick and easy. If you like running three applications to do what I want to do in one application, then so be it for you. The key to productivity to me is getting something done in the shortest time frame. I am offering suggestions of what I would like in Jr-Comm to Jack. He is certainly under no obligation to incorporate them. But I am getting sick of the attitude of "Do it with external programs." *THAT* is definitely an IBM attitude. Remember -- Elegant != Better. >PS: Sorry for any flames. I'm not in the best of moods, and the thought of >JR-Comm turning into the JR-operating-system doesn't make things any better. Then don't post flames. -- John M. Adams --***-- Professional Student /// Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/07/91)
In article <943@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes: > >>And a feature I (and all european users) miss very much in JRcomm: >> vowel mutation (or in german - "Umlaute") > > Set the keymap variable in the general parameters requester and *poof* >umlates, whatever. Deadkeys are fully supported in JR-Comm 1.01... No, I believe he doesn't talk about keymaps. You see, as most of this datacomm is with UNIX boxes, with only 7-bit ASCII or umlauts on different ASCII codes (err, it's enough to say PC instead of UNIX), and all that crap, there is a workaround: German umlauts are allowed to be rewritten as the normal vowel plus the letter e, e.g. a-umlaut becomes ae. Similarly, the sharp s (that looks like greek beta) becomes ss. To make this all really convenient, some datacomm programs allow the user to type in his normal umlaut characters, as he's accustomed to, but instantly change them into the form explained above. So this is a very German-special feature, I don't know whether something similar applies also to other languages. It's not vitally necessary, but it's a really nice feature to have and doesn't sound like all that hard to implement. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jprad@faatcrl.UUCP (Jack Radigan) (02/07/91)
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-
jprad@faatcrl.UUCP (Jack Radigan) (02/07/91)
jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >Yes, I use Snap 1.4. Two problems though: >A) I've seen Snap crap out on some fonts. >B) Will Jr-Comm do a split screen on the review buffer? And if so, >will it comply with Snap's need to have the destination window active, >instead of the review buffer? Yes, it works with the split screen review buffer. As for crapping out with some fonts, just make sure that your first snap of a new font is done on a non-blank character, otherwise it will most definately fail. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/07/91)
t22918@ursa (Matt Ranney) writes: >I'd like to suggest an improvement to the transfers routines: >when a download is started, there could be something to >check for enough disk space for the file to fit. With auto Z-modem, it >easy just to start a DL to a floppy that you THINK has enough room, only to >find out 10 minutes later that it's full. I know it's easy enough just to >pop back and check the status yourself, but it would add (IMHO) to the >overall slickness of the program. Plus, since we're all sitting on Santa's >lap anyway, I thought I'd throw in an excerpt from my wish list. Seek and ye shall find... Check the general parameters requester for the "Disk check" option. Just don't use it on a device like ram: that always reports back that it is full. >Keep up the good work, Jack. Thanks. -jack-
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) (02/08/91)
jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: < Problems (using capture files and snap for cutting and pasting): < < 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...) I realize that most BBSs have a timeout value. However, the process I described in my earlier article should not take the average Amiga user more than 5 or 10 seconds to execute. I would suspect that JRComm supports a keystroke to open and/or close a capture file, and it is almost second nature to me now to use Left-Amiga-N and Left-Amiga-M to toggle back and forth to the Workbench. If time is such a critical factor, then simply have the text-file viewer loaded before you start your communications program, or use Parm, MyMenu, of HandyIcons to add it to a Workbench menu. < B) Snap does NOT work across all fonts. This could be a problem, except for the fact that, of all of the fonts that have failed to work with Snap, I have yet to find one which would be acceptible for terminal emulation (or Workbench, for that matter). < 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. I would also trust Jack. In fact, given the features list of the next(?) release of JRComm, I may be able to start using it, and send him a check. The only reason I don't use it today is that I need kermit for file transfers to and from work. If XPR support is 'in there', he'll get my vote. Nevertheless, I would still prefer the file capture method to any view buffer, simply because it does give me that permanent record of the files on whatever host I am accessing. < Well, let's see. I run Paragon (or did you miss my .signature) < so I usually have about 30 tasks online. I think I < utilitize multitasking... Sorry about that. I sometimes get too hasty in my trimming of 'excess lines', so I did miss your .signature. No slight was intended. Regards, Chris -- Chris (Insert phrase here) Seaman | o\ /o See cseaman@gateway.sequent.com <or> | || "Attack of the Killer Smiley"! ...!uunet!sequent!cseaman | \vvvvvv/ Coming Soon | \____/ to a newsgroup near you!
guineau@wjg.enet.dec.com (W. John Guineau) (02/08/91)
In article <52363@sequent.UUCP>, cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: |> From: cseaman@sequent.UUCP (Chris "The Bartman" Seaman) |> Newsgroups: comp.sys.amiga.datacomm |> Subject: Re: Features I'd like to see in JRCOMM [stuff deleted] |> appropriate files. Now, you toggle to WB, where you load the capture |> file into your favorite speedy-whiz-bang text-file viewer, and find the |> file you want. Using Snap, you select the filename, toggle back to the |> comm program, and paste it in. Using SNAP on my machine (A2500/30) and JRComm gurus it everytime. All I need to do is start a snap (cut or paste) by holding the amiga key and clicking the mouse button - GURU! Also, Why does JRCOMM not provide a proper terminal identification string as a result of SET TERM/INQUIRE on VMS? I get "unrecognized terminal type" and have to type SET TERM/DEV=VT100 manually. I have VT100 selected in the setup menu. This is JRCOMM V1.01 -- W. John Guineau grep meaning life | more Digital Equipment Corporation guineau@wjg.enet.dec.com or wjg@wpi.wpi.edu
jimb@faatcrl.UUCP (Jim Burwell) (02/08/91)
jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: >In article <935@faatcrl.UUCP> jimb@faatcrl.UUCP (Jim Burwell) writes: >>transfer is in progress. If you want to point and click on filenames for >>downloads, just run Snap, and point and click away right on Jr-Comm's screen, >>or in the scrollback buffer, or on any other screen or window in the system >>which has the text you're interested in. >As I said in a previous posting, this option takes too much time. I would >like it native in the terminal program. First, I didn't see your previous posting. When I replied to your first message, there were no other replies on our system. Remember, UseNet is not magic. It can take up to 2 weeks for messages to propagate to every site. Now, how can doing a R-Amiga-F/return/L-Amiga-M/more jrcomm.cap/snap/L-Amiga-N (or whatever) take you more than 10 seconds ? And that's worse case scenerio. Most the time, the stuff I snap is right off of the screen, or the review buffer. Would what you were proposing take any less time than that ? >>Repeat this as many times as necessary: The Amiga is NOT an MS-DOS machine. >No sh*t Sherlock. That's why I *BOUGHT* an Amiga. >>Don't try to use it like one, when there are usually much more elegent ways ^^^^^^^^^^^^^^^^^^^^^^^^^^^^, Sherlock. >>to do what you're trying to do. The key to productivity on the Amiga is >>the realization that the programmer of the application doesn't have to GIVE >>you the features you want. They can usually be had easily by taking advantage >>of the Amiga's built in multitasking. >I'm not. I want something that is quick and easy. If you like running Hmm.. You mean something you don't have exercise an ounce of creativity to figure out how to do. Or something Magic. Perhaps you'd like it to figure out what you want to do before you can. For that kind of magic, buy a LISP machine :-). Naw. you just want pet-feature to work exactly like it does in your pet-comm- program on an MS-DOS machine. >three applications to do what I want to do in one application, then >so be it for you. The key to productivity to me is getting >something done in the shortest time frame. I am offering suggestions >of what I would like in Jr-Comm to Jack. He is certainly under >no obligation to incorporate them. But I am getting sick of >the attitude of "Do it with external programs." *THAT* is >definitely an IBM attitude. Huh? I can't figure that one out. With MS-DOS, the programmer typically has to build every concievable feature he can think of into his program. (Although some progress has been made with TSRs). "The Amiga way" is to run separate tasks (not Applications, nor "external programs", just tasks or processes running concurrently) to do what you want. The Amiga doesn't have any special names that I know of for programs like Snap. That's because there is nothing really special about them. It's just a program which runs in the background. Since running more than one program at a time is "something special" on an IBM, (or Mac), they've invented special names for 'em, like TSR and Desk Accessory. Snap is not an "Application", it's a small utility; AH! A "Commodity". I had forgotten about the new 2.0 classification which CBM has introduced. Running more than one program at the same time: *THAT* is definitely *NOT* an IBM attitude. >Remember -- Elegant != Better. Someone PLEASE explain this logic to me! Does he think "Elegant == Kludgy" ? Or perhaps he's complaining that "Elegant != Kludgy". Now that *IS* an MS-DOS attitude! ;-) >>PS: Sorry for any flames. I'm not in the best of moods, and the thought of >>JR-Comm turning into the JR-operating-system doesn't make things any better. >Then don't post flames. Flamez ? Moi ? You MUST be mistaken! >-- >John M. Adams --***-- Professional Student /// >Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga >Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible >Fido Net 1:3612/557. 904-492-2305 (Florida) \X/ ^^^^^ O...I C. C'ya, Jim -- +--------------------------+ _ |INET: jimb@faatcrl.uucp | | \ |UUCP: ..!rutgers!faatcrl!| _| \______________________________________ | jimb | - ______ ________________ \_`, +------------------------- + -(_______ -= -= USAF ) `--------=============----------------` - - - - ` . . - - .*` .* ;`*,`., `, ,`.*.*. * ______________________________________* * ` ^ *____________________________ IRAQ
amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) (02/08/91)
In article <943@faatcrl.UUCP>, Jack Radigan writes: > >And a feature I (and all european users) miss very much in JRcomm: > > vowel mutation (or in german - "Umlaute") > > Set the keymap variable in the general parameters requester and *poof* > umlates, whatever. Deadkeys are fully supported in JR-Comm 1.01... Ooops, excuse me - this works fine now with v1.01. (ashamed :-) I'm using VT102 at the moment and what I really miss are the colors. I set the "Screen Type" to "8 Colors" but nothing happens. No colors... As described in the vt102 manual, eight colors (foreground & background) can be used. (ESC-[-3-n (fg) and ESC-[-4-n (bg), where 'n' is 0-7) Bye, Andreas -- Andreas M. Kirchwitz, Seesener Str. 69, D-1000 Berlin 31, FRG, +49 30 873376 / __ Domain: amk@zikzak.in-berlin.de, IRC-Nick: 'bonzo' /___(oo)_________________________________ Bang: ...!unido!fub!unlisys!zikzak!amk " " "Ich liebe es, wenn ein Plan funktioniert." -- Hannibal (A-Team)
231b3678@fergvax.unl.edu (Phil Dietz) (02/08/91)
Hmmm..more options to make JRCOMM the Quintessential terminal:
1) Have a TURBO ascii send mode where it will not print the message you
are sending OR the messages sent from the machine you are sending it
to, until the transfer is done. The only time text on the screen
will show is when the transfer is complete. (Maybe have a little
ascii transfer upload status menu like Zmodem does)
REASON: at a direct connect 19.2k
connection, uploading ASCII files (uue's) results in trashed files
a lot. The buffer seems to be getting in the way and crapping the
transfer out (like it doesn't pick up the EOLN or something which
results like:
M234hiu23h4u23huhi4hu34ui23h4i23iu4hiu3h4iu32h4iu32432iu4hgggggggggggggggggggg
Mwqrferfhiuh3iuhiuhiu3hiuhiuhiu3
(extra long and extra short lines)
Plus as a benefit, since the screen doesn't have to bother with updating
the ascii transfer will BURN!
2) Full Arexx support on a public screen so all my handy utilities
(that i'll have to make) will be able to work smoothly! Wont it
be great having MORE macros or a scratch pad for necessary
telecomm. info. :-) (yepp I know arexx will be added. I'm just
saying what jrcomm will need to be god-like !)
3) Don't even think about stripping out your ZMODEM routines to replace
it with XPRZmodem! XPRZmodem wreaks a big one! Your zmodem
implementation is SO good, you should call it JRZmodem instead
of JRComm!
4) Think about adding Chuck Forsberg's new Zmodem compression algorithms.
They just added it to UNIX rz/sz and MSDOS in the last month or two.
5) Have a FOLLOW mouse option. Clicking on a spot will send the
appropriate cursor ups/lefts to get there! Also allow changing of
cursor ups etc. to hjkl's for VI and EMACS! This would be a
SMOOTH option!
hmmm...that's all for now.
Now everyone can flame broil my brain children to a smoldering heap of
charred flesh!
Phil Dietz
---
FACT: the Nebraska Cornhuskers Phil Dietz
signed a contract to lose the 231b3678@fergvax.unl.edu
big games! Yes, it's true! Univ. of Nebraskajma@beach.cis.ufl.edu (John 'Vlad' Adams) (02/08/91)
In article <52549@sequent.UUCP> cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: >next(?) release of JRComm, I may be able to start using it, and send >him a check. The only reason I don't use it today is that I need >kermit for file transfers to and from work. If XPR support is 'in >there', he'll get my vote. I agree. Kermit is the only thing holding me back from Jr-Comm. I never fail to praise Jr-Comm to other Amiga people. (Especially over NCOMM.) -- John M. Adams --***-- Professional Student /// Internet: jma@beach.cis.ufl.edu Genie: vlad /// Only the Amiga Sysop of The Beachside, Amiga BBS, Paragon 2.085 \\V// Makes it Possible Fido Net 1:3612/557. 904-492-2305 (Florida) \X/
sirotto@oak.circa.ufl.edu (Mike Cerrato) (02/08/91)
In article <19962@shlump.nac.dec.com>, guineau@wjg.enet.dec.com (W. John Guineau) writes: >Also, Why does JRCOMM not provide a proper terminal identification string >as a result of SET TERM/INQUIRE on VMS? I get "unrecognized terminal type" >and have to type SET TERM/DEV=VT100 manually. I have VT100 selected in the >setup menu. This is JRCOMM V1.01 I've never had any problems with SET TERM/INQUIRE with either the VT100 or VT102 mode with Jr-Comm 1.01. >W. John Guineau grep meaning life | more >Digital Equipment Corporation >guineau@wjg.enet.dec.com or wjg@wpi.wpi.edu ___ __ |\ |\ | / \ SirOtto -- Gallant Knight of a rather large, squarish | \ | \ | / table someplace in the West Panhandle of Florida. | \ | \ |--< | \| \|___\____/ Michael E. Cerrato -- University of Florida Internet: sirotto%maple.decnet@pine.circa.ufl.edu UUCP: ...!uunet!uflorida!pine.circa.ufl.edu!sirotto%maple.decnet
dtiberio@csserv1.ic.sunysb.edu (David Tiberio) (02/09/91)
In article <947@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >jma@beach.cis.ufl.edu (John 'Vlad' Adams) writes: > > > 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- Yes, it does severely lack in internal multitasking. I think Access! has internal multitasking (you can open up all of the windows at the same time). I am working on a terminal program and BBS that does multitask internally, unlike all other BBSs and terminals. The user can access almost anything at any time. It's nice to be able to download something while changing phone numbers in the address book or something like that. But I shouldn't go into details until my terminal is released. :) DavidTiberio SUNYStonyBrook2-3605 AMIGA TotalProductions DDDMEN
jprad@faatcrl.UUCP (Jack Radigan) (02/09/91)
guineau@wjg.enet.dec.com (W. John Guineau) writes: >Also, Why does JRCOMM not provide a proper terminal identification string >as a result of SET TERM/INQUIRE on VMS? I get "unrecognized terminal type" >and have to type SET TERM/DEV=VT100 manually. I have VT100 selected in the >setup menu. This is JRCOMM V1.01 I'm sending the standard terminal response string as per a DEC VT-340 manual, namely: VT-100: <ESC>[?1;2c VT-102: <ESC>[?6c -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/09/91)
231b3678@fergvax.unl.edu (Phil Dietz) writes: >1) Have a TURBO ascii send mode where it will not print the message you > are sending OR the messages sent from the machine you are sending it > to, until the transfer is done. The only time text on the screen > will show is when the transfer is complete. (Maybe have a little > ascii transfer upload status menu like Zmodem does) > REASON: at a direct connect 19.2k > connection, uploading ASCII files (uue's) results in trashed files > a lot. The buffer seems to be getting in the way and crapping the > transfer out (like it doesn't pick up the EOLN or something which > results like: It's not the buffer "getting in the way", it's most likely the fault of the remote system's editor or whatever than can't handle the speed of the ASCII send as it is already. Try using some character pacing or prompted sends and I'd bet that it works fine. Either that, or you've got some kind of flow control problem. >3) Don't even think about stripping out your ZMODEM routines to replace > it with XPRZmodem! XPRZmodem wreaks a big one! Your zmodem > implementation is SO good, you should call it JRZmodem instead > of JRComm! You got that right! >4) Think about adding Chuck Forsberg's new Zmodem compression algorithms. > They just added it to UNIX rz/sz and MSDOS in the last month or two. Can't. I already inquired about adding ZMODEM-90 extensions. It seems Chuck's gone off the deep end with his licensing policy of $80 per copy sold. $80 for about 3-5% increase in performance, jeez... >5) Have a FOLLOW mouse option. Clicking on a spot will send the > appropriate cursor ups/lefts to get there! Also allow changing of > cursor ups etc. to hjkl's for VI and EMACS! This would be a > SMOOTH option! Not so sure about this one, too much room for errors if the remote system can't handle the possibly huge amounts of ANSI sequences this could generate. Besides, most editors have macro sequences that can get you there quicker than the one-arrow-sequence multiplied by how far it has to travel. Can you imagine the delay it could take at 1200 or 2400bps from when you clicked on the target location to when the cursor gets there? I'll end up getting flamed for that one too... <sigh> -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/09/91)
dbuchtal@math.lsa.umich.edu (Dave Buchthal) writes: >and discarded it immediately. Why? When I use VLT, the feature I >get the most mileage out of is the on-screen review window. I can >leave it open while I work, use it to snap text from, etc. It is >absolutely necessary for me, now that I have grown used to it. God save us all if you write software reviews... Please enable the "Split review" option in the general parameters requester and you'll get what you want. It's been there since 1.0... -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/09/91)
peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >No, I believe he doesn't talk about keymaps. You see, as most of >this datacomm is with UNIX boxes, with only 7-bit ASCII or umlauts >on different ASCII codes (err, it's enough to say PC instead of UNIX), >and all that crap, there is a workaround: Um, gotcha. But, this still can be accomplished via a customized keymap that outputs a KCF_STRING instead of the 8 bit character for these cases. I'd have to add string output support, but that's trivial and will be there for 1.02. -jack-
dfrancis@tronsbox.xei.com (Dennis Heffernan) (02/10/91)
In article <957@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: |dbuchtal@math.lsa.umich.edu (Dave Buchthal) writes: | |>and discarded it immediately. Why? When I use VLT, the feature I |>get the most mileage out of is the on-screen review window. I can |>leave it open while I work, use it to snap text from, etc. It is |>absolutely necessary for me, now that I have grown used to it. | | God save us all if you write software reviews... | | Please enable the "Split review" option in the general parameters requester |and you'll get what you want. It's been there since 1.0... | | -jack- The split screen buffer in JRComm is not the same, and not as good as, the Review Window in VLT. Since VLT puts the buffer in its own window, I can have it open at the same time I'm using a full-screen editor. I can't do that in JRComm. Also, VLT's Review Window lets you save selected text to a file, or to the clipboard (useful when using QED instead of some crummy BBS editor- I don't need to use Snap to clip text from one to the other!), and has search functions, and is ARexx compatable... It's a lot more useful than JRComm's. dfrancis@tronsbox.xei.com ...uunet!tronsbox!dfrancis GEnie: D.HEFFERNAN1 ------------------------------------------------------------------------------ "We've got rules here- can't have senseless violence on the battlefield!" -- Evan Davis
vic@wookumz.ai.mit.edu (Vic Rattlehead) (02/10/91)
Since everyone is posting their wish lists for JRcomm, I decided to add a few of my own. 1) How about support for uw? Right now, I use meshugena becuse it supports this and has very good emulation. Unfortunately, it supports no file transfer or macros or scripts or anything. 2) How about improved vt100 emulation. (Try using VM/CMS, IRC, less, or emacs if you think this implementation is complete.) 3) How about making it live happily with other programs. LaceWB gurus, Mach II's clock when popped to the jrcomm screen gurus. 4) File requesters that don't "lock up" on io errors and get stuck on the screen would be nice.. Admittedly, I've only tried v1.01 a few times at a friend's,it seemed worse. We couldn't get vt102 to stop flashing everything on the screen, if you would hold the cursor keys down, the cursor wouldn't move until you release the key (The cursor would move, but the sprite wouldn't follow), and of course it still crashes taking the entire system with it.. -Vic
amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) (02/10/91)
In article <956@faatcrl.UUCP>, Jack Radigan writes: > 231b3678@fergvax.unl.edu (Phil Dietz) writes: > > >5) Have a FOLLOW mouse option. Clicking on a spot will send the > > appropriate cursor ups/lefts to get there! Also allow changing of > > cursor ups etc. to hjkl's for VI and EMACS! This would be a > > SMOOTH option! > > Not so sure about this one, too much room for errors if the remote system > can't handle the possibly huge amounts of ANSI sequences this could > generate. If the remote system cannot handle this, it's not your (JRcomm's) fault. But I don't remember any system (BBS, UNIX etc.) not managing it, pressing the cursor keys continuously down until the cursor is positioned well. A 'Follow-Mouse-Option' would do the same - but automagically :-) It would be a real good feature ! (I use it in VLT very often) > than the one-arrow-sequence multiplied by how far it has to travel. Can you > imagine the delay it could take at 1200 or 2400bps from when you clicked on > the target location to when the cursor gets there? That's no reason to restrict users with higher bps rates. Nobody *must* use it. But if someone will, he can :-) Please, try to implement it! Bye, Andreas -- Andreas M. Kirchwitz, Seesener Str. 69, D-1000 Berlin 31, FRG, +49 30 873376 / __ Domain: amk@zikzak.in-berlin.de, IRC-Nick: 'bonzo' /___(oo)_________________________________ Bang: ...!unido!fub!unlisys!zikzak!amk " " "Ich liebe es, wenn ein Plan funktioniert." -- Hannibal (A-Team)
jprad@faatcrl.UUCP (Jack Radigan) (02/12/91)
vic@wookumz.ai.mit.edu (Vic Rattlehead) writes: >1) How about support for uw? Right now, I use meshugena becuse it >supports this and has very good emulation. Unfortunately, it supports >no file transfer or macros or scripts or anything. >2) How about improved vt100 emulation. (Try using VM/CMS, IRC, less, >or emacs if you think this implementation is complete.) While there may certainly be a few incompatibilities or bugs in the VT-10x emulations that remain unknown to me, they are going to still exist if I'm not given sufficient info on what is not working correctly. I can vouch for the implementation of GNU Emacs on this system here, I'm using it to enter this post, BTW. As for the other stuff, I've got no access to one of those systems or knowledge of the applications themselves, so there's little that I can do for that. If you can take the time to capture the offending ANSI sequences I'd be more than happy to take a look and attempt to repair them for the next version. There were a couple of fixes to the VT-10x emulations for 1.02 which is close to release, but nothing that comes close to making them completely unusable. >3) How about making it live happily with other programs. LaceWB gurus, >Mach II's clock when popped to the jrcomm screen gurus. LaceWB? haven't tried it. Mach II? Too much of a memory hog and it blanks all sprites, not just the pointer sprite like Qmouse does, which isn't a cpu hog either. >4) File requesters that don't "lock up" on io errors and get stuck on the >screen would be nice.. Fixed. >Admittedly, I've only tried v1.01 a few times at a friend's,it seemed >worse. We couldn't get vt102 to stop flashing everything on the >screen, if you would hold the cursor keys down, the cursor wouldn't >move until you release the key (The cursor would move, but the sprite >wouldn't follow), and of course it still crashes taking the entire >system with it.. The flashing is due to not having the vtxx.fonts installed. As for the cursor, I've not had this problem, just tried it here to be sure... -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/12/91)
WGLP09@SLACVM.SLAC.STANFORD.EDU writes: > VLT frees up an Xoffed serial device just fine... Has for as long >as I can remember. Lurking, eh? ;-) Ok, I stand corrected. VLT & JR-Comm are the only ones that free up an XOFF'd serial.device... -jack-
dave@cs.arizona.edu (Dave P. Schaumann) (02/12/91)
In article <971@faatcrl.UUCP> jprad@faatcrl.UUCP (Jack Radigan) writes: >vic@wookumz.ai.mit.edu (Vic Rattlehead) writes: >[...] >>3) How about making it live happily with other programs. LaceWB gurus, >>Mach II's clock when popped to the jrcomm screen gurus. > > LaceWB? haven't tried it. Mach II? Too much of a memory hog and it >blanks all sprites, not just the pointer sprite like Qmouse does, which >isn't a cpu hog either. I have been told that LaceWB exits in a "hanging forbid" mode, which apparently can (& does!) cause the system to guru at a later date. No fault of JR-Comm. -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) (02/13/91)
Ferry van het Groenewoud asked me to forward this message to the net (it was sent to me by mistake). From uunet!mcsun!fwi.uva.nl!groenewo... A little contribution on my side to keep Jack busy... An option to send an arbritary char (for example return) for every arbritary amount of time (for example every 5 minutes). That would prevent a BBS from timing out. The windows that show info while down or uploading are pretty complete, however one more number (I know this will sound like a spoiled child talking) would be nice: how high the *actual* transfer speed is. Then you would be able to see how much the speed drops down at a given moment if the line sucks. Also you'd see the maximum speed if the transfer is going perfectly. Also a very nice thing would be a search option in the review buffer. Many times it happens that I wanna review something and find myself swimming around 48K of text trying to find what I need. I'm not talking about grep-like functions. A plain, simple search option with modest wildcards options would suffice for me. Why are things measured with different measures? I don't see a reason to display the review buffer size in units of 2K! It is a little problem to multiply the number by 2. I only find it annoying that such a good program has such strange things. It would also be very nice if you could speed the scrolling somewhat. Would be nice for the review buffer and probably neccesary to keep up with high speed modems. I don't know how they do it, but take a look at the Cygnus editor among others. I guess they use the blitter to scroll but that is up to the programmer to find out :^) Very luxury, and not really necessary, but very nice would be a window in which you can adjust some Hayes compatible modem parameters. How about a small slider for modem volume? Would be extremely helpful for starters that don't know all AT... codes of heart like me. It would be userfriendly, it would be... amiga! Also handy would be a way to dial a number without having to touch the mouse. Just for speed's sake. Again this is a luxury thing, but I think it is handy. I start JR-Comm from floppy and it takes him about two minutes to get ready. That is because I also load the RAD: disc considerable with some DOS commands. I don't wait for the amiga until it has finished it's work, I start doing other things in the mean time. When I come back, JR-Comm will be there up and running. However, with scripts implemented, I (think I) could let JR-Comm connect too. But I *don't* want to let it type in my password because that requires that it needs my password on disc. To that I'm very reluctant. Some solutions to this little inconvienience (sp?) are: being happy that JR-Comm manages to get to the 'Password:' prompt; 2. Be able to type the password in JR-Comm in the very beginning of the startup. JR-Comm could crypt it itself and see if the password is correct. Then it could start the whole thing up, and I wouldn't have to interact with the computer until it has done all it could. I could even let it download my mail automatically. The ideal situation would be that you switch the computer on, walk away and come back in ten minutes and find that you're mail has been downloaded. That requires your password on disk, which I don't want. The next best thing would be: switch on your computer, type in your password, walk away etc. An option to have audible/visible beep. Some sort of display reset. Many times I find myself selecting the terminal requester, press the button for 8 colors, press the button for 4 colors and exit again, just to get back my normal type of display of the letters. In version 1.0 the VT100 emulation isn't 100%, which causes some of this, you've fixed that. But I think it would be handy, for sometimes it happens that the text is bold or it displays strange chars. There are probably control chars (like CTRL-O I believe) to get rid of it, but not many people know this. That's all I could come up with. I think at least some of the points I make, make sense. Ferry. -- -- Mac. The noise of a wrong calibration. PS/2. You can't see the new thing. IBM. The toys of a dead generation. Sun. You can't feel the beating. NeXT. The choice cause of bad information. Atari. You'll need some healing. Amiga. For boys with real imagination. Amiga. You can reach the ceiling. Ferry van het Groenewoud groenewo@fwi.uva.nl -- Chris (Insert phrase here) Seaman | /|__|\__/|__|\ cseaman@gateway.sequent.com <or> | | | Where does he get ...!uunet!sequent!cseaman | | /\/\ /\/\ | those Wonderful toys? The Home of the Killer Smiley | \| \/ |/
n350bq@tamuts.tamu.edu (Duane Fields) (02/13/91)
What is the prospective release date of 1.1? Where do we send the money, ($30?) and is a check or money or better or does it matter??? Duane | Duane Fields | Friends don't | President, aTmiga club | | Box 1315 | let friends use | Fone# (409) 847-6760 | | College Station, Tx 77841 | MS-DOS. | n350bq@tamuts.tamu.edu |
jprad@faatcrl.UUCP (Jack Radigan) (02/14/91)
cseaman@sequent.UUCP (Chris "The Bartman" Seaman) writes: >The windows that show info while down or uploading are pretty >complete, however one more number (I know this will sound >like a spoiled child talking) would be nice: how high the >*actual* transfer speed is. Then you would be able to see >how much the speed drops down at a given moment if the line >sucks. Also you'd see the maximum speed if the transfer is >going perfectly. The *acutal* throughput figure is shown, instantaneous speeds or peak speeds are not really that useful and would need a bit of fudging due to the double buffering and other things. Besides, I'd rather have the cpu handling data rather than computing every superfluous statistic just for the sake of it. >Also a very nice thing would be a search option in the review >buffer. Many times it happens that I wanna review something >and find myself swimming around 48K of text trying to find >what I need. I'm not talking about grep-like functions. A >plain, simple search option with modest wildcards options >would suffice for me. Yeah, a simple, unanchored Boyer-Moore search is doable, no grep though. >It would also be very nice if you could speed the >scrolling somewhat. Would be nice for the review >buffer and probably neccesary to keep up with high >speed modems. I don't know how they do it, but >take a look at the Cygnus editor among others. >I guess they use the blitter to scroll but that is >up to the programmer to find out :^) A 2 or 4 color screen works pretty nicely as it is, but I do plan to work on that somemore for the future. >An option to have audible/visible beep. Already in there. -jack-