response 1 of 40:

Jan 8 22:27 UTC 1994

I just tried it, and it works.  Thanks.

response 3 of 40:

Jan 30 01:16 UTC 1994

Isn't there an item somewhere for editor comparison, and flame-bait like #2?

response 5 of 40:

Oct 13 06:55 UTC 1994

Hmmm.  I'm having a pico problem now.


I recently upgraded my terminal program (Term for the Amiga) to version 4.1
Since doing this I have noticed that when logging on to Grex directly I get
gobldy-gook in my lookback and capture buffers when I use 8-N-1 with the 8th
bit stripped.  This always used to work well for me.  I tried using 7-E-1
and that fixed the buffer problem, but when I do that, pico (the only editor
I'm willing to use) doesn't work.  Instead of drawing the screen it just spits
char oops...characters at me.  Yuck.  No matter which settings I use my primary
terminal screen works fine for most things.  It is only the buffers that get
messed up with 8-N-1-Stripped.  Anyone got any idea what's going on?  I realize
that it's a 7/8  bit translation thing, but what do I do about it?

I just tried pine and that works fine at 7-E-1.  That doesnt make sense... I
thought that pico was the same as pine's editor... Why does one work and not
the other??

Any thoughts on what I should do (not change editors) would be appreciated!

Thanks

A.J.

response 7 of 40:

Oct 15 01:06 UTC 1994

Hmm....
Space parity doesn't work.  It makes a terible mess of things!  Right now,
though, I'm trying 7-N-1 (who ever heard of that?!) and it seems to be working.
I just ran pico a minute ago and it drew the screen fine.  I guess I'll try 
this for a while and see if I can come across any problems, or if this is a 
goot (albiet) unexplainable solution.

response 9 of 40:

Oct 15 06:14 UTC 1994

Are you using vt102 emulation in the upgrade, as specified in your .profile?

response 11 of 40:

Oct 15 19:21 UTC 1994

It is indeed. <sigh>

response 13 of 40:

Oct 16 22:10 UTC 1994

I don't think so, Valerie.  On *input*, yes, though, which is one of the
things that's so baffling.  But on output (as seen from the terminal, I
mean, since that's what's being set) it should always zero the parity bit,
whereas 7N implies that the state of the bit is of no interest & it may
be left either 0 or 1.

That is, the difference between 7N1 & 7S1 explains nicely why (maybe)
the cursor keys don't work with 7N1 - maybe, but not for sure - but
the screen should definitely work the same.

response 15 of 40:

Oct 17 04:29 UTC 1994

Actually Valerie the one that I'm using is considered by most Amiga users to
be the best pd/shareware term available for the platform.  It is a very very
capable package, but it is so complex in scope that there seem to be
interesting" features " in every new release.  V4.1 is the first one that has
given me this  trouble, but it fixes some other annoying bugs in earlier
versions.  So far Grex is the only place where Ive had this happen.  I suspect
that my buffer problem is a new bug that causes the 8th bit stripping feature
to affect only the  screen display, and not the buffers.  I think I may write
the author about  that one, however, the failure of pico to work with my 7-E-1
setting may be something coming from grex and not from my terminal.  After all,
pico works just  fine when called through pine, just not by itself.  Also I
beleive I've seen pico  working just fine for me on other systems.  (I'll check
next I am on one of the oth systems).

response 17 of 40:

Oct 17 10:16 UTC 1994

Neither - pine has its own pico, in that pico is one module of pine,
extracted & separately compiled.  But we definitely had different revs at
one point, & pico gave trouble - but some of the things that have been
tried should have been sufficient to avoid *those* troubles.

He says he's choosing vt220 on login & that it shows as correct in his
environment, so the .profile is not the issue.

cicero, I hope you'll let us know what's going on when (& if) you do trace
it down.  This is pretty weird, & I'd like to know.

response 19 of 40:

Oct 18 06:58 UTC 1994

well I just tried it over on M-net.  They have pico V2 and also 1.7
like us.  It worked fine.  What I forgot was that unlike us, 
M-net is 8-N-0 so that really doesnt prove anything.  I'll see if
there's somewhere else we can test.

response 23 of 40:

Nov 7 18:32 UTC 1994

re 21: stty rows and stty cols do indeedwork for most purposes, and I've 
been using them for  some time.  Problem is, when telnetting out aof an 
xterm, I can have a screen size of whatever I want, and my default is
80x25, not 80x24 (and when I telnet from other places, I need 80x24, of
course).  My previous solution included using a vaguely complicated shell
expression to test whether $TERM was set properly, and didn't work.
Fortunately, for fully vt100 compatible terms, there's a better solution: 
set `resize` or something like that.
Unfortunately, while this works nicely in highter versions of Sunos, I can't
find it here, so I'll hve to make do.