[HECnet] Emacs-clone for RSX?

[Johnny Billquist]

It might be possible but you will have to work hard on finding ways to 
overlay it.
If you can do that, and just have a couple of K of space left, you'll be 
good. It might be rather slow, but it would still have the same 
capabilities.

	Johnny

On 2016-05-30 04:10, Dave McGuire wrote:
>
>   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
>>
>
>

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol