5 Jun
2016
5 Jun
'16
7:41 p.m.
Mark, a little longer reply now...
On 2016-06-05 05:40, Mark Matlock wrote:
Johnny,
I just got back from a trip today and got a chance to download both your latest
version of TCP/IP as well as the new EMAcs editor for RSX. I had never used emacs before
so I working up the learning curve, and so far I really like it a lot. for the first time
I'm able to use the 48 line mode of my terminal emulator on my iMac to edit files on
the PDP-11/83 in 48 line mode!
Happy to hear that you find it useful. Yes, being able to use larger
screens is another good thing.
It took me a bit to understand that Prefix-1 (meta)
is just the Escape key. Anyone who has used emacs would have known this but I didn't.
Also there is one typo in the NEMA.HLP It says that the Quit command is C-C C-C and it
should be C-X C-C. I'm still learning about the various commands but this looks like
an editor that I can really benefit from with the multiple windows and large file
capability.
Yes, that Meta thingy would be well known to any Emacs user. To give a
bit more background on this, it comes from a time when there was only
ASCII, and ASCII is a 7-bit code. Since most serial ports, and terminals
could deal with 8 bits, some terminals decided that this 8th bit could
be used as a modifier. And that modifier was then tied to a key labelled
META. So, you had one more modifier key in addition to Control and
Shift. And this key set the 8th bit of a character. And the people who
did the original Emacs made use of this to get more functions on short
key sequences.
Now, not all terminals had Meta, so an alternative solution was
implemented, using ESC, where you first pressed ESC, and then the key
you wanted. But it was still called Meta in Emacs.
Now, as we got to 8-bit characters sets, the Meta key totally
disappeared, and only ESC was left (DEC tried to kill ESC too).
Fast forward to windowing systems like X11, and people once more wanted
more modifiers, and were not longer limited by the serial encoding used
by traditional terminals using serial communication. So in X11 (for
example) there is once more a Meta key. But this cannot be converted to
a serial line encoding as such. But, if you are using xterm, you can
actually tell xterm to sent ESC + key, if you hold down Meta and press a
key.
And thanks for the bug report on the help file. Fixed. I also updated it
with a couple of keys that I had not documented. As ^S/^Q if someones
used for flow control, I had implemented ^\ and ^_ as alternatives, but
actually ^S and ^Q are also bound, and if you turn off TTCYNC in RSX,
you can use those keys too. (And TTSYNC is not needed if you use telnet,
for example).
The macro definition feature is useful for me, but
I'm still learning how to use it. Can a macro be executed a large number of times? I
used to use the LEARN mode of KED to quickly adjust field spacing in data files. You could
see exactly what needed to be done on 1 line then repeat the macro a few thousand times
and it was quicker than writing a debugging a program.
I already answered about how to repeat commands in Emacs. I hope that
was clear enough, otherwise let me know, and I'll try to explain it better.
Johnny
Thanks again for all the great enhancements to RSX!
Best Regards,
Mark
On Jun 4, 2016, at 10:35 AM, Johnny Billquist wrote:
--
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
Just wanted to give an update, as their have at
least been some interest, and this have already been ported to Unix and VMS by others.
Lots of changes, improvements and bugfixes have been done in the last week. At this
point, the editor is pretty stable, and working well.
I expect to implement more features and functionality over time, but this is now a very
usable editor, and I'll happily accept contributions, if someone wants to hack on it.
Just ping me, and I'll try and help and support you getting started.
I've written a couple of documents on how to port this. Porting should be very
simple, I would hope, although there are always traps and issues trying to really make
something portable. So I'm also very happy to receive bug reports and issues that
people might discover in trying to port this thing.
Of particular interest would be to get someone to port this to RSTS/E. We have the same
compiler, which means most things should just work. However, there is a few OS dependent
bits that needs to be written. Nothing that I expect someone who knows how to program
under RSTS/E should find particularly hard. And on the plus side, you'll get an editor
that easily fits within the address space of a program under RSTS/E, which can edit huge
files, and many of them, at the same time, at a reasonable speed, even on real
hardware...
Johnny
On 2016-05-29 19:31, 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
--
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