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)