[TUHS] Un-released/internal/special UNIX versions/ports during the years?

Joerg Schilling schily at schily.net
Mon Feb 27 01:55:27 AEST 2017

Angelo Papenhoff <aap at papnet.eu> wrote:

> Whoops, replied off list too accidentally, sorry Jörg.

Woops replied off list as well...

Angelo Papenhoff <aap at papnet.eu> wrote: 
> On 26/02/17, Joerg Schilling wrote: 
> > GNU EMACS is based on the Gosling EMACS and this did already include the 
> > interpreter. 
> >  
> > When Gosling started to work for Sun, he did no longer have the time to  
> > maintain it and did hand it over to Unipress. RMS did take this code, added 
> > few small changed and sold it under the name GNU emacs. 
> As far as I know the original LISP implementation in Gosling EMACS had 
> to be completely rewritten. I just don't remember where I've read this. 
Unipress asked RMS to rewrite the screen update code before distributing it as  
GNU emacs or they will sue RMS. 
It is not clear how much of the code was really rewritten. What I can tell is  
that the GNU emacs uses a screen update that is as slow as the original code  
from Gosling that Gosling took from another own project - an ASCII art editor  
that needed to be able to handle more than one simultaneous change at a time. 
My background is that I did a lot of benchmarking on Gosling Emacs, GNU Emacs,  
vi and my VED around 1985.  
It turned out that RMS may have rewritten the code but did not change the  
algorithm. My own screen update from VED is much faster even though it can 
only handle either a single deletion or a single insertion at a time. Changes
are implemented as a delete operation followed by an insert operation ahd 
this turns out to be much faster than what emacs does.  
BTW: one reason why emacs is slow is that the status line is at the bottom  
rather than being the top line as in VED. If you use emacs on a real terminal,  
you see the status line hopping... 
The oldest changelog file in GNU emacs claims on the bottom line something 
like: "Now all Gosling code has been rewritten". Given the fact that the
screen update still basically uses the same algorithm, it is not clear what 
this statement means. 


 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

More information about the TUHS mailing list