Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jan 89 19:52:34 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 14 Jan 89 02:49:29 EST Date: Sat, 14 Jan 1989 02:45 EST Message-ID: From: Rob Austein To: Bug-TECO@MC.LCS.MIT.EDU Subject: Ok, anybody feel like fixing the TECO garbage collector? For those who may have noticed that XX hasn't installed any new host tables on the ITS machines for a week or so, here's why. The TECO program that pre-processes the host table files has been blowing out with illegal memory reads when it tries to GC string space (32.F?). (It uses huge amounts of string space and blows out with URK errors very quickly if it doesn't GC string space every chance it gets). It looks like the garbage collector is trying to eat the :EJ space. Anybody out there who wants to have a bash at this for old time's sake? --Rob [PHOTO: Recording initiated Sat 14-Jan-89 2:31AM] MIT TOPS-20 Command Processor 5(312162)-2 XX>iddt IDDT 2.4(165)-2 ;yank file: emacs:teco ;obtain symbol file: emacs: ;rscan (JCL): teco hakhst.loader $$g TECO.1215 &ht$$ -1fs^Idisable$ :ejHAKHST.^Q:EJ$u0 er$ fsifile$u1 ec$ :i*& Macro Get$,q0m(q0+4)u.m m.m& Make Variable$u.v q1m(m.mMain$)fsexit$ &m(hfx*)$$ IMW:TECO&GCM2/ IDPB 13,TECO&GCPTR 13/ 441406 TECO&GCPTR/ TECO&VPATCH+2263,,774000 ;address space 1000 Pages, Entry vector location TECO&BOOT, length 3 0-5 RWX Private 6-60 R XC @ TECO.EXE.1215 (7-61) 61-773 RWX Private 774-777 R X HAKHST.^V:EJ.52 (0-3) ;;h XX>pop [PHOTO: Recording terminated Sat 14-Jan-89 2:35AM]  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" 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: From: Rob Austein To: "Pandora B. Berman" 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" Date: Friday, 3 April 1987 05:09-EST From: "Pandora B. Berman" 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" 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 Message-ID: <[MC.LCS.MIT.EDU].870618.860402.KLOTZ> Date: Sun, 30 Mar 86 02:43:35 EST From: Alan Bawden 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 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: From: "Frank J. Wancho" 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: From: Rob Austein To: Charles Rich 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 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: From: Charles Rich 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 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 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 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 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 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 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 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 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 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 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 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 ...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 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: 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: 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 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 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: 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 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 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 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 See SRI-KL: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 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 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 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 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 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 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" " of Wed 30 May 84 12:28:00-EDT Date: 30 May 1984 12:28 EDT (Wed) From: "David H. Kaufman" 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: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: From: "David H. Kaufman" 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: SS: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: From: "Leigh L. Klotz" 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: From: Eugene Ciccarelli 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 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 foo_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 Subject: GC not reclaiming impure strings held by macro frames To: Kent M Pitman cc: BUG-TECO@MIT-MC.ARPA In-Reply-To: The message of 10 Mar 84 18:48-EST from Kent M Pitman 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 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 Subject: GC not reclaiming impure strings held by macro frames To: Kent M Pitman 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 Message-ID: <840312223310.2.MMcM@TENEX.SCRC.Symbolics> Date: 10 March 1984 18:48-EST From: Kent M Pitman 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 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 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 " of Fri 20 Jan 84 11:40:28-PST I believe the official newest version of TECO is in [oz]tinman:. 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: From: Gail Zacharias 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 To: Bug-Emacs%MIT-OZ at MIT-MC.ARPA cc: MARTY-CC%MIT-OZ at MIT-MC.ARPA, Leonard N. Zubkoff 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 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 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 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: From: Sam 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:. It should get moved to [OZ]TINMAN: 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 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 logicals.cmd? Right now I say ! -*- CMD -*- ! and get this error message File Not Found 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 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 Date: 4 Oct 1983 1411-EDT From: John Wroclawski ... 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 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 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 Date: Saturday, 28 May 1983 20:42-EDT From: John Wroclawski 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 To: Bug-TECO@MIT-OZ Subject: [JTW: Emacs hacking...] Date: Saturday, 28 May 1983 20:42-EDT From: John Wroclawski 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 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 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 To: Gail Zacharias 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 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 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 Subject: S( To: BUG-TECO @ MIT-MC S( seems to match anything, rather than just things that wouldn't match S(.