Trailing-Edge
-
PDP-10 Archives
-
mit_emacs_170_teco_1220
-
emacs/teco.bugs
There are no other files named teco.bugs in the archive.
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 May 87 02:44:32 EDT
Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 May 87 02:37:18 EDT
Date: Tue, 26 May 87 02:37:34 EDT
From: "Leigh L. Klotz" <KLOTZ@AI.AI.MIT.EDU>
Subject: reading in TECORD causes FS ^R RPAREN to get set to 0
To: BUG-EMACS@AI.AI.MIT.EDU, KLH@AI.AI.MIT.EDU
cc: BUG-TECO@AI.AI.MIT.EDU
Message-ID: <205171.870526.KLOTZ@AI.AI.MIT.EDU>
There is a known TECO bug where under certain conditions a PDP-10 word
of a buffer gets set to 0. I remember some arbitrary change to one
of the language mode libraries once that exercised this bug; I don't
know that anyone found or fixed it.
I'm mentiioning this to point out that your bug could be something
bizzarre.
Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Apr 87 17:32:43 EST
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 APR 87 16:56:17 EST
Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet with SMTP; 3 Apr 87 16:25-EST
Date: Fri, 3 Apr 1987 16:42 EST
Message-ID: <SRA.12291644904.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Cc: SRA@XX.LCS.MIT.EDU, Bug-TECO@OZ.AI.MIT.EDU
Subject: Twenex mailing list canonicalizer
In-reply-to: Msg of 3 Apr 1987 05:09-EST from "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
Date: Friday, 3 April 1987 05:09-EST
From: "Pandora B. Berman" <CENT@AI.AI.MIT.EDU>
well, it returned almost immediately. all the host names are now bounded by
nulls, but they don't appear to have been fixed -- i have seen a BBNG, an
SCRC, and a CMU-CS-G, and these are not primary names. buffer still in my
emacs on OZ; i could save it out if you want a look. i did pull out of the
supdup to oz in order to do work on ai while waiting; that should not have
affected it, right?
TECO bug. You saw the intermediate form of the file (after TECO was
done grinding it but before CANHST.EXE had run over it). TECO's "E?"
command on OZ behaves differently when run under the debugger so that
it wins under debugger and loses when invoked normally (actually, the
lossage can be triggered using "@MM" in the debug minibuffer instead
of just "MM"). Specificly, the TECO expression
E?SYS:CANHST.EXE$
was returning zero instead of an error code, so my code thought that
the file SYS:CANHST.EXE existed when it really didn't. I bashed the
OZ copy of CANHST.EMACS to just assume that CANHST.EXE lives in MAIL:
without checking, compiled and installed, seems to work ok.
btw, you misspelled canonicalize. canon as in bach rather than cannon as in
weapon.
I means what I sez. Nicknames shall be shot at dawn.
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 APR 86 14:40:40 EST
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 2 APR 86 14:39:22 EST
Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 2 APR 86 14:38:43 EST
Date: Wed, 2 Apr 86 14:39:11 EST
From: "Leigh L. Klotz" <KLOTZ@MC.LCS.MIT.EDU>
Subject: Emacs and TECO sources
To: ALAN@AI.AI.MIT.EDU
cc: BUG-EMACS@AI.AI.MIT.EDU, BUG-TECO@AI.AI.MIT.EDU
In-reply-to: Msg of Sun 30 Mar 86 02:43:35 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].870618.860402.KLOTZ>
Date: Sun, 30 Mar 86 02:43:35 EST
From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
To: BUG-EMACS at AI.AI.MIT.EDU, BUG-TECO at AI.AI.MIT.EDU
Re: Emacs and TECO sources
I just moved the directories .TECO., EMACS, and EMACS1 from MC to AI. I
don't know what status these directories have as the "official" homes of
any source files, but whatever status they have should now be transfered to
to AI.
...
To the best of my knowledge the EMACS1; directory is the only home of
the ITS-specific libraries. DIRED is the only obvious one.
Received: from AI.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 30 MAR 86 02:44:48 EST
Date: Sun, 30 Mar 86 02:43:35 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: Emacs and TECO sources
To: BUG-EMACS@AI.AI.MIT.EDU, BUG-TECO@AI.AI.MIT.EDU
Message-ID: <[AI.AI.MIT.EDU].22474.860330.ALAN>
I just moved the directories .TECO., EMACS, and EMACS1 from MC to AI. I
don't know what status these directories have as the "official" homes of
any source files, but whatever status they have should now be transfered to
to AI.
Reproduced below is the system message I posted to explain the MC to AI
migration procedure:
The source files for everything vital to an ITS, which have been living on
MC, are being moved to AI one directory at a time. Copies are being left
on MC for completeness. When a directory has been copied to AI, the file
MOVED TO AI is added to the MC version of the directory.
Once a directory is copied to AI in this fashion, AI becomes its home.
After that, modifications done to the version on MC may be lost.
If you want to change anything related to ITS or important programs (e.g.
MacLisp, MIDAS) during this transition, look for the file
MOVED TO AI on the MC version of the directory -first-. If that file does
not exist, that directory still lives on MC and changes should be made
there; if the file does exist, make your changes on AI.
Received: from SIMTEL20.ARPA by MC.LCS.MIT.EDU 1 Mar 86 13:44:14 EST
Date: Sat, 1 Mar 1986 11:43 MST
Message-ID: <WANCHO.12187279128.BABYL@SIMTEL20.ARPA>
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To: BUG-TECO@MC.LCS.MIT.EDU
cc: BUG-EMACS@MC.LCS.MIT.EDU, BUG-BABYL@MC.LCS.MIT.EDU
Subject: VT100 TECTRM bug
PROBLEM:
In BABYL and ZBABYL on a VT100 or similar terminal, a "Q" or ^X^Z
leaves the cursor at the top of an uncleared screen instead of the
bottom, as intended.
DIAGNOSIS:
In some versions of TECTRM.MID, somebody got over zealous and "fixed"
VT1INI ("FORCE ANSII [sic] MODE") to include an ORIGIN reset sequence,
"$[?6l". This has the side effect of overriding any previous curpos
sequence and put the cursor at the top of the screen.
CURE:
A "quick fix" is to remove the ORIGIN reset sequence, which is
patchable in TECPUR.EXE. The "correct" (untested) fix would be to
envelope the ORIGIN mode reset with a Save Cursor and Restore Cursor
sequence, resulting in: $<$7$[?6l$8 .
--Frank
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JAN 86 16:07:56 EST
Received: from XX.LCS.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 14 Jan 86 16:05-EST
Date: Tue, 14 Jan 1986 15:54 EST
Message-ID: <SRA.12175244248.BABYL@XX.LCS.MIT.EDU>
From: Rob Austein <SRA@XX.LCS.MIT.EDU>
To: Charles Rich <RICH%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc: bug-emacs%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
bug-teco%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: Enabling
In-reply-to: Msg of 14 Jan 1986 15:42-EST from Charles Rich <RICH%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
You have to do it as a either a VALRET to the EXEC (try
:I*^PT^PC$fsechodisp$ w @^KEnable^JContinue^J$ w ^\) or stuff some
PDP10 assembler code into a buffer and execute it (see the Display
Load Average routine in BBNLIB for an example of this sort of thing).
Doing it directly with RPCAP% and EPCAP% is more general, but
valreting is much easier....
Received: from OZ.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 14 JAN 86 15:43:48 EST
Date: 14 Jan 1986 15:42 EST (Tue)
Message-ID: <RICH.12175242110.BABYL@MIT-OZ>
From: Charles Rich <RICH%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
To: bug-teco%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU,
bug-emacs%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: Enabling
Is there any way to Enable (in the Tops-20) sense from inside
Teco/Emacs? I searched for ENABLE in TECORD, but could not
find anything suitable.
Thanks, CR
Date: Sat, 10 Aug 85 18:49:14 EDT
From: Gail Zacharias <GZ@MIT-MC.ARPA>
Subject: TECO 1210
To: BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].607760.850810.GZ>
Bug-Teco:
I have built Teco 1210, finishing up the long filename support for ITS
started (but apparently not debugged) in 1209. (1210 also contains one more
terminal type for twenex, mainly to free up the OZ disk space that the
waiting-for-merging copy of teco was taking up).
Bug-Emacs:
There was an apparently bogus file in EMACS;EMACS :EJ. I renamed it to
EMACS BAD:EJ, and made EMACS :EJ a link to [PURE] >. I then built an
Emacs on Teco 1210, which is EMACS;TS 126.
It seems that SYS2;TS EMACS has been a link to EMACS;TS NE since '82. I
made it a link to EMACS;TS E, and made EMACS;TS E a link to EMACS;TS 125
(it used to point to TS 123).
Thus :EMACS is unchanged, and :NEMACS gets you the new emacs.
Date: Sun, 28 Jul 85 06:58:50 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem - yet more data
To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].590992.850728.KLH>
Well, with considerable pain I was able to cause an example of
this lossage while keeping a TCP datagram log. However, the log
doesn't show what I expected; I was looking for the stretch of
duplicated text that I observed, and couldn't find it. There are
some retransmissions but they are all correct.
Until GSB commented on the fact that the extra stuff seemed to be
a duplicate of previous stuff, I hadn't noticed this attribute, but
since then I've checked every instance and this appears to be always
true. Something somewhere is being retransmitted or re-used.
Since this happens with both CTN (CRTSTY SUPDUP) and TOPS-20 TN,
it isn't a TOPS-20 user-program problem. Since the outgoing datagram log on
MC shows no problems, the obvious deduction is that this looks like a
TOPS-20 monitor problem. As it happens, the duplicated stuff does appear
to correspond to a re-packetized TCP segment. More tests will be
necessary to confirm this, however.
This also implies that GSB's problem is actually something different
from this one. Since he mentioned it happening with PEEK, I think
we should confine further discussion to BUG-ITS and leave out
BUG-RMAIL,TECO,EMACS unless more information turns up.
Date: Tue, 23 Jul 85 22:37:28 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: re: RMAIL display problem
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].586008.850723.GSB>
I cam make it happen with peek on a 60 high 118 wide screen, just like i
can with rmail. looks like the cursor positioning goes bonkers as a
function of me typing at it.
Date: Mon, 22 Jul 85 18:06:15 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: re: RMAIL display problem -- you'll like this
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].584681.850722.GSB>
right here in the privacy of my own office, i can reproduce this, freeze
the screen, and get a hardcopy of the lossage. Isn't VMS wonderful?
Date: Mon, 22 Jul 85 13:30:54 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem
To: KLH@MIT-MC.ARPA
cc: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].584298.850722.KLH>
Some additional data which supports the theory that a user-program or
ITS TTY bug may be involved:
Date: Thu, 18 Jul 85 22:40:40 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: RMAIL display problem
To: KLH@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].581085.850718.GSB>
All the times i have seen such an error i have been able to find duplicated
text on the screen and the supposition was that it was a duplicated
tcp packet or something like that. I have seen this both internetting
from ru-net to here (from a 20) and i believe just within rutgers
(tops-20 -> tops-20 just on ru-net).
----------------------
Date: Fri, 19 Jul 85 23:45:04 EDT
From: Glenn S. Burke <GSB@MIT-MC.ARPA>
Subject: tty lossage
To: KLH@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].582348.850719.GSB>
well maybe i should take back what i said last night.
I'm coming from a microvax vaxstation running a vt100 emulator window,
running decnet to a 750 (corwin) from whence i'm doing chaosnet supdup
to mc. The window size is 94 wide by 55 high [i TOLD it 96 wide at this
end, you know how these things are...] anyway, i have a two screen long
(at this screen size) message, and if i have it redisplay the first and
get a space (in rmail, go to next screen) before it finishes, it invariably
fucks up.
anyway, there ain't no tcp in THIS network path.
Date: Thu, 18 Jul 85 05:55:23 EDT
From: Ken Harrenstien <KLH@MIT-MC.ARPA>
Subject: RMAIL display problem
To: BUG-ITS@MIT-MC.ARPA, BUG-RMAIL@MIT-MC.ARPA,
BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].580138.850718.KLH>
I'm not sure where the fault for this one might be, hence the shotgun
message.
In RMAIL, when using "space" to step through successive screenfuls
of a long message, sometimes output fails to stop at the mode line;
it continues for several more lines and runs right off the bottom of
the screen, causing the terminal to either scroll or wrap up to
the top (depending on one's terminal). The screen is then permanently
messed up until a complete redisplay is forced with ^L.
This happens for me when connected to MC either via SUPDUP (ie as a
software TTY) or via TELNET with a :TCTYP DM2500 declaration. At
first I thought it might be a CRTSTY/SUPDUP problem, but my TELNET
experiments have convinced me that it really is MC's fault.
However, I haven't been able to find a foolproof way of reproducing
the lossage. All I can say is that in the course of reading through
several SF-LOVERS digests on a 24x79 screen, this bug almost always
crops up someplace, sometimes twice or thrice in a row. I type:
N E ^K ^X r ; to invoke RMAIL
<spaces as needed to read msg> d ; for each message
This is probably a TECO bug of some variety, but there's an off
chance it might be an ITS TTY handling bug. It's even possible
that some EMACS code is screwing up the redisplay. This has happened
for quite a while (several months). I hope someone else has a
notion of what to look for at this point. If necessary, I could
try again to save a reproducible instance of this, although it is
a rather painful task.
Date: Thu, 20 Jun 85 21:28:22 EDT
From: Leigh L. Klotz <KLOTZ@MIT-MC.ARPA>
To: ZVONA@SRI-AI.ARPA
cc: BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
In-reply-to: Msg of Wed 19 Jun 1985 11:28 PDT from ZVONA at SRI-AI
Message-ID: <[MIT-MC.ARPA].550589.850620.KLOTZ>
I think Gumby wrote the long-needed routine that looks in
system:hostname.txt if it can't use a jsys to get the hostname.
Date: Thu, 20 Jun 85 20:59:11 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject: SU TECO/EMACS
To: BillW@SU-SCORE.ARPA
cc: BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA,
ZVONA@SRI-AI.ARPA
Message-ID: <[MIT-MC.ARPA].550502.850620.GUMBY>
Date: 20 Jun 1985 00:29-PDT
From: William "Chops" Westfield <BillW at SU-SCORE.ARPA>
...This is done in the latest version of EMACS/TECO
being distributed out of Stanford - how does one go about making
that the default version everywhere (MIT people, where should
it be put?)
I got a copy from Bradford; it's being merged into the tape.
Received: from SU-SCORE.ARPA by MIT-MC.ARPA 20 Jun 85 03:30:50 EST
Date: 20 Jun 1985 00:29-PDT
Sender: BILLW@SU-SCORE.ARPA
From: William "Chops" Westfield <BillW@SU-SCORE.ARPA>
To: ZVONA@SRI-AI.ARPA
Cc: bug-emacs@MIT-MC.ARPA, bug-teco@MIT-MC.ARPA
Message-ID: <[SU-SCORE.ARPA]20-Jun-85 00:29:49.BILLW>
In-Reply-To: <ZVONA.12120429714.BABYL@SRI-AI>
uh, like ever since NCP went away, all internet hosts have
"long" host numbers. use of CVHST should be flushed in favor of
GTHST everywhere! This is done in the latest version of EMACS/TECO
being distributed out of Stanford - how does one go about making
that the default version everywhere (MIT people, where should
it be put?)
BillW
Received: from SRI-AI.ARPA by MIT-MC.ARPA 19 Jun 85 22:19:14 EST
Date: Wed, 19 Jun 1985 11:28 PDT
Message-ID: <ZVONA.12120429714.BABYL@SRI-AI>
From: ZVONA@SRI-AI
To: bug-emacs@mc, bug-teco@mc
I fixed the problem I reported by reassembling with HSTNAM defined.
In the next tape that gets sent, the following comment from CONFIG.MID
should be expanded to explain that Arpa hosts with long host numbers,
as well as Chaos hosts, need to define this.
; If you are a non-ARPA Babyl site (more technically, if CVHST doesn't work
; but you need it for packages such as Babyl, eg, at Chaos MIT hosts), you should
; uncomment the following two lines and put your hostname in.
DEFINE HSTNAM
ASCIZ/your official hostname here/!TERMIN
Received: from SRI-KL.ARPA by MIT-MC.ARPA 19 Jun 85 17:59:12 EST
Date: Wed 19 Jun 85 12:35:37-PDT
From: LARSON@SRI-KL.ARPA
Subject: previous
To: bug-teco@MIT-MC.ARPA
I guess part of it should have gone to bug-emacs, but I hope it
will get there...
Alan
-------
Received: from SRI-KL.ARPA by MIT-MC.ARPA 19 Jun 85 17:58:52 EST
Date: Wed 19 Jun 85 12:35:06-PDT
From: LARSON@SRI-KL.ARPA
Subject: cvhst garbage
To: bug-teco@MIT-MC.ARPA
You are trying too hard to help the system, by doing a SYSGT or
GETAB to read LHOSTN before doing a CVHST. It is faster, and easier,
to just plug a full-word -1 into AC2 for CVHST (or the appropriate
host# to string GTHST%). This will save an extra trip through the
JSYS code. It will correct problems with babyl, M-X Date Edit, etc.
Speaking of M-X Date Edit, it gets real confused when the comment
string is null instead of ;. Other things wisely default to ";" as
the comment string, but not Date Edit.
Alan
-------
Date: Mon, 17 Jun 85 20:04:49 EDT
From: David Vinayak Wallace <GUMBY@MIT-MC.ARPA>
Subject: TECO host problem
To: Zvona@SRI-AI.ARPA
cc: BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
In-reply-to: Msg of Mon 17 Jun 1985 09:57 PDT from ZVONA at SRI-SPRM.ARPA
Message-ID: <[MIT-MC.ARPA].547587.850617.GUMBY>
Date: Mon, 17 Jun 1985 09:57 PDT
From: ZVONA at SRI-SPRM.ARPA
Hi, I have an emacs (teco?) problem for you. SRI-AI has a "big" host
number (whatever that means). EMACS here apparently truncates this host
number (perhaps by using the NOHOST jsys) which fucks up babyl and the
fancy mode line (and maybe other things). What I'd like to know is
whether this has been fixed at MIT (our EMACS is at least a couple
years out of date) and if so how to get a new EMACS (teco?) source and
how to compile it. Can you help? Or know who could? Thanks.
I don't understand this report. Can you supply more bits?
In any case a new EMACS tape should be appearing "Real Soon Now."
Date: Mon, 17 Jun 85 14:53:26 EDT
From: Alan Bawden <ALAN@MIT-MC.ARPA>
Subject: This went to Bug-Random-Program due to host table vandalization
To: BUG-EMACS@MIT-MC.ARPA, BUG-TECO@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].546909.850617.ALAN>
Received: from SRI-AI.ARPA by MIT-MC.ARPA 17 Jun 85 12:59:58 EST
Date: Mon, 17 Jun 1985 09:57 PDT
Message-ID: <ZVONA.12119888829.BABYL@SRI-SPRM.ARPA>
From: ZVONA@SRI-SPRM.ARPA
To: bug-emacs@mc, bug-teco@mc
Reply-to: Zvona@SRI-AI.ARPA
Hi, I have an emacs (teco?) problem for you. SRI-AI has a "big" host
number (whatever that means). EMACS here apparently truncates this host
number (perhaps by using the NOHOST jsys) which fucks up babyl and the
fancy mode line (and maybe other things). What I'd like to know is
whether this has been fixed at MIT (our EMACS is at least a couple
years out of date) and if so how to get a new EMACS (teco?) source and
how to compile it. Can you help? Or know who could? Thanks.
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 11 JUN 85 15:42:38 EDT
Date: Tue 11 Jun 85 15:40-EDT
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
Subject: fscase$
To: bug-teco@MIT-MC
It seems that the uppercase editing stuff (i.e. fscase$) will flag upperase
chars but still send lowercase to your terminal, on the assumption, I guess,
that your terminal will display them as uppercase. Unfortunately there are
uppercase-only terminals which don't understand lowercase ascii codes at all.
Teco should actually do the conversion to uppercase, since that would work
on both types of terminals.
Date: Fri 15 Feb 85 18:59-EST
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
Subject: fsbound
To: bug-teco@MIT-MC
Why doesn't fsbound$ just order its arguments instead of giving 2<1 errors?
Date: 14 Nov 1984 14:42-PST
Sender: BILLW@SRI-KL
Subject: Re: need terminal stuff for Sun
From: William "Chops" Westfield <BillW@SRI-KL.ARPA>
To: SHSU@MIT-MC
Cc: BUG-EMACS@MIT-MC, BUG-TECO@MIT-MC
Message-ID: <[SRI-KL]14-Nov-84 14:42:28.BILLW>
In-Reply-To: The message of 14 November 1984 06:46-EST from Sam Hsu <SHSU @ MIT-MC>
See SRI-KL:<EMACS>TECTRM.MID - This includes a definition for the SUN,
and also two definitions for the HDS Concept AVT. A SUN is basically
similar to an AAA with 34 lines of text. (assuming the the SUN-1 VT100
terminal emulator/TELNet)
BillW
Date: 14 November 1984 06:46-EST
From: Sam Hsu <SHSU @ MIT-MC>
Subject: need terminal stuff for Sun
To: BUG-EMACS @ MIT-MC, BUG-TECO @ MIT-MC
Anyone have the teco.mid terminal entry for a Sun workstation? I don't
feel like making one up if someone already has one...
Received: from MIT-MC by MIT-OZ via Chaosnet; 30 May 84 16:11-EDT
Date: 30 May 1984 16:11-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject: Phase of the Moon
To: Mly @ MIT-OZ
cc: GLS @ MIT-MC, bug-teco @ MIT-OZ, bug-emacs @ MIT-OZ,
sr.ehpyc @ MIT-SPEECH, SR.KAUFMAN @ MIT-SPEECH
In-reply-to: Msg of Wed 30 May 84 13:23:28-EDT from Richard "Miserable Cloudy Day for the Partial Eclipse. FOO!!!" Mlynarik <mly at MIT-MC.ARPA>
Hmm, I just checked it, and GLS's code contains the following comment:
;;; THIS ROUTINE IS NOT TRULY ACCURATE, THEY SAY, BUT WHO CARES?
Oh well.
Received: from MIT-MC by MIT-OZ via Chaosnet; 30 May 84 16:03-EDT
Date: 30 May 1984 16:03-EDT
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject: Phase of the Moon
To: Mly @ MIT-OZ
cc: bug-teco @ MIT-OZ, bug-emacs @ MIT-OZ, sr.ehpyc @ MIT-SPEECH,
SR.KAUFMAN @ MIT-SPEECH
In-reply-to: Msg of Wed 30 May 84 13:23:28-EDT from Richard "Miserable Cloudy Day for the Partial Eclipse. FOO!!!" Mlynarik <mly at MIT-MC.ARPA>
What's wrong with the algorithm in Maclisp?
Date: Wed 30 May 84 13:23:28-EDT
From: Richard "Miserable Cloudy Day for the Partial Eclipse. FOO!!!" Mlynarik <mly>
Subject: Re: Phase of the Moon
Sender: MLY%MIT-OZ@MIT-MC.ARPA
To: SR.KAUFMAN%MIT-SPEECH@MIT-MC.ARPA
cc: bug-emacs%MIT-OZ@MIT-MC.ARPA, bug-teco%MIT-OZ@MIT-MC.ARPA,
sr.ehpyc%MIT-SPEECH@MIT-MC.ARPA
Reply-To: MLY@MIT-OZ.#Chaos
In-Reply-To: Message from ""David H. Kaufman" <SR.KAUFMAN@MIT-SPEECH>" of Wed 30 May 84 12:28:00-EDT
Date: 30 May 1984 12:28 EDT (Wed)
From: "David H. Kaufman" <SR.KAUFMAN@MIT-SPEECH>
To: bug-emacs@oz, bug-teco@oz
cc: sr.ehpyc@MIT-SPEECH, sr.kaufman@MIT-SPEECH
Subject: Phase of the Moon
Wednesday, May 30,,1984
NM+21H.21M.31S.
According to the Miniature Almanac in today's Boston Globe (page 55),
the New Moon is at 12:49 PM today (that is, in about 1/2 hour), not 21
hours ago.
DHK
P.S. If anybody has a *working* algorithm for finding the phase of the
moon, I'd love to see it.
There are good algorithms (though getting a *little* dated now -- but nothing
that can't be fixed by looking up newer orbital elements in an ephemeris)
in mit-xx:<mdllib>celest.mud.
I started translating these into zetalisp at one stage, and will probably finish
doing that sometime later this month, now that I know that somebody else
realizes what a fantastically important undertaking that is.
-------
Received: from MIT-SPEECH by MIT-OZ via Chaosnet; 30 May 84 12:27-EDT
Date: 30 May 1984 12:28 EDT (Wed)
Message-ID: <SR.KAUFMAN.12019482301.BABYL@MIT-SPEECH>
From: "David H. Kaufman" <SR.KAUFMAN@MIT-SPEECH>
To: bug-emacs@oz, bug-teco@oz
cc: sr.ehpyc@MIT-SPEECH, sr.kaufman@MIT-SPEECH
Subject: Phase of the Moon
Output from the EG command:
840530
122359
SS:<SR.KAUFMAN>
SS:<SR.KAUFMAN>MAIL.TEMP.0
Wednesday, May 30,,1984
NM+21H.21M.31S.
According to the Miniature Almanac in today's Boston Globe (page 55),
the New Moon is at 12:49 PM today (that is, in about 1/2 hour), not 21
hours ago.
DHK
P.S. If anybody has a *working* algorithm for finding the phase of the
moon, I'd love to see it.
Date: Mon, 28 May 1984 14:32 EDT
Message-ID: <KLOTZ.12018980548.BABYL@MIT-OZ>
From: "Leigh L. Klotz" <KLOTZ%MIT-OZ@MIT-MC.ARPA>
To: bug-teco%MIT-OZ@MIT-MC.ARPA
Anybody know why there's an ANNARBOR terminal type and an AMBASSADOR
terminal type? They have separate dispatch tables. Is it for some
old kind of ann arbor terminal?
Date: Fri, 20 Apr 1984 14:40 EST
Message-ID: <ECC.12009031566.BABYL@MIT-OZ>
From: Eugene Ciccarelli <ECC%MIT-OZ@MIT-MC.ARPA>
To: BUG-TECO%MIT-OZ@MIT-MC.ARPA
Subject: --nn%--
I've forgotten whether this request has come up before (I'm sure
it must have) and whether there is anything tricky involved --
seems very simple and uncontroversial. The request is that the
more line show --nn%-- where nn% is in terms of the *virtual*
buffer, not the whole buffer (fsZ). It is especially strange in
two respects: First, when some program like Babyl uses the
virtual buffer to implement in effect separate buffers. And
second, the --Top-- and --Bot-- are in terms of the virtual
buffer, and so the more line is inconsistent.
Is there a reason why the current behavior is preferable? Is
this not an easy thing to do in Teco? (Seems like it should just
be the same arithmatic, but on a couple of different variables, B
and Z addresses instead of buffer start and end addresses.)
Date: 31 March 1984 03:21-EST
From: Devon S. McCullough <DEVON @ MIT-MC>
To: BUG-TECO @ MIT-MC
Where can I find a TECO source that assembles without errors? Look:
oz^K!
...
@gz.devon
Job 93 on TTY106 31-Mar-84 03:04
...
@midas <gz.devon>foo_<emacs>teco
TECO
END OF LOW IMPURE = 4026
NH52TB+12 50250 0. 338-015 Symbol table full
Unterminated successful bracketed conditionals
The first was at 288-002 of file TECO
Error is fatal.
Run time = 15.27
8001 Symbols including initial ones (100% used)
@...
I get similar results assmbling the same file on MC, I guess the TTY
support must have an extra [ in there somewhere. What do the cryptic
numbers 50250, 338-015 and 288-002 refer to? The last two look like @
page-line references, but I don't know how to find such in EMACS.
Received: from SCRC-MERRIMACK by SCRC-STONY-BROOK with CHAOS; Mon 12-Mar-84 22:46:47-EST
Date: Mon, 12 Mar 84 22:44 EST
From: Mike McMahon <MMcM%SCRC-TENEX@MIT-ML.ARPA>
Subject: GC not reclaiming impure strings held by macro frames
To: Kent M Pitman <KMP@MIT-MC.ARPA>
cc: BUG-TECO@MIT-MC.ARPA
In-Reply-To: The message of 10 Mar 84 18:48-EST from Kent M Pitman <KMP at MIT-MC>
Supersedes: <840312223310.2.MMcM@TENEX.SCRC.Symbolics>
Message-ID: <840312224424.3.MMcM@TENEX.SCRC.Symbolics>
Date: 10 March 1984 18:48-EST
From: Kent M Pitman <KMP @ MIT-MC>
It looks probable that Teco is considering all macro frames to be live,
rather checking to see if they really are.
Your guess is right.
To do it your way, you can change GCC2 to chain through the macro pdl
list starting with what's in MACPTR and following by way of MFLINK.
Something like (untested of course):
GCC1: MOVE T,MACPTR
GCC2: MOVEI T,MFCSTR(T) ;POINT TO CSTR
SKIPE (T)
CALL GCMA
ADDI T,MFARG1-MFCSTR
CALL GCM ;MARK MACRO ARG 1 (MAY BE A STRING POINTER)
ADDI T,MFARG2-MFARG1
CALL GCM ;MARK MACRO ARG 2
SKIPE T,MFLINK-MFARG2(T)
JRST GCC2
Probably an easier solution is to have FLSFRM do SETZM MFCSTR+1(A), so
that the (now dead) frame doesn't point to the string at all.
Received: from SCRC-MERRIMACK by SCRC-STONY-BROOK with CHAOS; Mon 12-Mar-84 22:35:31-EST
Date: Mon, 12 Mar 84 22:33 EST
From: Mike McMahon <MMcM%SCRC-TENEX@MIT-ML.ARPA>
Subject: GC not reclaiming impure strings held by macro frames
To: Kent M Pitman <KMP@MIT-MC.ARPA>
cc: BUG-TECO@MIT-MC.ARPA, BUG-EMACS@MIT-MC.ARPA, BUG-NEX@MIT-MC.ARPA
In-Reply-To: The message of 10 Mar 84 18:48-EST from Kent M Pitman <KMP at MIT-MC>
Message-ID: <840312223310.2.MMcM@TENEX.SCRC.Symbolics>
Date: 10 March 1984 18:48-EST
From: Kent M Pitman <KMP @ MIT-MC>
It looks probable that Teco is considering all macro frames to be live,
rather checking to see if they really are.
Your guess is right.
To do it your way, you can change GCC2 to chain through the macro pdl
list starting with what's in MACPTR and following by way of MFLINK.
Something like (untested of course):
GCC1: MOVE T,MACPTR
GCC2: MOVEI T,MFCSTR(T) ;POINT TO CSTR
SKIPE (T)
CALL GCMA
ADDI T,MFARG1-MFCSTR
CALL GCM ;MARK MACRO ARG 1 (MAY BE A STRING POINTER)
ADDI T,MFARG2-MFARG1
CALL GCM ;MARK MACRO ARG 2
SKIPE T,MFLINK-MFARG2(T)
JRST GCC2
Probably an easier solution is to have FLSFRM do SETZM MFCPTR+1(A), so
that the (now dead) frame doesn't point to the string at all.
Date: 10 March 1984 18:48-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: GC not reclaiming impure strings held by macro frames
To: BUG-TECO @ MIT-MC
cc: BUG-EMACS @ MIT-MC, BUG-NEX @ MIT-MC
This message records a discussion I had with RMS regarding a
probable bug in the Teco GC relating to impure strings held by
inactive macro frame pointers.
I have a Teco init file for dumping an Emacs which does some setup,
then does:
er @y fsrgetty"n@' ftAttempting to macro buffer... :m(hfx*)'
The start file which gets loaded is very large (about 5K) and does
:m(@:i*| -1f? ei@ejw@ft
Dumped to N
0fsechoactivew164000.fs exit|)
at the end of it so that the 5K string can get reclaimed by the -f?
Unfortunately, if I read the resulting BIN file into an editor and
search for the 5K start file, I find that the string is still present
and not getting GC'd.
From DDT, did searching for the ASCII text of the start file and
found the rubout leading off that string to be in the first char of
47440(8) Given that QRBUF holds 277306(8), I computed the string
pointer as -34359735078(10), which Teco recognizes as a valid string
pointer and g(-34359735078) seems to yank my start file so I'm sure
I'm looking at the right object.
Using W from DDT again, I determined that the only locations pointing
to -34359735078(10) are MFSTRT+20, MFSTRT+27, MFSTRT+36, and MFSTRT+54,
so it looks to me like it's Teco internals that is holding onto the
only pointer to this.
It looks probable that Teco is considering all macro frames to be live,
rather checking to see if they really are.
For now I will attempt to kludge around this by making my start file into
a library and just not :EJ'ing it upon startup after dump, but if someone
who knows enough to fix this bug for real could do so, I would
greatly appreciate it.
Thanks, -kmp
Date: Fri 20 Jan 84 12:46:25-PST
From: Sam <FHsu@WASHINGTON.ARPA>
Subject: Re: [MARTY%MIT-OZ: Fix for 2 echolines bug in TECO on Tops-20 with VTS]
To: GZ%MIT-OZ@MIT-MC.ARPA
cc: bug-teco@MIT-MC.ARPA
In-Reply-To: Message from "Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>" of Fri 20 Jan 84 11:40:28-PST
I believe the official newest version of TECO is in [oz]tinman:<emacs>.
There are several versions of TECO waiting to be merged - the one without
stuff like TECO-CHIRON.MID (the name attached) is the one to edit, or if
there isn't one like that, the TECO-FHSU one is the one that will contain
all the other edits (the other edits are mostly new terminal types which
can now go into TECTRM.MID).
-------
Date: Fri, 20 Jan 1984 14:35 EST
Message-ID: <GZ.11985175440.BABYL@MIT-OZ>
From: Gail Zacharias <GZ%MIT-OZ@MIT-MC.ARPA>
To: bug-teco@MIT-MC
Subject: [MARTY%MIT-OZ: Fix for 2 echolines bug in TECO on Tops-20 with VTS]
Is there any chance this could get installed? If somebody tells me where
the official sources are and what the correct procedure is, I'll do it
myself.
Date: 18 Jan 1984 03:02 EST (Wed)
From: Martin David Connor <MARTY%MIT-OZ at MIT-MC.ARPA>
To: Bug-Emacs%MIT-OZ at MIT-MC.ARPA
cc: MARTY-CC%MIT-OZ at MIT-MC.ARPA,
Leonard N. Zubkoff <Zubkoff%TARTAN at CMU-CS-C.ARPA>
Re: Fix for 2 echolines bug in TECO on Tops-20 with VTS
In VTS systems on Tops-20 the following bug happens when there are 2
echolines and the terminal is in WRAP mode.
If you type a carriage return to a prompt, sometimes the response will
WRAP to the top of the screen and kill the top line. Since EMACS
doesn't expect this (as it should not), I sought a bug fix for it.
The following fix is from from Leonard N. Zubkoff at CMU and has been
working fine in the version of TECO he maintains.
Here is the place where the fix needs to be applied:
; DO INITIAL SETUP
SETTTM: SAVE C
MOVSI A,.TICCG ; ^G ON CHANNEL 0
SKIPG NOQUIT ; IF QUITTING IS ALWAYS DISABLED DO NOT ARM ATI
ATI ; ^G, SO THAT IT WILL ARRIVE AS A COMMAND AT
; THE CORRECT TIME (THIS IS FOR RMODE).
CALL DOSTIW ; SETUP TERMINAL INT MASK
MOVEI A,.CTTRM
RTMOD% ;[NEW] Read VTS Terminal Mode Word (Jsys 636)
ERJMP .+4 ;[NEW] No VTS.
TLO B,(TM%SCR) ;[NEW] Turn off Wrap Mode (200000,,0)
STMOD% ;[NEW] Set VTS Terminal Mode Word (Jsys 637)
ERJMP .+1 ;[NEW] No VTS.
RFMOD ; GET TTY MODE WORD
SKIPE CH,RGETTY ; PRINTING?
TRZA 2,TT%DAM ; NO, BINARY MODE THEN
TRO 2,1_6\TT%ECO ; YES, MAKE SURE DATA MODE NORMAL
. . . .
Installing this fix will greatly help people who would like to use 2
echoline mode all the time.
Could someone please install it in the OZ version of TECO, or explain
to me the procedure for doing it?
Date: 16 November 1983 12:39 EST
From: Earl A. Killian <EAK @ MIT-MC>
Subject: If anybody ever has the energy to look at the redisplay routine
To: KLOTZ @ MIT-MC
cc: BUG-EMACS @ MIT-MC, BUG-TECO @ MIT-MC
In-reply-to: Msg of 16 Nov 1983 00:05 EST from Leigh L. Klotz <KLOTZ>
I believe this is a "feature". It is considered too expensive to
update the hash code of a line for operations such as
self-insert, and so it just sets the hash code to -1. The next
redisplay that specifies bounds that include that line will
retype it, because the hash code is wrong. The reason that it
doesn't retyped more often is that most things are so good about
returning accurate buffer bounds to limit redisplay.
Date: 16 November 1983 00:05 EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject: If anybody ever has the energy to look at the redisplay routine
To: BUG-EMACS @ MIT-MC, BUG-TECO @ MIT-MC
I suspect this bug has to do with the TYO HASH, but it may be unfixable
and just part of the algorithm - it's been with us for ages, but it
seems to me that I don't remember it happening three years ago or so.
Type ^R on this message and modify a line. They type M-X ^G.
The line will be needlessly redisplayed. It works for more than one
line, too. ^U-^L will give the same effect, so it's presumably
it's just the redisplay routine. When I look at the FS TYO HASH
of the affected lines, they are -1. So does this mean that the
tyo hash isn't validated until there's a honest full redisplay, or
something like it?
Leigh.
Date: 11 Nov 1983 17:30 PST (Fri)
Message-ID: <FHSU.11966889994.BABYL@WASHINGTON>
From: Sam <FHSU@WASHINGTON.ARPA>
Subject: new TECO put on XX
To: bug-teco@MIT-MC.ARPA
Cc: Klotz@MIT-MC.ARPA
MIT-XX has new TECO sources -- version 1209 taken from v1208 on OZ. (Note
that there is a v1210 on OZ which is not really a v1210 -- it just got that
way when it came from elsewhere.) Changes are in TECO.CHANGES. All this
is in [MIT-XX]PS:<EMACS>. It should get moved to [OZ]TINMAN:<EMACS> some
time, where the newest stuff is.
Major note: the terminal type support code has been moved into TECTRM.MID!
This makes merging all the new terminal type submissions easier - Bill W's
fix re PUSHJ P,DYPINI before PAGON: is in. Did I miss anyone's request?
After the term is over, I can spend some time working on Emacs again...
Date: Sat, 8 Oct 1983 14:48 EDT
Message-ID: <[MIT-OZ].GZ. 8-Oct-83 14:48:13>
From: Gail Zacharias <GZ@MIT-OZ>
To: Bug-Emacs@MIT-OZ
Cc: bug-teco@MIT-OZ, help-me@MIT-OZ, AGRE@MIT-OZ
Subject: 20x command files
Date: Saturday, 8 October 1983 14:01-EDT
From: AGRE
To: help-me
What is the right mode to indicate in 20X command files, such as
<agre>logicals.cmd? Right now I say
! -*- CMD -*- !
and get this error message
File Not Found <AGRE>CMD..0
There is a bug in the mode autoloading code, in particular Load Library
ends up getting called with the string " CMD ". This apparently invokes a
Teco bug whereby (with fsfnamsyntax=1), ET CMD (spaces included)
clobbers the second filename to null.
Date: 5 October 1983 17:09 EDT
From: Gail Zacharias <GZ @ MIT-MC>
Subject: [JTW: Emacs hacking...]
To: JTW @ MIT-MC
cc: bug-teco @ MIT-OZ, ian @ MIT-OZ, mmcm @ SCRC-TENEX
In-reply-to: Msg of 4 Oct 1983 1411-EDT from John Wroclawski <JTW at MIT-SPEECH>
Date: 4 Oct 1983 1411-EDT
From: John Wroclawski <JTW at MIT-SPEECH>
...
last DECUS this issue of EMACS and TEXTI came up, resulting in the DEC
monitor people claiming that they would be more than willing to make
the necessary changes if somebody would tell them what to add.
From EMACS:TWENEX.LOSSES (on OZ, and presumably most distribution sites):
* TEXTI
Everyone is eager for EMACS to use TEXTI break masks to do more
efficient echoing of insertion at the end of a line. Unfortunately,
it can't be used by EMACS (or any comparable editor) because it has so
many misfeatures. For one thing, it echoes the break character (the
control character or whatever which follows the inserted text)! There
are other problems: binary mode, which EMACS must use to be able
to read the ^@ character, turns off the break mask and also forces
echoing off. In addition, there is no way to deal with the Meta bit
on terminals which have it (Meta-A must break whether A does or not).
Date: Tue 4 Oct 83 19:53:53-EDT
From: RMS@MIT-OZ
Subject: PBOUTs
To: bug-teco@MIT-OZ, jtw@MIT-OZ
TECO does not use PBOUT for outputting a screen.
It does a single SOUT per line. This SOUT includes
the cursor motion and cleol that precedes the text of the line.
I suggest that anyone who wants to see EMACS use TEXTI get DEC
to fix the monitor first. The TECO changes are not very hard
since there is already a routine to use ECHOIN on ITS, which does
approximately the same thing. All this code is on one page,
and that's the only place that would need to be changed.
-------
Date: 4 Oct 1983 1411-EDT
From: John Wroclawski <JTW at MIT-SPEECH>
Subject: Re: [JTW: Emacs hacking...]
To: ian at MIT-OZ, mmcm at SCRC-TENEX, bug-teco at MIT-OZ
Reply-to: JTW@MIT-MC
In-Reply-To: Your message of 4-Oct-83 1356-EDT
A specific proposal was made to DEC ages ago for fixing TEXTI for use
with EMACS. That was back when there was someone who had time to hack
TECO. Anyway, it was ignored. If DEC doesn't accept a proposed
change, then most people are no better off.
Hmmm,I wonder why this old letter of mine popped up now. Anyway, at the
last DECUS this issue of EMACS and TEXTI came up, resulting in the DEC
monitor people claiming that they would be more than willing to make
the necessary changes if somebody would tell them what to add. Now, I
don't generally believe DEC these days, but they did say this in front
of a roomfull of people.
Even if it doesn't help everybody it would presumably help the MIT machines,
which are spending a lot of time running EMACS.
-------
Received: from SCRC-NEPONSET by SCRC-SPANIEL with CHAOS; Tue 4-Oct-83 13:55:44-EDT
Date: Tue, 4 Oct 83 13:55 EDT
From: Mike McMahon <MMcM@SCRC.SCRC>
Subject: [JTW: Emacs hacking...]
To: Ian@OZ.ARPA, JTW@SPEECH.MIT
Cc: Bug-TECO@OZ.ARPA
In-reply-to: <[MIT-OZ].IAN. 4-Oct-83 07:31:58>
Message-ID: <831004135529.6.MMcM@SCRC.SCRC>
Date: 4 Oct 1983 07:31 EDT (Tue)
From: Ian Macky <Ian@MIT-OZ>
Date: Saturday, 28 May 1983 20:42-EDT
From: John Wroclawski <JTW at MIT-SPEECH>
1) [Really easy] Outputting a string. When emacs wants to write a string
of chars to the terminal, it does a bunch of PBOUT's in a loop. SOUT's
instead would be a big win. Probably they have to be done a (screen) line
at a time, to avoid wraparound problems with different monitors. But still,
24 jsys overheads instead of ~1000 to write out a screen of text is worth
something.
Not true. Look at DISSIO. Probably you're thinking of something other than
normal redisplay.
2) [Harder, and requires monitor changes] EMACS currently reads characters
one at a time in binary mode. This means a scheduler wakeup and context
switch per character, even though mostly all you want to do with characters
is echo them and write them down. So, instead of doing PBIN's to get
every character, use TEXTI and breaksets to do the right thing. There
are problems with this: a)Texti currently likes to echo the break char,
b) You can't get NUL's with texti in ascii mode, and c) what to do about
meta-keys and 12bit input from SUPDUP tty's. However, these things can
be fixed, and likely would be if somebody had an EMACS that could win
by having them so repaired.
A specific proposal was made to DEC ages ago for fixing TEXTI for use with EMACS.
That was back when there was someone who had time to hack TECO. Anyway, it
was ignored. If DEC doesn't accept a proposed change, then most people are
no better off.
Date: 4 Oct 1983 07:31 EDT (Tue)
Message-ID: <[MIT-OZ].IAN. 4-Oct-83 07:31:58>
From: Ian Macky <Ian@MIT-OZ>
To: Bug-TECO@MIT-OZ
Subject: [JTW: Emacs hacking...]
Date: Saturday, 28 May 1983 20:42-EDT
From: John Wroclawski <JTW at MIT-SPEECH>
Reply-To: JTW at MIT-MC
To: marty, ian
Re: Emacs hacking...
Or Teco hacking, more precisely. Last week I was at DECUS, where I got
to listen to 27 million people bitch about how they really wanted to
use EMACS but couldn't afford to on their machines because of the
high overhead associated with it. Now, as it happens, this is true,
and everybody knows it. A little experimenting on my part shows
that it is even truer than I thought. So it seems to me that if
something can be done about it, we will all win, and OZ will win more
than most.
There are two areas that could be easily improved. Well, one is
really easy, i think, and one is medium hard. If one of you folks
wants to cut the load on OZ in half perhaps you could work on this?
1) [Really easy] Outputting a string. When emacs wants to write a string
of chars to the terminal, it does a bunch of PBOUT's in a loop. SOUT's
instead would be a big win. Probably they have to be done a (screen) line
at a time, to avoid wraparound problems with different monitors. But still,
24 jsys overheads instead of ~1000 to write out a screen of text is worth
something.
2) [Harder, and requires monitor changes] EMACS currently reads characters
one at a time in binary mode. This means a scheduler wakeup and context
switch per character, even though mostly all you want to do with characters
is echo them and write them down. So, instead of doing PBIN's to get
every character, use TEXTI and breaksets to do the right thing. There
are problems with this: a)Texti currently likes to echo the break char,
b) You can't get NUL's with texti in ascii mode, and c) what to do about
meta-keys and 12bit input from SUPDUP tty's. However, these things can
be fixed, and likely would be if somebody had an EMACS that could win
by having them so repaired.
I don't have time to screw with this, and 310 pages of MIDAS code is
more than I can deal with anyway. But it's well worth doing, if you're
interested...
-john
Date: 3 August 1983 12:04 EDT
From: Gail Zacharias <GZ @ MIT-MC>
Subject: [BYTE: HELP!!! (please???)]
To: BUG-BABYL @ MIT-MC, BUG-TECO @ MIT-MC
[The mail file was in BYTE [BABYL, so he recovered it. Note that this
guy is on info-cpm and info-micro, so if he hadn't been on in a while
his mail file was probably humongous. However, the error looks different
from the usual one in this situation -gz]
Date: 08/03/83 03:40:04
From: BYTE
Re: HELP!!! (please???)
I just lost my mail file. I was in BABYL and it came up with the message
PUR ATTEMPT TO WRITE TO PURE PAGE?
or something like that, to which I said control-z to abort and try
something else. I hadn't been on in awhile, so I had quite a bit of
mail accumulated, which I would like to recover if possible. Could
you ask whoever's responsible for that sort of thing to see if
anything is recoverable from tape?
Many thanks for whatever help you can render...
(It might also be helpful to understand the correct reply to the error
message above so I know better the next time.)
-roger
Date: Wed, 20 Jul 1983 03:00 EDT
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To: BILLW@SRI-KL.ARPA
Cc: bug-teco@MIT-MC.ARPA
Subject: ranges
In-reply-to: Msg of 19 Jul 1983 23:06-EDT from BILLW at SRI-KL.ARPA
I doubt there will be any changes to the TECO primitives at that
level any more. TECO is getting old and crochety about being
changed, especially since witch doctors are getting scarcer these days.
Maybe the "M" hack is called for in your routines -- set up a routine
to do this in a q-register, and then call it like MM or MR do.
Leigh.
Date: Tue 19 Jul 83 20:06:39-PDT
From: BILLW@SRI-KL.ARPA
Subject: ranges
To: bug-teco@MIT-MC.ARPA
I find it ridiculous that there isnt a teco command to limit a pair
of arguments to a valid buffer range, ie: MAX(B,ARG1), MIN(Z,ARG2)
or some such - the equivilent of n,mF^@ for characters instead of
lines. Im writing a routine that expands an FB search over larger
and larger areas around ., and this would certainly make it easier,
since FB returns a 2<1 error if the second argument is beyond the end
of the buffer (or is this a bug in FB?)
BillW
-------
Date: Tue, 19 Jul 1983 05:53 EDT
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To: Gail Zacharias <GZ@MIT-OZ>
Cc: bug-emacs@MIT-OZ, bug-teco@MIT-OZ
Subject: reading filenames in the echo area with fs echo line set to 2.
In-reply-to: Msg of 19 Jul 1983 01:41-EDT from Gail Zacharias <GZ>
this is an oz-specific, or at least, mit-specific bug. it doesn't happen to me
on bbn systems.
hacking teco to redisplay the top line is attacking the problem at the wrong
level, and invites other bugs.
Leigh.
Date: Tue, 19 Jul 1983 01:41 EDT
From: Gail Zacharias <GZ@MIT-OZ>
To: bug-emacs@MIT-OZ, bug-teco@MIT-OZ
Subject: reading filenames in the echo area
I have FSECHOLIN$ set to 2. On Twenex, or at least on OZ, whenever I have
to enter a filename in the echo area (e.g. ^X^W), the top line of the
screen is cleared, apparently during echo of the terminating CR. This is
very annoying - I have to position the cursor to the top line and do M-0
C-L then find my way back to where I was, a non-trivial operation.
If this can't be fixed, could Teco or Emacs please arrange to force
refreshing of the top line in this situation? (i.e. after reading a filename
when fsecholin$ is less than 3).
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 6 Jul 83 01:51:43 EDT
Date: 6 Jul 83 0155 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: bug-teco@MIT-MC
Subject: Running out of "macro" frames
CC: bug-emacs@MIT-MC
I just spent about eight hours trying to figure out how code
that wasn't calling any macros or using any ^] commands whatsoever
could trigger the error "TMN" (too many nested macros, ^]^X, ^]^Y,
or ^]qreg). This error is particularly insidious because it is
effectively a PDL overflow, thereby blowing away all the debugging
and backtrace aids, because there's no pdl to work with.
It turns out that creating buffers and Q-vectors uses up macro
frames also, as nearly as I can tell, and there is a rather
low limit on the number that can be created (about a hundred
or so). My application was creating an elaborate data structure
using nested Q-vectors.
I have three recommendations:
(1) The error message should be clarified to indicate more clearly
the possible sources of overflow.
(2) It should be allowable to create many more Q-vectors than currently
possible. I appreciate the need for a limit on runaway macros, but
the limit (expressed by MFMAX) should be variable. Either Q-vector
creation should circumvent the overflow test, or there should be
an FS flag for raising the limit.
(3) When overflow occurs, the limit should be raised automatically
to allow the debugging routines (cf. Q..P) a little room to work in.
--Guy
Date: 30 May 1983 06:43 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: S(
To: BUG-TECO @ MIT-MC
S( seems to match anything, rather than just things that wouldn't
match S(.