[comp.emacs] Grrr... uEmacs 3.10 doesn't work under Xenix

spolsky-joel@CS.Yale.EDU (Joel Spolsky) (04/10/89)

Argh! Version 3.10 of MicroEmacs no longer works in Xenix.

I spent several hours just getting the blasted thing to compile at
all, but now various things don't work

--- function and cursor keys
--- filename completion
--- the mode line isn't reverse video

SCO Xenix 2.3.2 on a compaq 386.

I'll bet there are other things that are now broken, that didn't used
to be.

If anybody has any solutions yet I'd love to hear them...

+----------------+----------------------------------------------------------+
|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
+----------------+----------------------------------------------------------+
                                                      #include <disclaimer.h>

rock@rancho.uucp (Rock Kent) (04/10/89)

In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes:

   Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
      [followed by some specifics followed by]
   I'll bet there are other things that are now broken, that didn't used
   to be.

   If anybody has any solutions yet I'd love to hear them...

Switch to GNU emacs.

***************************************************************************
*Rock Kent    rock@rancho.uucp        POB 8964, Rancho Sante Fe, CA. 92067*
***************************************************************************

jbayer@ispi.UUCP (Jonathan Bayer) (04/10/89)

In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes:
>
>Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
>
>I spent several hours just getting the blasted thing to compile at
>all, but now various things don't work
>
>--- function and cursor keys
>--- filename completion
>--- the mode line isn't reverse video


I have had the same experience.  I think that some of the above
mentioned problems may be due to an incorrect .emacsrc file.  I haven't
had a chance to do anything more than get it to compile and execute.

If Daniel Lawrence is on the net please respond.  In the meantime, I
will be working on it during the week and may figure out what is wrong
before I start doing my local modifications.  As of now the only files I
had to modify were:

	unix.c
	etype.h
	bind.c
	estruct.h

	Makefile, which was copied from makefile.unx

I also had to create a proto.h file, which contains prototypes of all
the functions.  The etype.h file now included the proto.h file, and all
the simple function definitions in etype.h are commented out.


JB
-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
19 Virginia Ave.				...uunet!ispi!jbayer
Rockville Centre, NY 11570  (516) 766-2867    jbayer@ispi.UUCP

nwd@j.cc.purdue.edu (Daniel Lawrence) (04/11/89)

In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes:
>
>Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
>
>I spent several hours just getting the blasted thing to compile at
>all, but now various things don't work
>
>--- function and cursor keys
>--- filename completion
>--- the mode line isn't reverse video
>
>SCO Xenix 2.3.2 on a compaq 386.
>
>I'll bet there are other things that are now broken, that didn't used
>to be.
>
>If anybody has any solutions yet I'd love to hear them...
>
>+----------------+----------------------------------------------------------+
>|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
>|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
>+----------------+----------------------------------------------------------+
>                                                      #include <disclaimer.h>

	Hello,

		Getting one stable version on many different platforms
is not always the easiest, especially in ones spare time.  

	I am ready and willing to take any donations of hardware and
software which will allow me to run XENIX.  At the moment, I have to
arrange, by apointment, to use equipment at a nearby company, taking
vacation days from my job to be able to do it in the buisness day.

	That is not to say I am not preparing XENIX, it just might take
a little while.  Also VMS users out there should hold on, a good set of
fixes with both a SMG and a VT220 style driver are being folded in now.

	And a little other good news... FINALLY... our computer center
here has gotten the internet connection up to my workstation.  Details
on anonymous FTP connections to it will be posted soon.

					Daniel Lawrence
					(317) 742-5153 nwd@j.cc.purdue.edu
					The Programmer's Room Fido 1:201/10
					(317) 742-5533

PS:	If you must get 3.10 running on XENIX immediatly...

	go into unix.c and add a "& 0" the the line

#if	COMPLET

	and go into tcap.c in the tcapgetc() function and add &0 to the:

#if	XENIX | SUN

	line.  This will get it running, without file name completion
and function key recognition.

usenet@cps3xx.UUCP (Usenet file owner) (04/11/89)

in article <199@rancho.uucp>, rock@rancho.uucp (Rock Kent) says:
$ Xref: cps3xx comp.emacs:5843 comp.unix.xenix:5901
$ In-reply-to: spolsky-joel@CS.Yale.EDU's message of 9 Apr 89 18:41:24 GMT
$ 
$ In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU (Joel Spolsky) writes:
$ 
$    Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
$       [followed by some specifics followed by]
$    I'll bet there are other things that are now broken, that didn't used
$    to be.
$ 
$    If anybody has any solutions yet I'd love to hear them...
$ 
$ Switch to GNU emacs.
$ 
I'd love to run GNU Emacs on my Xenix system. But with only 4MB of
memory, a 42MB SCSI disk, and a 12.5MHz 286 that's not enough resources
to run GNU in a nice manner. (read: not enough resources for a resource
hog) Don't get me wrong, I love GNU Emacs and would love to run nothing
else, but not a machine this small. MicroEmacs is my only other feasible
choice. Ver 3.9e is only a 120K image on the disk and won't consume
a quarter of my free disk space with runtime files.

John H. Lawitzke           UUCP: Work: ...rutgers!mailrus!frith!jhl
Dale Computer Corp., R&D               ...decvax!purdue!mailrus!frith!jhl
2367 Science Parkway                   ...uunet!frith!jhl
Okemos, MI, 48864                Home: ...uunet!frith!ipecac!jhl

daveh@marob.MASA.COM (Dave Hammond) (04/11/89)

In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU writes:
>
>   Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
>      [followed by some specifics followed by]
>   I'll bet there are other things that are now broken, that didn't used
>   to be.
>
>   If anybody has any solutions yet I'd love to hear them...

If this concerns recompilation with the 2.3 dev sys, I've found a few
things which broke (especially curses-based programs) because code
which formerly declared vars as "char" needed to be "unsigned char".
Mush is one program which comes to mind.  I'm not sure if the specs of the
C library functions originally called for unsigned chars, and the
programmers in question assumed char == unsigned char, or the specs changed
with the 2.3 release.

--
Dave Hammond
daveh@marob.masa.com

davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/12/89)

In article <9313@j.cc.purdue.edu> nwd@j.cc.purdue.edu (Daniel Lawrence) writes:

| 	That is not to say I am not preparing XENIX, it just might take
| a little while.  Also VMS users out there should hold on, a good set of
| fixes with both a SMG and a VT220 style driver are being folded in now.

  I think we may have failed to make it clear that support for ANSI
keysequences is needed in UNIX versions. Termcap support won't do it. I
posted fixes for this in every version from 3.7? to 3.10beta and none of
them ever got picked up.

  Earlier I posted the logic which allows this to work on all versions
of UNIX (at least seven I use uncluding BSD, SysV and Xenix) and which
was in the fix I posted for 3.10beta.

  I have offered several times to test versions on memacs on Xenix and
have never been contacted. I expect to have a fix out by the end of
April for 3.10 and will post it.
-- 
	bill davidsen		(wedu@crd.GE.COM)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

wrp@biochsn.acc.Virginia.EDU (William R. Pearson) (04/12/89)

]$    Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
]$ 
]$ Switch to GNU emacs.
]$ 
]I'd love to run GNU Emacs on my Xenix system. But with only 4MB of
]memory, a 42MB SCSI disk, and a 12.5MHz 286 that's not enough resources
]to run GNU in a nice manner. (read: not enough resources for a resource
]hog)

	Switching to GNUemacs is impossible for many of us, but I have
been extremely happy with the Lugaru Epsilon product for Xenix (and
DOS).  It costs about $195, and is worth every penny. I just wish
I could use it on larger machines.

Bill Pearson

jbayer@ispi.UUCP (Jonathan Bayer) (04/12/89)

In article <613@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>In article <56344@yale-celray.yale.UUCP> spolsky-joel@CS.Yale.EDU writes:
>>
>>   Argh! Version 3.10 of MicroEmacs no longer works in Xenix.
>
>If this concerns recompilation with the 2.3 dev sys, I've found a few
>things which broke (especially curses-based programs) because code


uEmacs does not use curses.  The problems seem to be in untested code.



JB

-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
19 Virginia Ave.				...uunet!ispi!jbayer
Rockville Centre, NY 11570  (516) 766-2867    jbayer@ispi.UUCP

jbayer@ispi.UUCP (Jonathan Bayer) (04/12/89)

In article <13576@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>
>  I think we may have failed to make it clear that support for ANSI
>keysequences is needed in UNIX versions. Termcap support won't do it. I
>posted fixes for this in every version from 3.7? to 3.10beta and none of
>them ever got picked up.

Why?  What is the matter with reading the termcap entry and interpreting
the keys according to the termcap info?  Why must the keys for ANSI be
hardcoded into the program, therefore increasing the program size and
complexity?  I have been able to make version 3.10 work with all the
keys on my keyboard by simply installing the appropriate modification to
my termcap file. (For those who don't know the modification added the
function key definitions to the termcap entry).  By using the termcap
entry it is now possible to use eEmacs on several different terminals,
and being able to use whatever function keys are available knowing that
their function will be the same.  I think that the current solution is
much better than a hardcoded one.



JB
-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
19 Virginia Ave.				...uunet!ispi!jbayer
Rockville Centre, NY 11570  (516) 766-2867    jbayer@ispi.UUCP

davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/13/89)

In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:

| Why?  What is the matter with reading the termcap entry and interpreting
| the keys according to the termcap info?  Why must the keys for ANSI be
| hardcoded into the program, therefore increasing the program size and
| complexity?  I have been able to make version 3.10 work with all the

  For someone on one machine, who is root, changing termcaps is just
fine. When running on a number of machines for which you may not have
permission to change the /etc/termcap file, and when you have two years
of accumulated emacs macros, you would like to not reinvent the world.

| and being able to use whatever function keys are available knowing that
| their function will be the same.  I think that the current solution is
| much better than a hardcoded one.

  This is not in keeping with the portable approach. You could just as
well decide the VMS is better than UNIX so pull support out for UNIX.
There are a lot of people who have been using memacs in one mode who
would like to continue. It would be better to have one set of changes
installed by the author than a group of changes done by various people.
The VT100 option for keystrokes is just another option like AMIGA or
IBMPC. It shouldn't require taking one useful thing out to add another.
-- 
	bill davidsen		(wedu@crd.GE.COM)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

spolsky-joel@CS.YALE.EDU (Joel Spolsky) (04/13/89)

In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>In article <13576@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>>  I think we may have failed to make it clear that support for ANSI
>>keysequences is needed in UNIX versions. Termcap support won't do it. I
>>posted fixes for this in every version from 3.7? to 3.10beta and none of
>>them ever got picked up.
>
>Why?  What is the matter with reading the termcap entry and interpreting
>the keys according to the termcap info?  

Jonathan, I'm going to have to come out against this one. TERMCAP was
never a good solution to keyboard problems. VERY FEW terminals are
correctly set up in standard /etc/termcap files, even if they were,
uEmacs 3.10 wants to use non-standard termcap entries for home, end,
pgdown, etc.  There is no question that TERMCAP is not robust enough
or well enough support for keyboards, especially in Xenix.

>Why must the keys for ANSI be
>hardcoded into the program, therefore increasing the program size and
>complexity?  

Some argument. The size of the uEmacs executable jumped about 50% from
3.9 to 3.10. A whole lot of difference a few ansi codes is going to
make. 

>I have been able to make version 3.10 work with all the
>keys on my keyboard by simply installing the appropriate modification to
>my termcap file.

Humph. I don't see why every poor joe slob that wants to use
microEmacs should have to (1) figure out that his function keys dont
work (2) find the source to uEmacs, (3) find that obscure comment in
tcap.c about the termcap (4) change the /etc/termcap file.

Chances are most users won't get to stage 3, and can't change the
/etc/termcap without the system administrator. Assuming that they
understand these things. Basically it's gotten twice as hard to get
uEmacs to work.

Essentially, as most Unix develpers have figured out, TERMCAP is NEVER a
realiable place to look for keyboard information. Especially in Xenix
where many users don't even set up or use the TERMCAP env. variable at all.

A more reasonable solution, and the one that GNU Emacs uses, is to
make it simple and reasonable to bind functions to the ANSI sequences,
instead of the unnecessary uEmacs step of binding to hypothetical key
names like FN< and FN>.

+----------------+----------------------------------------------------------+
|  Joel Spolsky  | bitnet: spolsky@yalecs.bitnet     uucp: ...!yale!spolsky |
|                | internet: spolsky@cs.yale.edu     voicenet: 203-436-1483 |
+----------------+----------------------------------------------------------+
                                                      #include <disclaimer.h>

nwd@j.cc.purdue.edu (Daniel Lawrence) (04/13/89)

In article <56803@yale-celray.yale.UUCP> spolsky-joel@CS.YALE.EDU (Joel Spolsky) writes:
>In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>>In article <13576@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>>>  I think we may have failed to make it clear that support for ANSI
>>>keysequences is needed in UNIX versions. Termcap support won't do it. I
>>>posted fixes for this in every version from 3.7? to 3.10beta and none of
>>>them ever got picked up.
>
	[long discusion of TERMCAP vs ANSI deleted...]

>Humph. I don't see why every poor joe slob that wants to use
>microEmacs should have to (1) figure out that his function keys dont
>work (2) find the source to uEmacs, (3) find that obscure comment in
>tcap.c about the termcap (4) change the /etc/termcap file.
>
>Chances are most users won't get to stage 3, and can't change the
>/etc/termcap without the system administrator. Assuming that they
>understand these things. Basically it's gotten twice as hard to get
>uEmacs to work.
>
	So, the 10,000 students here at Purdue would then have to
1) Fire up MicroEMACS, 2) figure out that they don't have an ANSI
terminal, 3) Curse me for not providing any support for the hundreds of
adm-3a, wyse, etc terminals around campus.  Chances are if users get to
stage 3 they will have to go in and write their own screen drivers to
get it to work at all.

	I am not resisting attempts to support your ansi driver, and
would be willing to provide it as well, I am just overloaded with things
to support on right now and I am desperatly trying to get all the
versions running now.

	As far as standards on UNIX are concerned, you and I and
hundreds of developers have been waiting around for one to come forth
for years now.  Is it time we decided to come up with one ourselves?

					Daniel Lawrence
					(317) 742-5153 nwd@j.cc.purdue.edu
					The Programmer's Room Fido 1:201/10
					(317) 742-5533

davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) (04/14/89)

In article <9332@j.cc.purdue.edu> nwd@j.cc.purdue.edu (Daniel Lawrence) writes:

| 	So, the 10,000 students here at Purdue would then have to
| 1) Fire up MicroEMACS, 2) figure out that they don't have an ANSI
| terminal, 3) Curse me for not providing any support for the hundreds of
| adm-3a, wyse, etc terminals around campus.  Chances are if users get to
| stage 3 they will have to go in and write their own screen drivers to
| get it to work at all.

  I don't think that anyone is suggesting that you should remove the
termcap support you have, but that the ANSI support which you have (more
of less) had for many versions has vanished.

  I don't blame you for sounding defensive, I may not have been too
tactful about mentioning the lack, and certainly several other people
have indicated their displeasure, but ANSI is one solution which allows
me to work with Xenix, V/AT, SunOS, and some fairly bizarre terminals. I
think a lot of us have grown to use memacs very heavily and are upset
that something which has been present has gone away. Many people who
can't change the termcap file find themselves out in the cold with the
new version.
-- 
	bill davidsen		(wedu@crd.GE.COM)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

jr@bbn.com (John Robinson) (04/14/89)

In article <56803@yale-celray.yale.UUCP>, spolsky-joel@CS (Joel Spolsky) writes:
>In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
>>In article <13576@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>>>  I think we may have failed to make it clear that support for ANSI
>>>keysequences is needed in UNIX versions. Termcap support won't do it. I
>>>posted fixes for this in every version from 3.7? to 3.10beta and none of
>>>them ever got picked up.
>>
>>Why?  What is the matter with reading the termcap entry and interpreting
>>the keys according to the termcap info?  
>
>Jonathan, I'm going to have to come out against this one. TERMCAP was
>never a good solution to keyboard problems. VERY FEW terminals are
>correctly set up in standard /etc/termcap files, even if they were,
>uEmacs 3.10 wants to use non-standard termcap entries for home, end,
>pgdown, etc.  There is no question that TERMCAP is not robust enough
>or well enough support for keyboards, especially in Xenix.

[...]

>>I have been able to make version 3.10 work with all the
>>keys on my keyboard by simply installing the appropriate modification to
>>my termcap file.
>
>Humph. I don't see why every poor joe slob that wants to use
>microEmacs should have to (1) figure out that his function keys dont
>work (2) find the source to uEmacs, (3) find that obscure comment in
>tcap.c about the termcap (4) change the /etc/termcap file.

I have to vote with Jonathan and (implicitly) Dan Lawrence here.  If
ANSI is standard enough (is it?  if not, then the built-in driver was
a compromise already), then why not simply distribute the ansi termcap
entry that uemacs wants to see to everyone, preferably with the
distribution.  Then users will get their ansi support without mucking
in the source or recompiling or getting a new distribution.  Are those
really easier than getting /etc/termcap changed?  I think rather the
opposite.

If users at a site want the better termcap(s) put into their local
copy, then they can pressure their site admin.  But there is always
the workaround - set your TERMCAP variable yourself.  This is
available to every user of uemacs now, without debugging new source or
waiting for a new distribution or buthering Dan.

Jonathan, could you post your termcap here?  Along with easy
instructions on how to set up $TERMCAP...  If it isn't "ansi", maybe
also a cookbook on how to modify it toward ansi-ness if you're able.

>Essentially, as most Unix develpers have figured out, TERMCAP is NEVER a
>realiable place to look for keyboard information. Especially in Xenix
>where many users don't even set up or use the TERMCAP env. variable at all.

And the more software out that there that avoids termcap, the more it
will atrophy.  The original concept is good.  Let's debug and enhance
termcap, not every screen-oriented program individually!

>A more reasonable solution, and the one that GNU Emacs uses, is to
>make it simple and reasonable to bind functions to the ANSI sequences,
>instead of the unnecessary uEmacs step of binding to hypothetical key
>names like FN< and FN>.

It's a separable issue how easy it is to rebind control sequences.
This idea sounds good independent of what happens with termcap. The
rebinding code iss much more generally useful than an ansi driver.
--
/jr
jr@bbn.com or bbn!jr
C'mon big money!

jbayer@ispi.UUCP (Jonathan Bayer) (04/14/89)

In article <13592@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
}In article <588@ispi.UUCP> jbayer@ispi.UUCP (Jonathan Bayer) writes:
}
}| Why?  What is the matter with reading the termcap entry and interpreting
}| the keys according to the termcap info?  Why must the keys for ANSI be
}| hardcoded into the program, therefore increasing the program size and
}| complexity?  I have been able to make version 3.10 work with all the
}
}  For someone on one machine, who is root, changing termcaps is just
}fine. When running on a number of machines for which you may not have
}permission to change the /etc/termcap file, and when you have two years
}of accumulated emacs macros, you would like to not reinvent the world.

So you set your termcap locally.  uEmacs reads the environment, not the
termcap file.  If you cannot change the system termcap file you can
certainly set the TERMCAP environment variable locally.

}
}| and being able to use whatever function keys are available knowing that
}| their function will be the same.  I think that the current solution is
}| much better than a hardcoded one.
}
}  This is not in keeping with the portable approach. You could just as
}well decide the VMS is better than UNIX so pull support out for UNIX.
}There are a lot of people who have been using memacs in one mode who
}would like to continue. It would be better to have one set of changes
}installed by the author than a group of changes done by various people.
}The VT100 option for keystrokes is just another option like AMIGA or
}IBMPC. It shouldn't require taking one useful thing out to add another.

If you want VT100 keys then get a VT-100 termcap and set it locally.  It
is the same functionality, and removes some special, wierd code which is
specific for one terminal.

Portable to me means that I can use the same code with many different
types of hardware without any modification other than setting
environment variables to inform the program what is going on.  If you
are at an environment which has several different types of terminals the
_portable_ vt-100 just doesn't hack it.  On the other hand, setting the
TERMCAP variable does.  It is easy, and there is no need to hack around
with the code.  All you have to do is set the TERMCAP.



JB
-- 
Jonathan Bayer			      Beware: The light at the end of the
Intelligent Software Products, Inc.	      tunnel may be an oncoming dragon
19 Virginia Ave.				...uunet!ispi!jbayer
Rockville Centre, NY 11570  (516) 766-2867    jbayer@ispi.UUCP

blarson@skat.usc.edu (Bob Larson) (04/16/89)

In article <13606@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
> Many people who
>can't change the termcap file find themselves out in the cold with the
>new version.

???

setenv TERMCAP /usr/skat2/blarson/.termcap
setenv TERM hz80

That's what I'm using right now, the hz80 entry isn't in /etc/termcap .

[I don't use microemacs, I use mg.  If you want to bind an ansi sequence
in mg, just put a line in your .mg file:
(global-set-key "\E[?2;8y" previous-line)
would set your infinite-wait key to previous-line.]

-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request