ss (04/19/83)
I just had a horrible thought - naturally I want everyone else to feel
horrible too, or put me out of my misery.
When 4.2bsd comes out, and mpio goes away, emacs will stoip functioning.
(Won't it?) Since James has turned EMACS over to someone
who is chargine real money (not that I blame him), does this mean
that we will all have to fork over some money, or not run 4.2, or
not run EMACS???? What a choice!!!
Sid Shapiro -- {decvax,linus}!wivax!ss -- Wang Institute
ss.Wang-Inst@UDel-Relay -- (617)649-9731thomas (04/20/83)
As I have announced earlier, I have a fix for mchan.c which will allow it to work even under 4.2bsd. This is available for the current version of emacs (i.e., the last "free" version) upon request. My only condition is that you bear with my response time, I am trying to get a thesis done in my "copious spare time". =Spencer
mrose%uci-750a%Rand-Relay@sri-unix.UUCP (02/10/84)
From: Tim Morgan <mrose%uci-750a@Rand-Relay> I have a version of Emacs (#85) that runs well under 4.2BSD. In order to get it though, you need to show me proof that you have a bona fide, official Emacs #85 (or previous) from Gosling. This version has all of the process control modifications made by Chris Torek and Spencer Thomas and all the maclib stuff works well (including an asynchronous "man" and "spell" package). /mtr
israel@umcp-cs.UUCP (02/12/84)
From: David Chase <rbbb@rice>
On a different subject, is anyone else annoyed at the number of
cmu-specific hacks in the maclib? As distributed, "man" and
"lisp" fail, for lack of some pathname with a cmu in it, and
for lack of cmulisp.
Yeah I know what you mean. We just installed Unipress Emacs, and I
just got finished doing what I do whenever I receive a new Mlisp package
or maclib; I diff against our version and integrate the two. This time
I kept a simple log detailing what each package is, whether its local
or not, and whether I had to do any fixing. I want to forward this
stuff to Unipress since I've got a lot of fixes and extensions to
distributed packages, and also packages that aren't in the standard
distribution at all. Has anyone had any contact with Unipress about
such a thing? I was a little miffed about them since some of that
packages had minor bugs that stops them from being run, and some from
even being loaded successfully!!! Don't they check that stuff before
distributing it to paying customers?
About the CMU specific things; that doesn't bother me that much since
I usually have to change pathnames anyway to local paths, and we run
regular franz and not CMUlisp. But that stuff should be un-CMU-ized
by Unipress be distribution. In fact, one thing that came with the
distribution was a package called 'whist.ml' that had the follwing
comment in the top of it.
; This package implements the whist function to write
; history messages (just the same as whist on Unix).
Now I don't know about your system, but we don't have a 'whist' on our
4.1bsd system, and in fact I have absolutely no idea about what it
does!!! Oh well, what I've done with it is move it to our 'unused'
directory (for Mlisp files that are inapplicable, unintelligible,
ridiculous, superceded, or otherwise unused by our local populace).
After I get the LOG file mentioned above cleaned up, I'd like to
distribute it over this list and maybe get it filled out with any
new packages and modified versions of old packages out there. Then
maybe we can have an organized way of finding out what packages there
are and trading them. Some of these packages came with the Unipress
distribution which they are selling. I was wondering what the story
is about redistributing those since you have to pay money for them.
The old packages aren't a problem, since they came with the free
version of Gosling's emacs. Anyone know the story on this?
--
Bruce Israel
University of Maryland, Computer Science
{rlgvax,seismo}!umcp-cs!israel (Usenet) israel.umcp-cs@CSNet-Relay (Arpanet)rbbb%rice@sri-unix.UUCP (02/14/84)
From: David Chase <rbbb@rice> We have brought up emacs under 4.2, and most of it works about the same as it ever did, but some of the process control stuff doesn't at all. Is the bug/fix in mchan.c, or should the process package be fixed? Specifically, when running a shell or lisp, typing control-D does nothing at all. We tried inserting a control-D, and that worked in certain situations, but not all. drc
rbbb%rice@sri-unix.UUCP (02/14/84)
From: David Chase <rbbb@rice> We (Mike Caplinger and I) have brought up Gosling's emacs under 4.2, and most of it works about the same as it ever did, but some of the process control stuff doesn't at all. Is the bug/fix in mchan.c, or should the process package be fixed? We are using version 264, mutated from a version that ran on a Sun. To recreate this bug (if other people can indeed recreate it) fire up a lisp or a shell, and type control-D. It doesn't exit. I rather suspect mchan, because invoking "eot-process" by hand didn't work either. Does someone out there have a diff listing against Unipress's original 4.1 distribution? On a different subject, is anyone else annoyed at the number of cmu-specific hacks in the maclib? As distributed, "man" and "lisp" fail, for lack of some pathname with a cmu in it, and for lack of cmulisp. drc
guido@mcvax.UUCP (Guido van Rossum) (02/17/84)
Eot-process doesn't work because the kernel doesn't implement it. The
4.2 manual page pty(4) states under the description of TIOCREMOTE how
an eot should be sent: "a write of 0 bytes is like typing an end-of-file
character". However, the BUGS section tells us: "It is not possible to
send an EOT". (This was not present in the 4.1c version of the manual.)
Inspection of the kernel code shows that some attempts are made to
handle writes of 0 bytes special, but somehow this doesn't make it to
the other end of the line.
Someone at our site hacked the 4.1c version to use the master tty in
normal mode rather than TIOCREMOTE mode, thus with input editing
enabled, and to send a control-D character. This worked, but had the
disadvantage that processes in windows could influence the tty status
with stty system calls. Later we reverted to an "official" version.
--
Guido van Rossum, {philabs,decvax}!mcvax!guido
Centre for Mathematics and Computer Science, (CWI, formerly MC), Amsterdamchris@umcp-cs.UUCP (02/18/84)
In the MRose/CAK/Thomas/Torek 3-file system, we make the pty work
like a normal tty, and fetch the appropriate EOF character before
sending it. (I think. *When* will the lawyers let the University
sign that agreement?!)
Who knows, maybe UniPress will be distributing that code soon.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay