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