Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!brl-sem!ron
From: ron@brl-sem.UUCP
Newsgroups: comp.emacs
Subject: Re: Naughty, naughty!
Message-ID: <695@brl-sem.ARPA>
Date: Sun, 22-Mar-87 00:18:47 EST
Article-I.D.: brl-sem.695
Posted: Sun Mar 22 00:18:47 1987
Date-Received: Sun, 22-Mar-87 16:41:25 EST
References: <883@cullvax.UUCP> <812@nrcvax.UUCP>
Organization: Electronic Brain Research Lab
Lines: 27

In article <812@nrcvax.UUCP>, ihm@nrcvax.UUCP (Ian H. Merritt) writes:
> ... or '186 or 8086.  It wouldn't be such a crime to refuse to support
> silly little toy architectures, except for the fact that there are
> some of us that have no choice but to work on them, and could benefit
> from having a real editor.  There ARE reasonable emacs subsets, of
> course, (i.e. MicroEmacs, Epsilon, etc.), so it may not be such a
> terrible thing.
> 
> I saw a comment needling RMS for 'violating a primary rule of
> portability', but with the x86, Intel violates common sense enough to
> create far more portability issues than RMS's oversight.
> 
C'mon, lets be fair.  For someone who just finished a C compiler,
you're being awfully short sighted.  CHAR * and INT are two seperate
types which need not have any relationship to each other.  It isn't
just "toy" machines using the Intel chips that have the problem.
Machines with 64 bit wordsizes generally make the address sizes smaller
to be reasonable.Other machines, int is smaller than char * and long.
Someone went and found the small number of cases in Gnu EMACS where these
assumptions were made and RMS scoffed and refud to make the correction,
which ioutright arrance.

A system that is going to be claimed as the saviour of the people through
free hardware ought to work on the not-free but cheap hardware of the
masses.

-Ron