[HECnet] Emacs-clone for RSX?

[Dave McGuire]

  I think this is fantastic.  Is there any chance of this running on
non-PLUS RSX?  I'm running it on several non-22-bit systems (real iron)
at LSSM.  I'd love to have an emacs-style editor available on those systems.

            -Dave

On 05/29/2016 01:31 PM, Johnny Billquist wrote:
> Not sure if anyone really cares, but I figure it don't hurt to tell
> anyway...
> 
> I have for many years used a very old version of MicroEMACS for RSX. I
> eventually started searching around for alternatives, but realized
> during that search that most Emacs clones are horribly huge (including
> MicroEMACS), not portable at all (even if they claim to be), and
> generally also expects to just allocate gobs of memory to keep all data
> in ram.
> 
> Now, RSX, being a PDP-11 OS, have a 16-bit address space limitation. So
> just allocating memory is never going to be a solution. There is a C
> compiler, which is pretty much ANSI C. But it is not Unix, and gives you
> the C standard IO library, but not low level Unix calls.
> On the plus side, most of the library can sit in supervisor space, and
> not consume any memory in your process space.
> 
> Clones I've looked at:
> MicroEMACS - Huge and difficult to port. Use lots of memory.
> JOVE - Small (runs on 2.11BSD), but horribly difficult to port.
> mg - Huge and difficult. Use lots of memory.
> AMIS - Huge, and written in Pascal. Not necessarily bad, but adapting
> the code to a new system requires mucking around some, made worse by the
> small differences in different Pascal compilers, and the lack of any
> preprocessor, as well as the bonehead type system in Pascal. Also use
> lots of memory, but it has been made to run on small machines (including
> PDP-11 with RSTS/E) in the past, so it is a solveable problem.
> Atto - Hard to port.
> JED - Huge.
> 
> I looked at dozens more, which were not even worth looking deeper into,
> or to list here.
> 
> The long and short of it was that, even though there are numerous
> implementations out there, they all suck, from my point of view.
> 
> With all that in mind, I decided to write my own Emacs clone instead
> (yes, I got horribly upset with the lousy quality of most code I looked
> at, if someone wants to hear some rants, contact me privately).
> 
> I started about a month ago, and at this point, it's working, and quite
> useful. And I guess if other people are in a similar situation, they
> might be interested in looking into this, and possibly make use of it.
> 
> Quick run through:
> . ANSI C sources.
> . Mostly uses the C standard IO library. Exception is terminal I/O,
> which requires some small pieces reimplemented if you want to port it.
> So, if you have an ANSI C compiler, porting should be very low effort.
> . Only works on ANSI terminals today. It would be doable to extend with
> other terminal support, but I don't have any need, and since I do not
> have, nor want to depend on curses, it will require coding to either
> have a module to uses curses, if that is wanted, or handling of specific
> terminals.
> . The compiled code, using PDP-11 C, ends (at the moment) up at around
> 36 Kbytes of binary. The C library and RMS sits mostly in supervisor
> mode, and is not accounted for in this.
> . Data usage is about 8K for various storage and strings.
> . Code dependecies are very much in a tree, so overlaying is easy, if
> wanted/needed, and that capability exists on the host.
> . Since I compile with split I/D space, this means than about 56K of
> dataspace can be used for buffering of various sorts.
> . File buffers are kept in a temporary file, and read/written to memory
> as needed (pretty much a demand-paging virtual memory implementation in
> the application).
> . The virtual, paged memory is about 4G, which is an absolute limit on
> memory usage. Practical file limit is (I would guesstimate) around 1G.
> . Most basic EMACS editing functions are implemented, including split
> windows, multiple buffers, kill buffer, moving around in various ways,
> and some semi-stupid automatic indentation handling for C code. Also
> incremental searching in a proper fashion.
> . Speed, tested on a real PDP-11/93 is pretty acceptable. Testing on a
> file about 1000 lines takes a couple of second to open, and a couple of
> seconds if you try to search from the start to the end. Most other
> things move faster.
> . The program is not suitable for editing binary data. The C standard
> I/O library don't really lend itself to binary I/O, and this code have
> to live within those constraints.
> 
> There are still lots of functionality that I'm working on adding, such
> as repeats (almost done) and macros (only started thinking about it).
> If people have functions they consider extra important, let me know, and
> I'll see if I can add them. If people want to contribute code, I'll be
> happy to incorporate changes as well, as long as they make sense.
> 
> The sources, as well as a compiled RSX-11M-PLUS binary for PDP-11 C
> V1.2, can be found at HECnet: MIM::DU:[NEMA], or
> ftp:://nema at mim.update.uu.se/.
> 
> This editor is now installed as ...EMA on MIM::, so if you type "EMA
> filename", you can see how it works there.
> It is now my tool for doing further development. I have ditched
> MicroEMACS. So I'm constantly testing the thing, as I am developing
> it... :-)
> 
> Maybe someone will find it useful...
> 
>     Johnny
> 


-- 
Dave McGuire, AK4HZ
New Kensington, PA