Trailing-Edge - PDP-10 Archives - steco_19840320_1er_E35 - 10,5676/teco/bugs.mai
There is 1 other file named bugs.mai in the archive. Click here to see a list.
30-Jul-82 10:12:48,764;000000000005
Date: 30-Jul-82 10:12:48
From: DPM at KL1026
To: Tamburri at KL1026
cc: Tarl at KL1026
Subject: STECO
Message-ID: <"MS10(2064)+GLXLIB0(273)" 11843777476.17.46.107561 at KL1026>

Here's a cute one.  Apparently, control-C trapping is not done
when you type EVOFF, but it continues to do auto-buffer stuff.
It is possible to type ^C REENTER while you're in the middle of
the auto-buffer code leaving you editing a different Q-register
and the state of things in a real mess.  Since you're not in
video mode, you don't see what happened 'till searches start

Perhaps, EVOFF should do an implicite 0U(AUTO-COUNT)?  Better
still, control-C trapping should be done if you're in video
mode OR doing auto-buffer things.

30-Aug-82  9:26:21,534;000000000005
Date: 30-Aug-82  9:26:21
From: Spider <Spider at KL1026>
To: Tamburri at KL1026
Reply-to: Spider at KL1026
DTN: 231-7171
LOC: MRO1-2/S43 Pole M2
Subject: Re: Gripes
Message-ID: <"MS10(2070)+GLXLIB1(1130)" 11851895485.46.2987.2990 at KL1026>
Regarding: Message from Tamburri at KL1026 of 30-Aug-82  8:54:50
In-reply-to: <"MS10(2070)+GLXLIB1(1130)" 11851889742.26.3006.7620 at KL1026>

FI command prompting with evmode on and running on a vt100 prints garbage
instead of positioning and typing out the prompt.
15-Oct-82  8:44:13,686;000000000005
Date: 15-Oct-82  8:44:13
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO
Message-ID: <"MS10(2117)+GLXLIB1(1133)" 11863946439.23.46.233678 at KL1026>

Another bug I forgot to mention:

If you ER a file and type EX$$, STECO correctly tells you
that there's no file for output.  It also turns off viedo
mode.  Typing EVON$$ puts you back in video mode, but you
have to explicitely type ^L to get the text displayed. In
addition, the filespec info in the mode line is lost.

You can also cause this to happen if you run STECO with
viedo mode turned off, do some editing, and then EI an INI
file that does an EVON and sets up a mode line.

26-Oct-82  3:17:07,369;000000000005
Date: 26-Oct-82  3:17:08
From: Tarl at KL1026
To: Tamburri at KL1026, Grossman at KL1026, Wachs at KL1026
Subject: TECELS
Message-ID: <"MS10(2117)+GLXLIB1(1133)" 11866770480.17.2909.83868 at KL1026>

?TECELS Extension is longer than six characters MACA

Well,.... the error message could use a bit of improvement.
29-Nov-82  8:52:58,558;000000000015
Date: 29-Nov-82  8:52:58
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO bug
Message-ID: <"MS10(2117)+GLXLIB1(1133)" 11875744511.19.46.143559 at KL1026>

Problems with ^EL searches.

I wrote the following macro to count the number of lines in
the buffer.  It loops forever when it reaches the end of the
buffer and continues to execute the % command following the
semi-colon.  DEC TECO correctly stops at end of buffer.

	BJ U0U <S^EL$; %0>

It works if you substitute <12> for the L in the search string.

29-Nov-82  9:12:10,1423;000000000005
Date: 29-Nov-82  9:12:10
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO bug
Message-ID: <"MS10(2117)+GLXLIB1(1133)" 11875748007.19.46.185618 at KL1026>

It's a known fact that the mode a file is written in has very
little meaning on TOPS-10.  For example, a program may write
a file in DUMP mode, then rename it to ASCII mode.  FORTRAN
does this quite often.  Programs like NFT and SPROUT take the
mode from the RIB (via an extended LOOKUP) and based on the value
of the mode, interpret the contents of the file differently.
Therefore, the mode is a quantity that allows **cooperating**
programs or jobs to interpret the data stored within a file.
CUSPs that indescrimitely change the mode are uncooperative.

It would be highly desirable, if STECO would preserve the mode
of the file, regardless of how the file was edited.  It was my
understanding that the switches /MODE, /IMODE, and /OMODE merely
specify how the file is to be processed by STECO, and say
nothing about the data contained withing the file.

Editors should preserve all information stored in the RIB with
the exception of the file sizes (both allocated and used),
unless the user explicitely askes to have some file attributes
changed (like version).  Since STECO lacks a switch that would
allow the user to explicitely set the mode (e.g. /IOMODE:17),
this quantity shouldn't be modified.

30-Nov-82  5:06:53,567;000000000005
Date: 30-Nov-82  5:06:54
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO bug
Message-ID: <"MS10(2117)+GLXLIB1(1133)" 11875965503.26.46.104271 at KL1026>

The following macro works correctly with DEC TECO and
DTECO (both ASCII and DUMP modes), but fails with STECO
in DUMP mode.  It searches the buffer looking for lines
with IFNDEF and writes those lines out to a file.

	<_IFNDEF$; 0L .U1 L Q1,.P$>
	HK$ EX$$

Appending a /MODE:DUMP switch to the filespecs works.

 7-Jan-83 10:28:20,513;000000000005
Date:  7-Jan-83 10:28:20
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO bug
Message-ID: <"MS10(2123)+GLXLIB1(1133)" 11885985488.21.46.18319 at KL1026>

If I put my terminal in 132 column mode and set the TTY width to 132
and edit a file whose lines are longer than 80 characters, STECO
wraps the line around at 80.  It should beleive the TTY width setting
instead of it's own internal values.  For that matter, it probably
should respect the TTY LENGTH setting too.

 7-Jan-83 10:35:35,618;000000000005
Date:  7-Jan-83 10:35:36
From: DPM at KL1026
To: Tamburri at KL1026
Subject: STECO bug
Message-ID: <"MS10(2123)+GLXLIB1(1133)" 11885986812.21.46.25763 at KL1026>

If you do not hav a TECO.INI file and you do the following:


Then when in DPY mode, type ^Z, STECO dumps a large decimal number
on the screen followed by ";H".  Other type-in caused this too but
I don't remember what else I typed.  It's quite reproducable.  Looks
like they dropped the <ESCAPE>[ mumble stuff somewhere along the

26-Jan-83 18:56:27,454;000000000005
Date: 26-Jan-83 18:56:28
From: Phil Budne <Budne at KL1026>
To: Tamburri at KL1026
cc: Grossman at KL1026
Subject: STECO bug
Message-ID: <"MS10(2124)+GLXLIB1(1133)" 11891058726.25.3034.56163 at KL1026>

This gives a bad diagnostic with the STECO on STD:

E.(FOO)$$ M(FOO)$$ It complains that you are trying to execute an
'internal' display only q-reg.  The E? q-dir function does not
tell you what are 'internal' also...

10-Feb-83  7:35:36,860;000000000005
Date: 10-Feb-83  7:35:37
From: DPM at KL1026
To: Tamburri at KL1026, Houk at KL1026
Subject: TECO bug
Message-ID: <"MS10(2124)+GLXLIB1(1133)" 11894866944.25.46.37321 at KL1026>

All flavors of TECO except for good 'ole standard TECO have the
following bug:  In an iterative loop used to count the number of
lines in the buffer, a search for ay EOL character never fails.

	0U0$ <S^EL$; %0$>$$

DTECO and STECO will loop forever.  Changing the ^EL to ^E<012>
makes it work correctly.  Standard TECO does break out of the
loop as it should, but repositions . to the begining of the
buffer.  This might be normal on "un-coloned" search failures,
though it's been so long since I've used that TECO, I'm not
sure.  According to the TECO manual, end of buffer is supposed
to satisfy the ^EL search condition.

22-Feb-83  8:42:17,472;000000000015
Date: 22-Feb-83  8:42:17
From: TW <Wachs at KL1026>
To: Tamburri at KL1026
Reply-to: Wachs at KL1026
DTN: 8-231-6455
Subject: STECO
Message-ID: <"MS10(2107)+GLXLIB1(1133)" 11898024805.11.8.6007 at KL1026>

I keep a journal file which I can play back if the system crashes
in the middle of an edit.
1 problem is that if I have started an insert with <tab>text, rather
than I<tab>TEXT; when I play it back I get TEXT without the preceding tab.
19-May-83 11:34:41,363;000000000005
Date: 19-May-83 11:34:42
From: Phil Budne <Budne at KL1026>
To: Grossman at KL1026, Tamburri at KL1026
Subject: NTECO
Message-ID: <"MS10(2124)+GLXLIB1(1133)" 11920600576.30.3034.6435 at KL1026>

If you are not in video mode, and you use <LF> NTECO screws
up by leaving the cursor on the line it just displayed, not
the one with the *.