response 76 of 227:

Jan 13 18:15 UTC 2000

  It probably doesn't like you. ;)

  I know that's not then answer you're looking for, but it IS an answer.

response 78 of 227:

Jan 14 08:57 UTC 2000

pine is a memory pig.  your better off using elm.

response 80 of 227:

Jan 14 15:17 UTC 2000

        It probably is a dirty line.  It's difficult with most commercial
modems to tell whether you're on one or not - but connecting to an ISP with
PPP should give you a count of errors which might help to troubleshoot the
problem.

response 82 of 227:

Jan 14 17:24 UTC 2000

        I'm guessing that it's "only pine out of the programs that I use here",
and that it's probably related to munging one of the VT100 control sequences.

response 84 of 227:

Jan 15 01:42 UTC 2000

whatever it is keesan, it isn't a grex system problem.  if it were, there
would be a lot more of us having similar difficulties.

having read your posts, my suspicion is that you have either a significant
line noise problem local to you, or have reconfigured something either with
your account or with your computer/s, or all of the above.  you strike me as
a tinkerer, much like myself, who will change things to see what the changes
do, but you may have forgotten a change you made or changed something without
realizing it...

(just my take)

response 86 of 227:

Jan 15 05:15 UTC 2000

Re: some long-ago discussion of Party doing weird things with the first
character you type.

Unix terminal devices have two modes:  cbreak and cooked (actually,
there is a mode called "raw" but we won't talk about that).  In cooked
mode, the operating system gathers up the characters of the line you
type, handling any backspaces and control-W's and so forth.  When you
hit enter at the end of the line, then the whole finished line is passed
to the program.  This "cooked" mode is used by most programs you use on
Grex.  In cbreak (or character-break) mode, each character is passed to
the program as it is typed.  No backspace processing is done by the
operating system.  This is used by programs like "vi" or "nethack" where
an 'h' key might mean "move the cursor" or "hit the monster", and needs
to be processed by the program immediately without waiting till you hit
enter.

Party is slightly weird.  The first character that you type on a line is
magic.  In nofirstchar mode, hitting space brings up the > prompt.  In
firstchar mode, any letter brings up the > prompt and also echos as the
first character of your response.  But the rest of the characters of the
line are just normal input, and we'd like backspaces and control-W's and
all the rest of the line-editting stuff to work.

So the way party was originally written (when nofirstchar was the only
option) it would start out in cbreak mode till you hit a space.  Then it
would print the "> " prompt, and switch to cooked mode so you can enter
the rest of the line in good order.  This is a weird thing to do.  I
don't think I know of any other program that toggles between cooked and
cbreak mode like this.  It's always been a glitchy thing to do, and has
had different odd effects on different computers.  I think what is
happening in the odd instances described is that you are typing fast
enough, and the system is running slow enough, that you get a few
characters in before the switchover is complete, and things get mungled
up.  I think it is possible that we are exercising a rather subtle
operating system bug here.

This won't happen in firstchar mode because in firstchar mode party
always stays in cbreak mode and never goes to cooked mode.  All the
characters you type are passed one-by-one to the party program without
any processing by the operating system.  To make things like backspace
and control-W work, I implemented a simplified version of the operating
system's input processing function inside of party.  I couldn't do the
mode switch because there was no way to get the first typed character,
the one that popped up the > prompt, into the operating system's input
buffer after my program had already read it in.  This was bad because if
it wasn't in the operating system's input buffer, then the operating
system wouldn't let you backspace it away.  So I had to abandon all hope
of using cooked mode.

I could have (and could still) make party stay in cbreak mode all the
time when doing "firstchar".  It would avoid weird glitches, and most of
the code needed to support this has already been written.  The
disadvantage is that the operating system is much more efficient about
doing line processing than party could be, so we'd add a little bit more
system load.  Probably not enough to worry about, but party was written
in the old days of Grex when every CPU cycle counted.

response 88 of 227:

Jan 15 12:51 UTC 2000

        I figured that party was switching tty modes in between the first
character, though I wasn't sure, and I just thought it was an interesting race
condition.  I'm not kibbitzing, just thought it was interesting.

        Jan's summary was written well enough that I'm sure the 25% of agora
who reads this item on a regular basis will be able to understand it - how
much they take from it probably depends on their background and how useful
it is - but it beats Stephens' explanation.

        Keesan, munged means "mushed until no good".

response 90 of 227:

Jan 15 23:44 UTC 2000

Same account - works on one phone line, does not work on another line on
either of two computers with two different modems.  Jim has been fiddling with
turning off hardware flow control and switching between Procomm, PCPLUS
and Bitcomm and claims all three of the latter do not work.  Do we need
hardware flow control?  Procomm (without it) seems to work at the office.
We have plenty of other modems to experiment with and will do so.

response 92 of 227:

Jan 16 01:40 UTC 2000

From what Sindi says, it sounds too frequent for that to be likely.

response 94 of 227:

Jan 17 04:40 UTC 2000

What was the scoop today?

response 96 of 227:

Jan 17 05:17 UTC 2000

        Thanks for getting 'er back up, guys!

response 98 of 227:

Jan 17 10:27 UTC 2000

Thanks STeve and Steve.