26 Feb
2017
26 Feb
'17
6:39 p.m.
From: Dave Horsfall
Another acronym is Esc Meta Alt Ctl Shift...
Good one!
And there was a pretty funny fake Exxx error code - I think it was
"EMACS - Editor too big"?
I was never happy with the size of EMACS, and it had nothing to do with the
amount of memory resources used. That big a binary implies a very large amount
of source, and the more lines of code, the more places for bugs... And it
makes it harder to understand, for someone working on it (to make a
change/improvement).
Noel
26 Feb
26 Feb
6:46 p.m.
New subject: The size of EMACS, and what hides in kLOCs
On 26 Feb 2017 07:39 -0500, from jnc(a)mercury.lcs.mit.edu (Noel Chiappa):
I was never happy with the size of EMACS, and it had
nothing to do with the
amount of memory resources used. That big a binary implies a very large amount
of source, and the more lines of code, the more places for bugs...
But remember; without Emacs, we might never have had _The Cuckoo's
Egg_. Imagine the terror of that loss.
Or not. (Though Stoll's book was one of the things that more or less
introduced me to the idea of operating systems other than DOS/Windows.
I don't remember how many times I borrowed that book from the local
library, but it was probably in the double digits at least. Later I
got my own copy, which I still have.)
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
7:32 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017, at 12:39, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
I was never happy with the size of EMACS, and it had nothing to do with the
amount of memory resources used. That big a binary implies a very large amount
of source, and the more lines of code, the more places for bugs... And it
makes it harder to understand, for someone working on it (to make a
change/improvement).
I think whether you think Emacs is large or small depends on what you think it is. If you
think it's a text editor it's huge (by the standards of the 1970s, anyway: I
have things which purport to be text editors which have python interpreters in and are
significantly larger than Emacs, *on my phone*). But if you think of it as the userland
of an operating system it's rather small. And many Emacs users do (or did: I used to
but don't so much any more) treat it as the latter.
8:19 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Oops. Meant to send this to this list but sent it privately. Here's a
second try:
My supposition is that EMACS was basically Stallman's attempt to bring in
all the things he liked about the LISP Machine environment into the Unix
world through the back door. The original PDP-10 EMACS really was just a
pile of macros which turned TECO into something usable by mere mortals. If
all you wanted was an editor that worked the same way as PDP-10 EMACS, it
would have been easy to create: several people have (MicroEMACS, etc). It's
the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift
in the bold new world of Unix that made it so huge for its time.
Mike
On Feb 26, 2017 8:40 AM, "Tim Bradshaw" <tfb(a)tfeb.org> wrote:
On 26 Feb 2017, at 12:39, Noel Chiappa
<jnc(a)mercury.lcs.mit.edu> wrote:
I was never happy with the size of EMACS, and it had nothing to do with
the
amount of memory resources used. That big a
binary implies a very large
amount
of source, and the more lines of code, the more
places for bugs... And it
makes it harder to understand, for someone working on it (to make a
change/improvement).
I think whether you think Emacs is large or small depends on what you
think it is. If you think it's a text editor it's huge (by the standards
of the 1970s, anyway: I have things which purport to be text editors which
have python interpreters in and are significantly larger than Emacs, *on my
phone*). But if you think of it as the userland of an operating system
it's rather small. And many Emacs users do (or did: I used to but don't so
much any more) treat it as the latter. 
8:54 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Michael Kerpan <madcrow.maxwell(a)gmail.com> wrote:
Oops. Meant to send this to this list but sent it
privately. Here's a
second try:
My supposition is that EMACS was basically Stallman's attempt to bring in
all the things he liked about the LISP Machine environment into the Unix
world through the back door. The original PDP-10 EMACS really was just a
pile of macros which turned TECO into something usable by mere mortals. If
all you wanted was an editor that worked the same way as PDP-10 EMACS, it
would have been easy to create: several people have (MicroEMACS, etc). It's
the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift
in the bold new world of Unix that made it so huge for its time.
But the GNU EMACS is not a RMS invention...
GNU EMACS is based on the Gosling EMACS and this did already include the LISP
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 a
few small changed and sold it under the name GNU emacs.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
9:25 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Whoops, replied off list too accidentally, sorry Jörg.
On 26/02/17, Joerg Schilling wrote:
But the GNU EMACS is not a RMS invention...
GNU EMACS is based on the Gosling EMACS and this did already include the LISP
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 a
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.
aap
9:55 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Angelo Papenhoff <aap(a)papnet.eu> wrote:
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.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Whoops, replied off list too accidentally, sorry Jörg.
Woops replied off list as well...
Angelo Papenhoff <aap(a)papnet.eu> wrote:
On 26/02/17, Joerg Schilling wrote:
> GNU EMACS is based on the Gosling EMACS and this did already include the
LISP
> 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
a
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.
9:37 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017, at 14:54, Joerg Schilling
<schily(a)schily.net> wrote:
GNU EMACS is based on the Gosling EMACS and this did already include the LISP
interpreter.
Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs
has elisp which *is* a Lisp (albeit a fairly horrid one).
There's no doubt that GNU Emacs had its roots in Gosling Emacs, but only in much the
same way that FreeBSD has its roots in 6th edition Unix.
There's also no real doubt that RMS was responsible for Emacs *as an idea* as opposed
to any particular implementation (Guy Steele is I think the other person who might be held
responsible, but I believe he's said that it was RMS, which is good enough for me).
--tim
9:52 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Tim Bradshaw <tfb(a)tfeb.org> wrote:
OK, then Gosling just had the idea of including lisp.
On 26 Feb 2017, at 14:54, Joerg Schilling
<schily(a)schily.net> wrote:
GNU EMACS is based on the Gosling EMACS and this did already include the LISP
interpreter.
Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs
has elisp which *is* a Lisp (albeit a fairly horrid one). There's also no real doubt that RMS was
responsible for Emacs *as an idea* as opposed to any particular implementation (Guy Steele
is I think the other person who might be held responsible, but I believe he's said
that it was RMS, which is good enough for me).
I am sure that emacs would be unknown today in case that Gosling did not write
the C-implementation.
A macro set for a closed source editor on a dying architecture (PDP-11)
would have died as well.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
10:06 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017, at 15:52, Joerg Schilling <schily(a)schily.net> wrote:
OK, then Gosling just had the idea of including lisp.
I'd have to check the chronology but I'm fairly sure that EINE predates Gosling
Emacs by several years: I'd assume that either EINE is where Gosling got the idea, or
that it was just obvious, since Emacs came from an environment where implementing things
in Lisp was not a strange idea, to put it rather mildly.
(Note I agree that Gosling Emacs is the root of Emacs-on-Unix and that without that Emacs
would likely have died out with the platforms it lived on.)
--tim
10:27 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Tim is right. EINE predates Gosling's EMACS by a few years. Of course,
it uses LISP as an extension language not because they thought that would be
novel but since the whole thing was implemented in LISP to begin with (much
as you could extend the TECO EMACS with more TECO).
And you are right, since EMACS (both the TECO and EINE and other variants)
were coming out of the AI realm where LISP prevails, using LISP as a
language certainly made sense. It was also really easy to implmenet a
cheap mocklisp parser as Gosling did in the an otherwise C language
implementation.
I worked with Gosling and his successor Mike Gallaher (at Unipress) for
years on the Unipress commercialization of Gosling's EMACS (I had been using
the early non-commercial version at BRL). Gosling was a big fan of
programmable interfaces. From the EMACS mocklisp, he went to developing
the NeWS window system (which used a variant of PostScript as it's language)
and then on to JAVA. I did a bunch of stuff with NeWS and Gallaher's
subsequent similar extension module SoftWire (also commercially used by my
company as PixScript). Even with Owen Densmore's (Sun Microsystems)
object oriented changes, it was a horrendous language to actually write
stuff in.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of tfb(a)tfeb.org
I'd have to check the chronology but I'm fairly sure that EINE predates
Gosling Emacs by several years: I'd assume that either EINE is where Gosling
got the idea, or that it was just obvious, since Emacs came from an
environment where implementing things in Lisp was not a strange idea, to put
it rather mildly.
27 Feb
27 Feb
12:32 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
"Ron Natalie" <ron(a)ronnatalie.com> writes:
RMS credits Multics Emacs with the idea to use Lisp as the extension
language:
The language that you build your extensions on shouldn't be thought
of as a programming language in afterthought; it should be designed
as a programming language. In fact, we discovered that the best
programming language for that purpose was Lisp.
It was Bernie Greenberg, who discovered that it was. He wrote a
version of Emacs in Multics MacLisp, and he wrote his commands in
MacLisp in a straightforward fashion. The editor itself was written
entirely in Lisp. Multics Emacs proved to be a success great
programming new editing commands was so convenient that even the
secretaries in his office started learning how to use it.
https://www.gnu.org/gnu/rms-lisp.html
I'd have
to check the chronology but I'm fairly sure that EINE
predates Gosling Emacs by several years: I'd assume that either EINE
is where Gosling got the idea, or that it was just obvious, since
Emacs came from an environment where implementing things in Lisp was
not a strange idea, to put it rather mildly.
Tim is right. EINE predates
Gosling's EMACS by a few years. Of course,
it uses LISP as an extension language not because they thought that would be
novel but since the whole thing was implemented in LISP to begin with (much
as you could extend the TECO EMACS with more TECO). 
10:04 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Lars Brinkhoff <lars(a)nocrew.org> wrote:
RMS credits Multics Emacs with the idea to use Lisp as the extension
language: [snip] https://www.gnu.org/gnu/rms-lisp.html
There's a nice history / retrospective of Multics Emacs at
http://www.multicians.org/mepap.html
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h punycode
Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later.
Moderate or rough, occasionally very rough later. Rain or showers. Moderate or
good.
28 Feb
28 Feb
5:51 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Really fascinating reading (the emacs history essay). I had more or less
gone through a similar thought process in my own editor experiments, such
as a failed attempt to provide full screen editing for email in
TheMajorBBS, it's a difficult and fascinating problem and the dicussion of
FNP char-at-a-time patches is quite revealing in regards to the limitations
(both physical and idealogical) that prevailed with early mainframes.
cheers, Nick
On Feb 28, 2017 3:05 AM, "Tony Finch" <dot(a)dotat.at> wrote:
Lars Brinkhoff <lars(a)nocrew.org> wrote:
RMS credits Multics Emacs with the idea to use Lisp as the extension
language: [snip] https://www.gnu.org/gnu/rms-lisp.html
There's a nice history / retrospective of Multics Emacs at
http://www.multicians.org/mepap.html
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ - I xn--zr8h
punycode
Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later.
Moderate or rough, occasionally very rough later. Rain or showers.
Moderate or
good.
26 Feb
26 Feb
10:22 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Feb 26, 2017 10:52 AM, "Joerg Schilling" <schily(a)schily.net> wrote:
Tim Bradshaw <tfb(a)tfeb.org> wrote:
GNU
Emacs has elisp which *is* a Lisp (albeit a fairly horrid one).
OK, then Gosling just had the idea of including lisp.
IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an
extension language. GNU EMACS is mostly written in LISP, with the C mainly
being used to implement the LISP interpreter. That's a pretty big
architectural difference there.
Mike
> On 26 Feb 2017, at 14:54, Joerg Schilling <schily(a)schily.net> wrote:
>
> GNU EMACS is based on the Gosling EMACS and this did already include
the LISP
interpreter.
Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp.
10:36 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Gosling Emacs was indeed written in C. But so is/was GNU EMACS. It started by outright
stealing not only one of Gosling’s earlier (pre-commercial) releases but RMS made off with
improvements done at UNIPRESS.
However, after much wrangling between James, Unipress, and RMS, RMS backed out the stuff
stolen from UNIPRESS and chucked out Gosling’s “mocklisp” interpretter for what RMS felt
was a more correct “mlisp” implementation. Of course, most of the lisp stuff was
largely original to RMS’s project. This accounts for the really anti-UNIX ugliness in
some of his keybindings that is always the thing I program when I have to use a Xemacs
implementation (who the hell thought using BACKSPACE for “help” was a good idea? Well I
know who, his maloderous self used to show up at my house from time to time).
My coworkers always used to laugh at me. If there was no EMACS-like editor on the
machine (I also variously used Montgomery’s EMACS and finally JOVE) on smaller machines
that GosMacs was too heavy for), I would just use “ed” (having been a master of that from
when that was all there was). I never learned vi, and if I was stuck using it, I ran it
in ex mode. I had a brief stint with the RandEditor AKA Interactive Systems editor
derived from it (InED).
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Michael Kerpan
Sent: Sunday, February 26, 2017 11:23 AM
To: tuhs(a)tuhs.org
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years?
On Feb 26, 2017 10:52 AM, "Joerg Schilling" <schily(a)schily.net> wrote:
Tim Bradshaw <tfb(a)tfeb.org> wrote:
OK, then Gosling just had the idea of including lisp.
IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an extension
language. GNU EMACS is mostly written in LISP, with the C mainly being used to implement
the LISP interpreter. That's a pretty big architectural difference there.
Mike
On 26 Feb 2017, at 14:54, Joerg Schilling
<schily(a)schily.net> wrote:
GNU EMACS is based on the Gosling EMACS and this did already include the LISP
interpreter.
Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs
has elisp which *is* a Lisp (albeit a fairly horrid one). 
27 Feb
27 Feb
12:01 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Ron Natalie wrote:
Gosling Emacs was indeed written in C. But so is/was GNU EMACS. It
started by outright stealing not only one of Gosling’s earlier
(pre-commercial) releases but RMS made off with improvements done at
UNIPRESS.
However, after much wrangling between James, Unipress, and RMS, RMS
backed out the stuff stolen from UNIPRESS and chucked out Gosling’s
“mocklisp” interpretter for what RMS felt was a more correct “mlisp”
implementation. Of course, most of the lisp stuff was largely
original to RMS’s project. This accounts for the really anti-UNIX
ugliness in some of his keybindings that is always the thing I program
when I have to use a Xemacs implementation (who the hell thought using
BACKSPACE for “help” was a good idea? Well I know who, his
maloderous self used to show up at my house from time to time).
My coworkers always used to laugh at me. If there was no EMACS-like
editor on the machine (I also variously used Montgomery’s EMACS and
finally JOVE) on smaller machines that GosMacs was too heavy for), I
would just use “ed” (having been a master of that from when that was
all there was). I never learned vi, and if I was stuck using it, I
ran it in ex mode. I had a brief stint with the RandEditor AKA
Interactive Systems editor derived from it (InED).
Interesting how the Rand Editor seems to have been the choice of many.
Perkin-Elmer (later Concurrent) based their in-house office automation
software
("Paper Free in '83.") On dog-slow UniPlus SysIII (IIRC -- later
MicroXelos
UniPlus SysV based I think) on 68000 cpu 8 mhz machines. No virtual memory
a dog-crap slow video subsystem.
Of course I got a truck load of them when they dumped them and I used
them to do the two county wide newsfeed until the PC Unix stuff
became available.
http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf
The nice one I had was an XF200 MicroXelos box -- which was RARE.
It was a minitower without the graphics and with room for a pair of
80mb MFM drives.
Did one of 'em for system and user accts and one for partial newsfeed.
--
Digital had it then. Don't you wish you could buy it now!
pechter-at-gmail.com http://xkcd.com/705/
12:40 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Tim Bradshaw <tfb(a)tfeb.org> writes:
There's also no real doubt that RMS was
responsible for Emacs *as an
idea* as opposed to any particular implementation (Guy Steele is I
think the other person who might be held responsible, but I believe
he's said that it was RMS, which is good enough for me).
Here's what they wrote about that 6 Jul 1978.
RMS:
The work done by GLS was
a) to consider a large number of possible command sets, and
suggest many interesting possible commands, and
b) to begin doing actual work (on the purifier and start-up).
Although none of this code survived after a week or so, I might
never have been able to start doing anything if left to myself.
I often have trouble getting off the ground.
GLS:
The account of my involvement given by RMS is essentially accurate.
I started [EMACS] because I was getting tired of the kludginess of
the TCMAC command arrangement, and saw in other editors neat
commands that could not be fit cleanly into TECMAC. I therefore
decided to perform a total reorganization of the command structure,
and carefully examine all the other existing TECO-based editors,
such as RMODE, DOC, and the ever-popular TMACS. Most of my work
involved playing with assignments of commands to keys, and running
around organizing discussions and soliciting comments. I made an
initial stab at a loader, and I think I invented (or re-invented)
the notion of a compressing loader, and invented most of the
specific conventions for the EMACS loader (such as using _ for a
space), though these conventions were greatly refined later. It was
at about this point that RMS and others took over the development
work, and did a much better job, much faster, than I could have.
For this reason, as well as the pressure of classes and the
maintenance of LISP, I was happy to let others take over [EMACS].
Thus, while I provided initial impetus and much of the original
user-level command structure, most of the development work and
succeeding refinements is to the credit of other people.
26 Feb
26 Feb
10:06 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017, at 14:19, Michael Kerpan <madcrow.maxwell(a)gmail.com> wrote:
My supposition is that EMACS was basically Stallman's attempt to bring in all the
things he liked about the LISP Machine environment into the Unix world through the back
door.
I think this is at least partly right, although either RMS didn't like most of the
really interesting things about the LispM environments or he was not involved in many of
the developments which made them interesting: I suspect at least partly the latter as he
presumably stopped being involved when Symbolics became seriously independent from the MIT
AI lab and/or the hardware became too divergent (the 3600 I guess: I don't know if
the AI lab had lots of those, they were certainly eye-wateringly expensive for those of us
bought up on Suns). It may also be that a lot of the LispM stuff was genuinely hard to
support on hardware which, for instance, wanted to distinguish between the OS and userland
in any serious way until much later, although I'm reluctant to believe that.
Slightly more on-topic, it seems to me really interesting that both the LispM & Unix
environments really aim at providing comfortable places for programmers to work in, and
specifically for the people writing the OS to work in (as opposed to some other OSs which
clearly were more aimed at production applications) but they did it in such enormously
different ways. Some of this has been fairly well-explored I think, by the famous
'worse is better' paper & its successors, but I don't think that's
the whole answer.
Both Unix and the LispMs encourage a way of working where you build little tools to do
things, often things that get used only a few times, but the *way* you do that is
completely different. And Unix is ultimately the better answer I think, because you can
build a LispM-type environment on Unix but you can't realistically do it the other
way around (the filesystem on LispMs was not up to what you'd want to run a
Unix-style world on top of it, for one thing).
So I don't think that this has really been sorted-out yet: certainly I'm
confused and I've spent a lot of time in both worlds.
--tim
10:30 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Slightly more on-topic, it seems to me really
interesting that both the
LispM & Unix environments really aim at providing
comfortable places for
programmers to work in, and specifically for the people writing the OS to
work in (as opposed to some other OSs which clearly were more aimed at
production applications) but they did it in such enormously different ways.
Isn't that what Programmer's WorkBench was alp about. We had picked up
random stuff out of PWB (notably the shell) at JHU, but didn't really use
the PWB aspects of it. My first job after college (intermixed with writing
some design documents for the database system I was supposed to be working
on ) was helping the QA department setup the procedures to use PWB (SCCS and
various other things) to implement the software engineering environment.
While PWB was sort of targeted on RJE submittal to IBM mainframes, we were
using it to control the software development for a RSX-11M based
intelligience system.
11:15 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
RMS had pretty much left both the LISP machine and the DEC MAINFRAME (TOPS20 and ITS) by
the time he got around to creating EMACS, he started GNU because he wanted a new super
system and he figured starting with UNIX which he regarded (if you read the manifesto) as
incredibly deficient. The idea was to come up with a new UNIX-ish kernel with all the
crap he had come accustomed to on the LISP machines and iTS. Of course, he got run over
by LINUX along the way.
11:20 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017 12:15 -0500, from ron(a)ronnatalie.com (Ron Natalie):
Of course, he got run over by LINUX along the way.
...and even today, while the GNU userland sees reasonable use (just
about every Linux distribution targetting the desktop or server niches
use it, except for the few minimalistic ones that rely primarily on
Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
a life of obscurity and few even know what it is, let alone knows
anyone who uses it for anything even half-way serious.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
11:23 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
I didn't say that GNU wasn't a necessary part, it's just I think RMS feels
he lost control of things when LINUX displaced his plans for the kernel. Obviously, much
of the user mode is entirely beholden to the GNU project starting with GCC and the run
tlime libraries. The only major system that really isn't is the display system
which is X.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Michael Kjörling
Sent: Sunday, February 26, 2017 12:20 PM
To: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017 12:15 -0500, from ron(a)ronnatalie.com (Ron Natalie):
Of course, he got run over by LINUX along the way.
...and even today, while the GNU userland sees reasonable use (just about every Linux
distribution targetting the desktop or server niches use it, except for the few
minimalistic ones that rely primarily on Busybox, so it's pretty hard to run Linux
and not GNU), GNU Hurd lives a life of obscurity and few even know what it is, let alone
knows anyone who uses it for anything even half-way serious.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
11:33 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sun, 26 Feb 2017, Michael Kjörling wrote:
On 26 Feb 2017 12:15 -0500, from ron(a)ronnatalie.com
(Ron Natalie):
I've thought of implementing a system using musl, clang and the Solaris
userland on Linux just to prove that not all Linux is GNU/Linux. (As if
Android doesn't always prove that.)
-uso.
Of course, he got run over by LINUX along the
way.
...and even today, while the GNU userland sees reasonable use (just
about every Linux distribution targetting the desktop or server niches
use it, except for the few minimalistic ones that rely primarily on
Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
a life of obscurity and few even know what it is, let alone knows
anyone who uses it for anything even half-way serious.
11:39 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 26 Feb 2017 12:33 -0500, from usotsuki(a)buric.co (Steve Nickolas):
On Sun, 26 Feb 2017, Michael Kjörling wrote:
Yes, Android of course being the obvious counterexample to what I
wrote, which I thought of only after hitting send. Sorry.
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
...so it's pretty hard to run Linux and not
GNU...
I've thought of implementing a system using musl, clang and the
Solaris userland on Linux just to prove that not all Linux is
GNU/Linux. (As if Android doesn't always prove that.)
11:39 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
Personally, I'd like to see something using the Heirloom Tools userspace.
Heirloom *roff, in particular, is miles ahead of GNU (especially when
dealing with fonts) while also being much lighter weight. The only bit of
GNU that I'd keep in my "ideal" OS would be GCC, which still produces
better output than Clang.
Mike
On Feb 26, 2017 12:33 PM, "Steve Nickolas" <usotsuki(a)buric.co> wrote:
On Sun, 26 Feb 2017, Michael Kjörling wrote:
On 26 Feb 2017 12:15 -0500, from ron(a)ronnatalie.com (Ron Natalie):
I've thought of implementing a system using musl, clang and the Solaris
userland on Linux just to prove that not all Linux is GNU/Linux. (As if
Android doesn't always prove that.)
-uso.
Of course, he got run over by LINUX along the
way.
...and even today, while the GNU userland sees reasonable use (just
about every Linux distribution targetting the desktop or server niches
use it, except for the few minimalistic ones that rely primarily on
Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives
a life of obscurity and few even know what it is, let alone knows
anyone who uses it for anything even half-way serious.
27 Feb
27 Feb
1:33 a.m.
New subject: roff
On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael Kerpan wrote:
Personally, I'd like to see something using the
Heirloom Tools userspace.
Heirloom *roff, in particular, is miles ahead of GNU (especially when
dealing with fonts) while also being much lighter weight.
What's better about the old roff? The new roff has some pic enhancements
that I like. I suspect the old roff includes grap, be nice to have that.
1:36 a.m.
New subject: roff
Amusingly someone sent me a document not that far back with a table in it.
I said "Did you use PIC and TBL with this?" He admitted he did. It had
the little tell tail stray overshoots on the vertical lines. I would have
thought someone would have fixed that in the interim.
1:46 a.m.
New subject: roff
On Sun, Feb 26, 2017 at 2:36 PM, Ron Natalie <ron(a)ronnatalie.com> wrote:
Amusingly someone sent me a document not that far back
with a table in it.
I said "Did you use PIC and TBL with this?" He admitted he did. It
had
the little tell tail stray overshoots on the vertical lines. I would have
thought someone would have fixed that in the interim.
When I was getting deployed to Afghanistan, we were given a little
laminated card with a "cheat sheet" of important bits of radio protocol on
it: how to call for a casualty evacuation, unexploded ordinance (I had to
use that one once, btw...), a thing called a MIST report that detailed
injuries, etc.
Anyway, something about the fonts and I *knew* it had been written using
troff. Of course, we didn't have the source, just the card...so I sat down
and recreated it. I printed a whole bunch out, laminated them and gave them
to my Marines to hang onto. I probably still have the PIC file laying
around my directory somewhere.
- Dan C.
1:41 a.m.
New subject: roff
Heirloom roff, as maintained at
https://github.com/n-t-roff/heirloom-doctools, started with the code
released as part of OpenSolaris and added UTF-8 support, support for
various key bits added by groff, and then support for various modern
"smartfont" features, as well as the ability to use modern font files
directly rather than having to jump through various hoops. The whole
package is much lighter than groff while also having more (useful)
features and not having --very-long-options-like-this
Mike
On Sun, Feb 26, 2017 at 2:33 PM, Larry McVoy <lm(a)mcvoy.com> wrote:
On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael
Kerpan wrote:
Personally, I'd like to see something using
the Heirloom Tools userspace.
Heirloom *roff, in particular, is miles ahead of GNU (especially when
dealing with fonts) while also being much lighter weight.
What's better about the old roff? The new roff has some pic enhancements
that I like. I suspect the old roff includes grap, be nice to have that.
3:27 a.m.
New subject: roff
Michael Kerpan <madcrow.maxwell(a)gmail.com> wrote:
Heirloom roff, as maintained at
https://github.com/n-t-roff/heirloom-doctools, started with the code
This is where troff used to be maintained until around summer 2011.
While most heirloom programs did only get attention for aprox. 3 months, troff,
mailx and vi have been maintained for a longer time.
Then, since aprox. 6 years ago no traces to Gunnar Ritter have been seen in
the net anymore.
Fortunately, mailx and troff now have new maintainers and can be found on
github.
troff now is at: https://github.com/n-t-roff/heirloom-doctools
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
3:28 a.m.
New subject: roff
schily(a)schily.net (Joerg Schilling) wrote:
Michael Kerpan <madcrow.maxwell(a)gmail.com>
wrote:
Sorry for my fault, I thought I did see sourceforge here instead of github.
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Heirloom roff, as maintained at
https://github.com/n-t-roff/heirloom-doctools, started with the code
This is where troff used to be maintained until around summer 2011. 
7:59 p.m.
New subject: roff
schily(a)schily.net (Joerg Schilling) wrote:
..
|Fortunately, mailx and troff now have new maintainers and can be found on
|github.
We, the former and i that is, are not on github. I was shortly in
i think 2011, and i wanted to pay (because they paid (at least)
a developer, Jeff King, for working on Git), but they rejected my
clouts and only desired virtual clowds, but you know, the
low-payment sector is already flooded, in our local bank we not
longer than ten years ago had bank tellers, you know, that Arthur
Hailey Money-Changers story that i have read on the seventies,
these targets for Bonnie and Clyde, and other cicadas, now all
that robots instead, i think the tellers are now licking the
runway of Frankfurt airport speckless or something. No.
--steffen
1 Mar
1 Mar
2:15 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Sun, 26 Feb 2017, Noel Chiappa wrote:
Somewhere Out There (tm) is a web page full of EMACS acronyms.
Another
acronym is Esc Meta Alt Ctl Shift...
Good one! And there was a pretty funny fake Exxx error code - I
think it was
"EMACS - Editor too big"?
"Editor too large"; it was in a list of fake error messages in a Usenix
article. Another was ENOTOBACCO - Read on empty pipe.
I was never happy with the size of EMACS, and it had
nothing to do with
the amount of memory resources used. That big a binary implies a very
large amount of source, and the more lines of code, the more places for
bugs... And it makes it harder to understand, for someone working on it
(to make a change/improvement).
I tried EMACS once (so I couldn't be accused of criticising it without
trying it) and immediately ran back to the comfort of VI.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
7:31 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Tue, 28 Feb 2017, Lars Brinkhoff wrote:
Wow - thanks!
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will
suffer."
Somewhere Out
There (tm) is a web page full of EMACS acronyms.
Or distributed with Emacs: etc/JOKES. 
2:40 a.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On Feb 28, 2017, at 21:15, Dave Horsfall <dave(a)horsfall.org> wrote:
"Editor too large"; it was in a list of fake error messages in a Usenix
article. Another was ENOTOBACCO - Read on empty pipe.
ENOTOBACCO was the winner of the EUUG errno contest (I think Florence
meeting). There were a couple of these contests. There should be
a video somewhere where the jury is singing the winning entry of
the Atlanta one. A description of the Nashville one can be found
at <http://www.qef.com/html/docs/egregious.pdf>.
jaap
6:45 p.m.
New subject: Un-released/internal/special UNIX versions/ports during the years?
On 28 Feb 2017 21:40 +0100, from jaapna(a)xs4all.nl (Jaap Akkerhuis):
ENOTOBACCO was the winner of the EUUG errno contest (I
think Florence
meeting). There were a couple of these contests.
Here's one: https://www.gnu.org/fun/jokes/errno.2.html
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
2852
days inactive
2855
days old
38 comments
18 participants
participants (18)
-
Angelo Papenhoff -
Dan Cross -
Dave Horsfall -
Jaap Akkerhuis -
jnc＠mercury.lcs.mit.edu -
Larry McVoy -
Lars Brinkhoff -
Michael Kerpan -
Michael Kjörling -
Nick Downing -
Ron Natalie -
schily＠schily.net -
Steffen Nurpmeso -
Steve Nickolas -
tfb＠tfeb.org -
Tim Bradshaw
-
Tony Finch -
William Pechter