🚀 go-pugleaf

I don't know if DataStorm is on the net, but they claim to have a
Procomm Support BBS at (314)449-9401.

Bill Frolik
hp-pcd!bill
Hewlett-Packard Portable Computer Division
Corvallis, Oregon

In article <376@vu-vlsi.UUCP>, colin@vu-vlsi.UUCP (Colin Kelley) writes:
> I've just downloaded Procomm 2.4, and was happy to see that BS/DEL swap is now
> supported.  However, Procomm still has at least one minor bug in its vt100
> emulation:  when a character is printed in column 80, Procomm advances the
> cursor to column 1 of the next line.  True vt100s just internally note that the
> cursor should be there, but leave it in column 80.  If another character comes
> in, it is printed _as if_ the cursor had been advanced to column 1, provided
> the vt100 itself is set to do line wraps.  This allows vi to work regardless
> of the am (automatic margin) setting in the termcap...
> 
> Also, when is Procomm going to allow the keypad to be used as a keypad?  I've
> seen at least one emulator (PC/InterComm by Mark of the Unicorn) which handles
> ...
> 
> 			-Colin Kelley ..{cbmvax,pyrnj,psuvax1}!vu-vlsi!colin



I have similar feelings about procomm (2.3 and 2.4). It is a file job
for file transfers but its vt100 is absolutely USELESS. The key pad stuff
does not follow the physical locations that we are all used to.
Besides the 80 column end problem, procomm does not respond properly to
many of the ansii sequences for screen attributes and positioning and is
useless with emacs on a unix machine.

Phil Kaufman
Silicon Compilers Inc.

In article <376@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>I've just downloaded Procomm 2.4, and was happy to see that BS/DEL swap is now
>supported.  However, Procomm still has at least one minor bug in its vt100
>emulation:  when a character is printed in column 80, Procomm advances the
>cursor to column 1 of the next line.  
>
>Also, when is Procomm going to allow the keypad to be used as a keypad?  

Version 2.4.1 has just been released... fixes both the above.

-- 
             ====================================================  
             |    Fortiter in re,       ||     Bill Fischer     |
             |       suaviter in modo.  ||    wmf@chinet.UUCP   |
             ==================================================== 

In article <376@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>I've just downloaded Procomm 2.4, and was happy to see that BS/DEL swap is now
>supported.  However, Procomm still has at least one minor bug in its vt100
>emulation:  when a character is printed in column 80, Procomm advances the
>cursor to column 1 of the next line.  True vt100s just internally note that the
>cursor should be there, but leave it in column 80.  If another character comes
>in, it is printed _as if_ the cursor had been advanced to column 1, provided
>the vt100 itself is set to do line wraps.  This allows vi to work regardless
>of the am (automatic margin) setting in the termcap...

This is also a pain when reading the news.

>                                    ....  My problem with the Procomm way
>of mapping the keypad is that it is backwards.  It attempts to map the function
>keys into a layout physically similar to the vt100 keypad.  However, when I
>need to use the keypad, I am familiar with the key names, not their position.
>I know for instance that I want PF1 7 for the Command: prompt in EDT.  Procomm
>then forces me to figure out that the 7 is in row 2 column 1, which would map
>to PF3 (right?).  Anyway, it's tough to use...
>

What I would really like to see, is more programs going the way MS Kermit
has for key mapings.  You can go with the standard, OR, compleately redefine
every key on the keyboard if you want.  Now I don't do this, but it does
let me do some neat things with the keyboard when I use the IBM 7171 protocol
converters (ASCII-3270), which think I am useing a VT100, when I actually
have the function keys layed out on the function keys (god forbid), and 
all those "extra" keypad keys get used for "3270" functions (like clear
screen, etc).  Then I can also use delete to be a 3270 delete, the appropriate
arrow key to be the "backspace" (3270s don't really have a backspace, they
use an arrow key for it), AND use the backspace as my nice familiar destructive
backspace.  The only package I have used that has come close to this was the
PIBTERM package which I got here a few days ago.  I like this package, but
it didn't let me redefine the Keypad Minus, or the Backspace, both of which
I have alternate definitions for.

   By the way, for the person who posted PIBTERM, I lost your address,
so I can't send you to ask for the source (which you so nicely offered),
so I will have to request it here.  Thanks, it looks great.

                      S. John Banner

UUCP:     ...!uw-beaver!uvicctr!sbanner1
BITNET:   ccsjb@uvvm
EAN:      sbanner1@uvunix.uvic.cdn