nText Aurora editor for DOS - mailing list archive, macro help?

[doshea]

Background

I used this editor a little back in the '90s, and then again last year, and thought it seemed pretty nice, but never invested much time in learning about all its power.

More recently I've been looking for something that works like modern GNU Emacs - at least to the extent of having some syntax highlighting, ability to run an external compiler, and the key sequences I use all the time - that would run under DESQview on a 386 with 4MB of RAM (so not taking up all the RAM!). JOVE and MicroEmacs seem too limited to me. I have an old GNU Emacs 20.4 for DJGPP I tried using but when DESQview gave it only 4MB of EMS/XMS plus whatever base RAM it got, it wouldn't start, so it's too big. JASSPA MicroEmacs seems pretty nice but seems to have hefty RAM requirements too, I think because it's a more modern backport to DOS rather than something contemporary.

Seeing that someone much smarter than me thinks Aurora is great too, and also pointed out it works on low-end systems:

I did an editor shootout many years ago but my focus was on editing speed on slow systems, not programmer's editors. That said, you might find something useful there, and you might also want to check out the Aurora editor which is ludicrously flexible.

I thought maybe my best bet would be to change Aurora into what I want.

Requests

I'm gradually figuring out how to get Aurora to do many of the things I want, although it's been a bit of a trial-and-error process where I keep making it crash by calling functions in ways that were presumably not expected.

I spent some time looking around on the Wayback Machine for archives of the Aurora mailing list in the hope that there might have been discussions there about how to do things, but those archives appear to have been hosted on sites that have been excluded from the Wayback Machine Would anyone happen to have been subscribed to the list and still have some of those emails? If not, perhaps all I can do is keep at the trial-and-error, or read the macros that come with Aurora and those available on this archived fan site, but I've already done some grepping of the former and not found much of relevance to me.

Does anyone feel qualified to offer any advice on using Aurora's macro language? For example, I'm currently wondering how I should implement modes on a per-buffer basis. Aurora seems like it wants you to do these on a per-window basis, since some interesting flags can be set on a window, and you can attach an object to a window, and objects are where you have key bindings. However, I'm trying to implement an Emacs-like scheme where you switch which buffer is displayed in a given window without changing window arrangement. I have implemented that, but it means that if you switch buffers you effectively get the mode you selected for the old buffer leaking over to the new buffer. Perhaps I could maintain an array with buffer IDs and some data, and maybe do sorted insertion into the array so that I can do a binary search for the lookup, but I'm not sure how well that would perform. Or maybe instead of changing which buffer is displayed in a window, I need to just shuffle windows around in the background and put the window for the new buffer right over the top of where the old one was. That would probably work better in the presence of file manager windows since you can't pick them from a list of buffers.

Obligatory screenshot:

 

[doshea]

Perhaps I could maintain an array with buffer IDs and some data, and maybe do sorted insertion into the array so that I can do a binary search for the lookup, but I'm not sure how well that would perform.

I just remembered that the names of variables accessed via set and lookup don't need to be valid identifiers, so unless I need a way to walk through the full list, I could just attach a variable to an object whose name is "buffer_modes_for_" + buffer_id, and it could be an array {major_mode minor_mode ...}. Then I realised I could create a unique object to store the variables in rather than just using the top-level a object, and that would enable the variable names to just be the buffer IDs. So this works:

createobject "buffmodes"
set (getcurrbuf) {"foo" "bar"} "buffmodes"
msgbox (lookup (getcurrbuf) "buffmodes")[1] // outputs "foo"

(manually transcribed, so may have typos)