cem@intelca.UUCP (Chuck McManis) (08/22/84)
This is a problem I have been experiencing with vnews that I need clarified.
On my system, a Xenix 286 system, vnews CANNOT handle lines of more than
80 characters. It seems whenever a line is longer than 80 characters some of
it and the next 1 or several lines are gobbled up! This also seems to be a
generic fault of postnews which also does wierd things with long lines. Is
this vnews ? my termcap entry? or what? does anyone else have this problem?
As an example I will try to send a line longer than 80 characters. frinstance
This is a very long line, it will exceed 80 characters by at least 10 additional characters.
This line is probably garbled.
There should be a line below the long line that says it is probably
garbled. Any clues ?
--
-- Chuck - - - D I S C L A I M E R - - -
{ihnp4,fortune}!Dual\ All opinions expressed herein are my
{proper,idi}-> !intelca!cem own and not those of my employer, my
{ucbvax,hao}!hplabs/ friends, or my avocado plant. :-}
ARPAnet : "hplabs!intelca!cem"@Berkeleycem@intelca.UUCP (Chuck McManis) (08/24/84)
[Whimper, Whimper]
I have discovered that which maybe should have been obvious. The problem
I mentioned on venws failing to deal with lines > 80 cols stems from the
fact that my terminal was set NOT to AUTOMATICALLY generate CR/LF when a
character was written in column 80. Therefore long lines would type all
of the additional characters one on top of the other until the end of the
line. The not so clear problem is that after doing this, vnews seems to
assume your terminal has generated the CR/LF, and types the next line without
sending CR/LF first. Therefore, sometimes the second line is also destroyed.
My terminal is/was set this way because some full screen editors, notably
EMACs can sometimes write characters in column 80 of line 24 and NOT expect
the screen to scroll. So I have some Inconsistencies to clear up. It may
have some thing to do with vnews' screen update algorithim or something (ie
forcing CR/LFs before lines) and why does vnews sometimes leave junk on the
screen. Argh! So much to do and so little time to do it.
--
-- Chuck - - - D I S C L A I M E R - - -
{ihnp4,fortune}!Dual\ All opinions expressed herein are my
{proper,idi}-> !intelca!cem own and not those of my employer, my
{ucbvax,hao}!hplabs/ friends, or my avocado plant. :-}
ARPAnet : "hplabs!intelca!cem"@Berkeleychris@umcp-cs.UUCP (08/28/84)
If your terminal *does* do auto-wrap, you should have ":am:" in your
termcap. If it doesn't auto-wrap, you should not have that in there.
If you have the ``eats newline'' glitch/feature (where after writing in
the last column the cursor stays there and if it gets a newline goes to
the beginning of the next line, or if it gets a char it also goes to
the beginning of the next line (then prints the char)) then you should
have ":am:" and ":xn:".
(Then there are pathological terminals where the auto-wrap is set
either by a switch or at random on power on, but can't be interrogated
or changed from software... lots of fun.)
If your termcap has this and Emacs still misbehaves, you have a broken
Emacs. (Mine sets tt.t_width = tgetnum("co")-tgetflag("am"), which
works, though it can be annoying to lose that last column.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland