Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcvax!botter!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re:  Request for information about editors
Message-ID: <1539@botter.cs.vu.nl>
Date: Sun, 26-Jul-87 10:27:10 EDT
Article-I.D.: botter.1539
Posted: Sun Jul 26 10:27:10 1987
Date-Received: Sun, 26-Jul-87 21:06:16 EDT
References: <392@louie.udel.EDU>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 34

In article <392@louie.udel.EDU> ncoverby%NDSUVAX.BITNET@wiscvm.wisc.edu writes:
>From: Glen Overby 
>
>I have tried porting Micro Emacs version 3.6 and MicroGnuEmacs. On both
>I recieved a "Out of memory" message.

I am not surprised, "Micro" and "GNU" are two fundamentally incompatible
concepts.

Worse yet, I tried porting jove and failed.  There were two problems:

1. I couldn't make a termcap entry for the MINIX "terminal".  MINIX numbers
   the screen lines with (0, 0) in the lower left hand corner.  Perhaps it
   was arrogant of me to choose this co-ordinate system.  I just thought that
   since the entire world has been doing things this way since the time of
   Rene Descartes (1596-1650), it might be ok.  As far as I can tell, termcap
   can't hack it.

2. The keys on the numeric pad generate codes above 128.  There is no way in
   termcap to express this concept, and even if it were possible, jove
   can handle it.

While it might be possible to modify tty.c to add a new escape sequence, say
ESC ! x y to number the rows the other way, and modify it again to produce
escape sequences for the numeric pad, there is another issue-performance.
Jove writes characters to the screen one at a time.  This results in a lot of
system calls, which is very slow.  Mined has been very carefully optimized to
hold the number of system calls to an absolute minimum.

I think the most realistic possibility is to modify mined to handle large
files.  If anybody feels inspired to do this, I (personally) think it would
be the most valuable single addition to MINIX at this point.

Andy Tanenbaum (ast@cs.vu.nl)