On Wednesday, December 9, 2020 at 3:11:01 PM UTC [email protected] wrote:
> Ah, the pdp-8, a trip down memory lane. I used an 8i extensively in the > early 70s, but did not make the acquaintance of TECO. After looking it up > on Wikipedia, I' m glad I didn't. Remember how 3 ascii characters were > packed into two 12-bit words? And while the 8e may have come with 12k of > RAM, the 8i came with 4k, unless you had the money to get the extension to > 8k (which ours had) > OT: I used a similar editor to TECO on 8-bit CP/M systems back in the early 80's. This was PMATE, which IIRC was derived from "Mike Aronsen's Text Editor". You had a command line and an edit screen. The commands you could use in the command line were exceedingly crude, but surprisingly capable with a bit of practice. It was entertaining to speculate what set of commands a random bit of line noise would correspond to... One of my jobs in my early working life was to customise installations like this so that PMATE would work in the given system. You had to configure simple things like screen width and height, then harder things like "how to move cursor to position X, Y", and then on to even more complicated things via custom assembly language routines. Happy days... J^n On Wednesday, December 9, 2020 at 8:35:54 AM UTC-5 David Szent-Györgyi > wrote: > >> >> >> On Saturday, October 24, 2020 at 1:07:15 PM UTC-4 Edward K. Ream wrote: >> >>> On Sat, Oct 24, 2020 at 11:53 AM Thomas Passin wrote: >>> >>>> Remembering back to long ago when we only had 640k of RAM at the most, >>>> there were editors that kept three screens of data in memory at once - the >>>> current page, the previous page, and the next page. When the user >>>> scrolled >>>> forward (say), parts of the next page would be brought in, and when >>>> necessary another page would be read in from disk. An analogy would be a >>>> long continuous (paper) scroll, where only one part in the middle would be >>>> visible at any one time. >>>> >>>> This scheme would seem to fit right in with your thoughts above. >>>> >>> >>> Alas not. Leo's clone-find commands would pull in the entire db. That's >>> why we need a search that is disconnected from positions and generators. >>> >> >> That the clone-find commands are written to work on the entire database >> does not change the engineering considerations that arise from the goal of >> working on a database that is either too large to fit in RAM or is so large >> that the existing code becomes too slow for a database of the desired size >> even if that database does fit in RAM. >> >> I suggest looking up the user manuals for the text editor in which the >> original Emacs was first written, namely TECO >> <https://en.wikipedia.org/wiki/TECO_(text_editor)>. TECO was written for >> DEC computers with tiny address space in which to hold text, and was >> written in terms of editing the current contents of the buffer that held >> the address space's worth of the file under modification; it features >> flexible commands for paging the file's contents into the editor's buffer, >> allowing one to modify a file too big to fit. >> >> TECO was the power user's text editor on the PDP-8/e that was the first >> computer I used, back in the early Seventies - a machine with 12K words of >> RAM, which were divided into 4096-word fields; the computer could directly >> address the current field as pages of 128 words, meaning that addressing >> the current field required indirect addressing. TECO allowed me to think in >> terms of a buffer without tracking fields and pages - an abstraction you >> might want to consider for Leo to handle "huge outlines". >> >> It might be of interest to note that the original Emacs was a series of >> macros written for TECO - Emacs originally stood for "Editor Macros". >> > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/d688a85b-9f4f-4be3-9226-a8ff91176b96n%40googlegroups.com.
