SYSTEM@gwuvax.BITNET.UUCP (01/27/87)
To whom it may concern:
I am running a vax with VMS 4.5 and EUNICE 4.2 Bsd ( a 4.1BSD
lookalike). I would like to know two things.
Has anyone put up GNU EMACS under EUNICE (from the Wollongong Group)
and if so where is the jobs library specified in the xmakefile in ../src
under label temacs: ie the ld statement is supposed to get the the libraries
specified in LIBES = -ljobs .... -lg -lc.
Secondly is it possible to get the VMS distribution over the BITNET
network?. I do have a the VAX C compiler.
If someone would be able to answer these questions I would appreciate
the assistance.
Jey Nathan
System Manager
jey@gwuvax.bitnet
system@gwuvax.bitnetSCS7317@oberlin.bitnet (02/13/88)
I need some help with gnu emacs: 1) How do I get a shell to run under VMS? 2) Can someone send me a copy of the online manual? Thanks in Advance: Chris Seline scs7317%ocvaxa@vb.cc.cmu.edu (internet) scs7317@ocvaxa.oberlin.edu (CSnet) ihnp4!oberlin!ocvaxa!scs7317 (UUCP) SCS7317@oberlin.bitnet (BITNET -- if your database is up to date) SCS7317%ocvaxa@CMCCVB.BITNET (BITNET -- if your database is OLD)
ronald@csuchico.EDU (Ronald Cole) (11/30/88)
In article <8791@wright.mips.COM> earl@wright.mips.com (Earl Killian) writes: >You seem to be operating under the misconception that emacs is an >editor. Emacs is an operating system. I hope that clears things up. >-- >UUCP: {ames,decwrl,prls,pyramid}!mips!earl >USPS: MIPS Computer Systems, 930 Arques Ave, Sunnyvale CA, 94086 That brings an interesting question to mind... Is GNU Emacs appropriate as a login shell? The manual certaintly seems to imply that to be the case. Has anyone done this? -- Ronald Cole | uucp: ihnp4!csun!csuchico!ronald AT&T 3B15/201 System Manager | PhoneNet: ronald@csuchico.edu California State University, Chico | voice (916) 895-5942 "... and if you don't like it, you must lump it." -Joseph Smith
mrd@sun.soe.clarkson.edu (Michael DeCorte) (12/01/88)
In article <1138@csuchico.EDU> ronald@csuchico.EDU (Ronald Cole) writes:
That brings an interesting question to mind... Is GNU Emacs appropriate
as a login shell? The manual certaintly seems to imply that to be the case.
Has anyone done this?
I haven't and don't plan to, the shell mode is just not complete
enough It might not be so bad if you only had an ascii terminal and
couldn't telnet or rlogin into any place else but if you do windows or
use other computers then it would be horrible.
Now if only emacs could make a window? (ala X) instead of splitting
the screen and had a terminal-emulator with a complete termcap that
other editors could use then maybe.
--
Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676
Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet
---------------------------------------------------------------------------
Clarkson Archive Server // commands = help, index, send, path
archive-server@sun.soe.clarkson.edu
archive-server%sun.soe.clarkson.edu@omnigate.bitnet
dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server
---------------------------------------------------------------------------jr@bbn.com (John Robinson) (12/01/88)
In article <MRD.88Nov30174223@sun.soe.clarkson.edu>, mrd@sun (Michael DeCorte) writes: >Now if only emacs could make a window? I have heard it rumored that this will come with v19, for X at least. >and had a terminal-emulator with a complete termcap that >other editors could use then maybe. Now why would you want to use any other editor? :-) -- /jr jr@bbn.com or bbn!jr
mrd@sun.soe.clarkson.edu (Michael DeCorte) (12/02/88)
>>and had a terminal-emulator with a complete termcap that >>other editors could use then maybe. >Now why would you want to use any other editor? :-) Well not all machines have emacs for one. But try this. M-X terminal-emulator (return when you it asks if you want /bin/csh) vi [run vi in the terminal emulator] [gee it works!] me [run me in the terminal emulator] [emacs complains of incomplete termcap entry] emacs [run emacs in the terminal emulator] [it works but is SLOW] [now rlogin into another favorite computer that has emacs] emacs [run emacs in the terminal emulator but on another machine] [says emacs-virtual undefined] setenv TERMCAP ... [goback and steal the $TEMRCAP the the above emacs had] [Doesn't seem to work] Now if you could put an entry in /etc/termcap say emacs-virtual that was complete then maybe we would have something. -- Michael DeCorte // (315)265-2439 // P.O. Box 652, Potsdam, NY 13676 Internet: mrd@sun.soe.clarkson.edu // Bitnet: mrd@clutx.bitnet --------------------------------------------------------------------------- Clarkson Archive Server // commands = help, index, send, path archive-server@sun.soe.clarkson.edu archive-server%sun.soe.clarkson.edu@omnigate.bitnet dumb1!dumb2!dumb3!smart!sun.soe.clarkson.edu!archive-server ---------------------------------------------------------------------------
mludwig@lehi3b15.UUCP (Mitchell Ludwig ) (12/10/88)
Ok, here we go... I am attempting to make 18.52 (gnu) work on my Microport 386. The machine is running Microport UN*X ver 3. Internally I've got 2 meg of usable memory. When I compile the darn thing, everything goes just grand until the makefile tries to execute ld temacs (and a whole lot of .o files...). Partway through the execution of this command I get an error concerning the system's inability to add the symbol Lisp_Subr to the symbol table and then I get gonged. I'm using the m-intel386.h and the s-usg-5-3.h in my config.h. My question is, HELP! How come? I have a friend using the freakin thing in SCO's Xenix (if this is a plug for XENIX, sorry :-) and he had none of the problems I'm having. In fact, it was the ease with which he compiled the thing which led me to give it a shot. So, does anyone 1) Have any idea why it gongs me here and with that error? 2) Have Gnu running on Microport? and 3) know of either an m or s file for my config which is more compatable with Microport. Also, if I'm gonna need to re-map my keyboard, has anyone done it yet? Any help is appreciated... You can reply to me here or directly to : UUCP : ...!lehi3b15!rastro!mfl or ...!lehi3b15!mludwig or for you internet and bitnet dudes Internet : KMFLUDW@vax1.cc.lehigh.edu Bitnet : MFL1@lehigh.bitnet Mitch
james@bigtex.cactus.org (James Van Artsdalen) (12/11/88)
In <429@lehi3b15.UUCP>, mludwig@lehi3b15.UUCP (Mitchell Ludwig ) wrote:
> So, does anyone [...] Have Gnu running on Microport?
GNU emacs 18.52 works fine under uPort unix, at least my 2.2 version.
I'll send Mitchell (and anyone else) my config.h, .emacs, and a
program I wrote to re-map the AT keyboard to something more useful for
emacs and ksh.
--
James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die"
Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759brian@cbw1.UUCP (Brian Cuthie) (12/12/88)
In article <429@lehi3b15.UUCP> mludwig@lehi3b15.UUCP (Mitchell Ludwig ) writes: > >Ok, here we go... > >I am attempting to make 18.52 (gnu) work on my Microport 386. The machine >is running Microport UN*X ver 3. Internally I've got 2 meg of usable memory. >When I compile the darn thing, everything goes just grand until the makefile >tries to execute ld temacs (and a whole lot of .o files...). Partway >through the execution of this command I get an error concerning the system's >inability to add the symbol Lisp_Subr to the symbol table and then I get >gonged. I'm using the m-intel386.h and the s-usg-5-3.h in my config.h. >My question is, HELP! How come? I have a friend using the freakin thing in [stuff deleted] Check the amount of disk space you have in the root partition. I ran into this problem on a client's system while trying to build a new kernel. After scratching my head for a few minutes I realized that all the disk space in the root partition (/) was gone. I then found out that when I had asked them to restore from the backup tape a few weeks ago, they had somehow not mounted the /usr file system. I don't know why, but the ld(er) is not very good about error messages when it runs out of disk space. This is *so* like many unix utilities. I like unix and have been using it for a *long* time, but I can't help but wonder what universe some of the people who write these utilities live in. I mean would it be so difficult to say "ld: out of /tmp space ?" I can't help but think that the major obstacle to UNIX becoming accepted in the business community has been the piss poor way in which programs die. Most of the time the program knows why it can't proceed but it just gives one of those famous "name: cryptic dribble" messages. Some utilities are definitely better than others but AT&T needs to impliment some internal standard for the way a program dies. All programs should be required to give you meaningfull error messages. Then perhaps, non UNIX people will begin to overcome their fears of using it. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (12/12/88)
brian@cbw1.UUCP (Brian Cuthie) writes: >Partway >through the execution of this command I get an error concerning >the system's inability to add the symbol Lisp_Subr to the symbol >table Check the amount of disk space you have in the root partition. If this is in fact the problem, then try setting the environment variable TMPDIR to some directory on a filesystem with lots of excess space. All the SysV standard utilities will write their temp files there rather than in /tmp. --Karl
debra@alice.UUCP (Paul De Bra) (12/12/88)
In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >... >I don't know why, but the ld(er) is not very good about error messages when >it runs out of disk space. This is *so* like many unix utilities. I like >unix and have been using it for a *long* time, but I can't help but wonder >what universe some of the people who write these utilities live in. I mean >would it be so difficult to say "ld: out of /tmp space ?" >... What's wrong with the message the kernel should display on the console: /tmp: file system full and which it repeats for every attempted write? I don't know about Microport but every other unix system I have worked on will give you this message. I think it's a neat idea to put this message in just one place (in the kernel) rather than to repeat it in every utility. And though it used to be a problem on multiuser systems where you might not notice the messages on the console (though the system surely came to a crawl which everyone should notice) on these mighty PC's where one always uses the console this should be even more acceptable than before. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jxw@RODS.IUS.CS.CMU.EDU (John Willis) (12/13/88)
Several weeks ago I was able to compile GNU-Emacs 18.52 under Microport 3.0 and /bin/cc. You need to be careful because the LISP files default to loading a compiled version (.elc) rather than a pure ASCII source version (.el). Somewhere along the transmission path, if you assume that the source is all ASCII, these compiled files will probably be corrupted. There is a simple fix, as documented by Stallman in the release notes. 1) Increase the amount of memory allocated to pure lisp (I think the define is at the end of config.h). 2) Recompile (only alloc.o is probably sufficient, check). 3) Delete all of the .elc files from the LISP directory. 4) Load the new temacs, defaulting to .el representations. 5) Recompile .el files into .elc files (something like byte-compile-directory ../Lisp) 6) Reduce the pure lisp storage (reversing (1) above). 7) Rebuild emacs, loading the .elc files by default. Like the other GNU tools, this is an excellent editor. It's worth a little effort. If this doesn't get you a running Emacs 18.52, I'll try to help. -John --
" Maynard) (12/13/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes, in reference to a kernel message written to the console: >And though it used to be a problem on multiuser systems where you might >not notice the messages on the console (though the system surely came to a >crawl which everyone should notice) on these mighty PC's where one always >uses the console this should be even more acceptable than before. Hate to tell you this, Paul, but I'm on /dev/cons1 right now on my AT-clone, not /dev/console. I hardly ever flip over to /dev/console; insted, it's reserved for those times that I need to log on as root to get something done. Next suggestion? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can uucp: uunet!nuchat! (eieio)| adequately be explained by stupidity. hoptoad!academ!uhnix1!splut!jay +---------------------------------------- {killer,bellcore}!tness1! | Eight more years! Eight more years!
debra@alice.UUCP (Paul De Bra) (12/13/88)
In article <778@splut.UUCP> jay@splut.UUCP (Jay "you ignorant splut!" Maynard) writes: ]In article <8525@alice.UUCP> debra@alice.UUCP () writes, in reference to ]a kernel message written to the console: ]>And though it used to be a problem on multiuser systems where you might ]>not notice the messages on the console (though the system surely came to a ]>crawl which everyone should notice) on these mighty PC's where one always ]>uses the console this should be even more acceptable than before. ] ]Hate to tell you this, Paul, but I'm on /dev/cons1 right now on my ]AT-clone, not /dev/console. I hardly ever flip over to /dev/console; ]insted, it's reserved for those times that I need to log on as root to ]get something done. Next suggestion? ] I hate to tell you this, Jay, but Microbug clearly blew it on this one again. With SCO Xenix you would get the messages no matter on which virtual console you are. So you can figure out my next suggestion... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
brian@cbw1.UUCP (Brian Cuthie) (12/14/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes: >In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >>... >>I don't know why, but the ld(er) is not very good about error messages when >>it runs out of disk space. This is *so* like many unix utilities. I like >>unix and have been using it for a *long* time, but I can't help but wonder >>what universe some of the people who write these utilities live in. I mean >>would it be so difficult to say "ld: out of /tmp space ?" >>... >What's wrong with the message the kernel should display on the console: >/tmp: file system full >and which it repeats for every attempted write? > Well, actually, it doesn't do that for microport Sys V/386. Plus, I'm not sure that it's reasonable for user A to have to wonder what's wrong with his program when the messages are bombarding user B. Seems kind of stupid to me. I will stick with my original statement: ALL PROGRAMS SHOULD SAY *IN CLEAR ENGLISH* WHY THEY DIED ! I mean, GEEZ, what is it that makes people want to keep unix messages cryptic. Could it be job security ?? I sure don't know. -brian -- Brian D. Cuthie uunet!umbc3!cbw1!brian Columbia, MD brian@umbc3.umd.edu
mludwig@lehi3b15.UUCP (Mitchell Ludwig ) (12/14/88)
In article <11544@bigtex.cactus.org> james@bigtex.cactus.org (James Van Artsdalen) writes: >GNU emacs 18.52 works fine under uPort unix, at least my 2.2 version. >I'll send Mitchell (and anyone else) my config.h, .emacs, and a >program I wrote to re-map the AT keyboard to something more useful for >emacs and ksh. James, thanks alot for your help. Believe me it made life alot easier. The remap is real nice. But (there is *ALWAYS* a but), I am now having a new problem. I'm now a happy user of GNU 18.52, well, almost happy. RMAIL hates me. My system is hooked via uucp to an internet gateway of sorts. It's also hooked to another independent machine. I can't talk to either of them. I can originate messages to either, but responding aint a happy time. The 3b15 (which is my internet host) mails to me with the extension of @lehi3b15.UUCP which my mailer hates. I guess it's the @ sign. Any help there? And with ubu, the indep. machine, all mail from him seems to be coming from my uucp account, and rmail replies to it there. So I'm in deep kaka and sinking fast into the mud. Any help is appreciated... Mitch ...!lehi3b15!mludwig ...!lehi3b15!rastro!mfl (but don't expect a reply :-)
guy@auspex.UUCP (Guy Harris) (12/14/88)
>And though it used to be a problem on multiuser systems where you might >not notice the messages on the console (though the system surely came to a >crawl which everyone should notice) on these mighty PC's where one always >uses the console this should be even more acceptable than before. It's arguably still a problem on those multiuser systems; they haven't gone away. Furthermore, programs should print them *anyway*; programs should check for I/O errors and report them. They should also "do the right thing" when they occur; for instance, an SMTP daemon should *not* acknowledge receipt of mail until it has written the mail out with no errors *and*, if at all possible, has ensured that the data has actually been written to non-volatile storage (using "fsync" on systems that have it, otherwise using O_SYNC mode when writing on systems that have it). As long as you're checking for errors such as this, it's not that much harder to print a message as well.... Furthermore, it's not always obvious what *caused* the file system to fill up; it might have been caused by a daemon program as opposed to a command the user ran (or it might have been caused by a background job the user started, or by somebody who remotely logged into your machine running a job, or...). A message from the program, giving the source of the message (e.g., "ld", or maybe even better "cc"), would do that better than just "/tmp: file system full".
lars@myab.se (Lars Pensj|) (12/14/88)
In article <8525@alice.UUCP> debra@alice.UUCP () writes: >In article <121@cbw1.UUCP> brian@cbw1.UMD.EDU (Brian Cuthie) writes: >>... >>I don't know why, but the ld(er) is not very good about error messages when >>it runs out of disk space. This is *so* like many unix utilities. I like >>unix and have been using it for a *long* time, but I can't help but wonder >>what universe some of the people who write these utilities live in. I mean >>would it be so difficult to say "ld: out of /tmp space ?" >>... >What's wrong with the message the kernel should display on the console: >/tmp: file system full > >I don't know about Microport but every other unix system I have worked on >will give you this message. I think it's a neat idea to put this message in >just one place (in the kernel) rather than to repeat it in every utility. I strongly disagree here. It is of vital importance that all programs on their own check results of system calls (like write). Even if some people uses the console, there are always a lot of people who do not. It is also important that a program wich fails on a system call (as in this case) immediately terminates (if it does not know how to recover). I have had to much contact with programs that take for granted success of some functions, with the result that the programs just fails without telling why. Especially when porting to new systems. And when a system call fails, always use perror. -- Lars Pensj| lars@myab.se
mdt@s1.sys.uea.ac.uk (M.D. Templeton GEC ) (12/16/88)
o Item 1
I have emacs v 18.45, on a Sun 3/50 and have a teeny weeny problem.
If I use the mouse in suntools, say with two emacs windows displayed,
to select an emacs menu option, say to expand the current window,
the message I get is:
Invalid function: (macro lambda (window &rest forms) "Switch to WINDOW, evaluate FORMS, return to original window." (byte-code .....
The dots were my idea!
The function does seem to be performed, though. I also can't get any effect
from the middle mouse-key.
Any ideas, fixes, patches????
o Item 2:
Does anyone in the UK or Europe have a copy of emacs 18.52, and the will
to put it on a tape for me (I'll supply the tape of course).
Similarly, anyone over here got the other FSF programs, and/or a
system for getting updates/new versions as they come available??
o Thanks in advance for help with both of these items.
Mark D Templeton (The Druid)
Janet: mdt@uk.ac.uea.cs
Voice: 0603-56161 x 2308 (UEA)
0634-44433 x 60 (GEC)
0634-364150 (home - 18-Dec-88 to 3-Jan-89)jr@bbn.com (John Robinson) (12/16/88)
In article <291@s1.sys.uea.ac.uk>, mdt@s1 (M.D. Templeton GEC ) writes: >o Item 1 > I have emacs v 18.45, on a Sun 3/50 and have a teeny weeny problem. > If I use the mouse in suntools, say with two emacs windows displayed, > to select an emacs menu option, say to expand the current window, > the message I get is: > >Invalid function: (macro lambda (window &rest forms) "Switch to WINDOW, evaluate FORMS, return to original window." (byte-code ..... This is one of those problems that crop up from time to time. What happened is that one of the sun-*.el files was byte-copmiled without the proper macro definitions having been made first. Though I have 18.52, it appears that the macro in question is eval-in-window, which is used in sun-fns.el and sun-mouse.el, and defined at thge top of the latter. The error you got is that the macro definition was called as a function, which doesn't work. The fix is to load the file defining the macro before byte-compiling files that use the macro. In your case, connect to the emacs/lisp directory and do the sequence: (load-file "sun-mouse.el") (byte-compile-file "sun-mouse.el") (byte-compile-file "sun-fns.el") or the equivalent interactive calls. Check first that the defmacro in question is in sun-mouse.el, as 18.45 may differ from 18.52. To be safe, you may want to load-file on all the sun-*.el files and byte-compile them all. Do all the load-files first. -- /jr jr@bbn.com or bbn!jr
mdt@s1.sys.uea.ac.uk (M.D. Templeton GEC ) (12/16/88)
Another one.. Emacs has a terminal emulator. As I need a vt100 terminal emulator for a Sun 3/60, I thought this a good idea. However, the emacs terminal emulator seems to emulate some unknown terminal type. Does anyone have the lisp to make a VT100 version?? Alternatively, any suggestions as to how I can get vt100 emulation through suntools, or anything else?? ps. Although I have emacs 18.45, I only have the manual/info files for version 17. Mark D Templeton (The Druid)
debra@alice.UUCP (Paul De Bra) (12/17/88)
In article <448@myab.se> lars@myab.UUCP (Lars Pensj|) writes: >... >It is of vital importance that all programs >on their own check results of system calls (like write). >... I agree, but unfortunately very few programs actually do this for read and write. It is very common in Unix utilities to check the result of the open system call and then just assume that writing and closing will go well. Reasons are obvious: programmers are a bit lazy, and the programs become smaller and faster if you don't check. (so not checking also makes your system look better in benchmarks which use standard utilities...) The administrative advice which is given with every Unix system (or at least used to be given) is that the system administrator should regularly check the amount of free space on all file systems, to make sure they never get full. This administrative procedure may no longer be considered acceptable, but remember that lots of utilities have not changed, so they still rely on this assumption. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
plocher@uport.UUCP (John Plocher) (12/17/88)
In article <8530@alice.UUCP> debra@alice.UUCP () writes: >I hate to tell you this, Jay, but Microbug clearly blew it on this one >again. With SCO Xenix you would get the messages no matter on which virtual >console you are. So you can figure out my next suggestion... > >Paul. The messages printed by Unix kernels use a version of printf() which bypasses the complete Virtual Console Subsystem and dumps the text directly to the screen. This is done by the ATT, ISC, Microport, and SCO versions of Unix to make sure the messages get seen (what would happen if there was a bug in the console driver and you couldn't change to the console VC? You'd still want to see the message! These messages also pass thru the osm (Operating System Messages) driver so you can log them to a file amd find them with crash(1M). -John Plocher
chip@ateng.ateng.com (Chip Salzenberg) (12/22/88)
In article <448@myab.se> lars@myab.UUCP (Lars Pensj|) reminds us that all programs should check return values of system calls, such as write(). This is obviously good policy. However, according to debra@alice.UUCP (Paul De Bra): >... unfortunately very few programs actually do this for read and write... >Reasons are obvious: programmers are a bit lazy, and the programs become >smaller and faster if you don't check. (so not checking also makes your >system look better in benchmarks which use standard utilities...) This misconception about "efficiency" is all too common. Checking the return values of system calls takes some programmer time during coding, but this is more than returned during debugging and use. ("A bit lazy"? Try "lazy enough to get fired".) And as for execution speed: how long does an integer comparison take? Certainly not enough to worry about, once you've accepted the overhead of a kernel trap. And this fellow works in AT&T Research. Sigh. -- Chip Salzenberg <chip@ateng.com> or <uunet!ateng!chip> A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."
rlc@uvacs.cs.Virginia.EDU (Robert L. Chase) (02/21/89)
Two questions, if you can help: 1. Is there a way to print the current manual (distributed on tape) if I don't have TEX? (I'm on VMS). 2. Is there a way to make Incremental Search (CTRL-S) case sensitive (I do Modula-2). Thanks in advance for any help. ---- Robert L. Chase INTERNET: rlc@uvacs.cs.virginia.edu Director of Academic Computing Computer Center Sweet Briar College UUCP: ...!mcnc!uvacs!rlc PO BOX AK ...!cbosgd!uvacs!rlc Sweet Briar, VA 24595 (804) 381-6232 -- Robert L. Chase, PO Box AK, Sweet Briar College, Sweet Briar, VA 24595 INTERNET: rlc@uvacs.cs.virginia.edu UUCP: ...!mcnc!uvacs!rlc or ...!cbosgd!uvacs!rlc
weiner@novavax.UUCP (Bob Weiner) (02/22/89)
In article <2987@uvacs.cs.Virginia.EDU> rlc@uvacs.cs.Virginia.EDU (Robert L. Chase) writes:
Two questions, if you can help:
1. Is there a way to print the current manual (distributed on tape) if
I don't have TEX? (I'm on VMS).
If you have the emacs.dvi file already (I'm not sure if this is currently
distributed) then you don't need TeX, but you do need another program
that filters the .dvi file to something your printer accepts such as
Postscript. Many such programs such as dvi2ps are available.
But why waste your time and your printer. The Free Software
Foundation sells very readable manuals for $15 a piece. They are in
the Cambridge, MA telephone directory.
Additionally, you should learn to use Info. It lets you browse the
entire manual online. Once you know how to use it (try {C-h a info})
you probably won't need a printed manual.
2. Is there a way to make Incremental Search (CTRL-S) case sensitive (I do
Modula-2).
Yes, do a (setq case-fold-search nil) to turn case sensitivity on.
Interactively, you can do a {M-x setq <RTN>} and fill in the
parameters. {M-x apropos <RTN> fold} will show you all the variables
associated with case-folding.
As a side note, not a lot of people know that {M-x apropos} often
displays much more information that {C-h a} since it includes
functions without "interactive" declarations and variables not
normally intended for user setting.
Bob
--
Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
(407) 738-2087fisher@SIFVX3.SINET.SLB.COM (11/23/89)
Can anyone tell me where I can get hold of a copy of GNU emacs sources. I can't use anonymous FTP so it will have to be an archive- or info-server. If there is no such server, could some kind soul mail them to me (or preferably let me know they would be willing to mail them to me. This will give me some warning so I can make enough space for them.) Thanks in advance. Craig fisher@sifvx1.sdr.slb.com@relay.cs.net
bret@uop.UUCP (11/24/89)
fisher@SIFVX3.SINET.SLB.COM: > Can anyone tell me where I can get hold of a copy of GNU emacs sources. I can't > use anonymous FTP so it will have to be an archive- or info-server. > > If there is no such server, could some kind soul mail them to me (or preferably > let me know they would be willing to mail them to me. This will give me some > warning so I can make enough space for them. I can email it. It is HUGE!!! I'm not altogeth sure (I haven't tried to pack it up, but, compressed and tar'd, it's (i guess!) between 10 and 11 MEGS. It'll come in god knows how many shar files. Lemme know, -Bret.
jka@hpfcso.HP.COM (Jay Adams) (11/26/89)
Their is an archive server that will mail you the 18.53 sources. Send mail to archive-server@sun.soe.clarkson.edu with "help" and "index fsf" in the message body. The archive server should give you the details. If you want newer sources, 18.55, I could probably mail them to you. I don't know what the differences are between the two releases. - Jay
ceb@CSLI.STANFORD.EDU (Charles Buckley) (11/27/89)
If your Schlumberger connection is not bogus: Simply go across sinet to slcs, who *has* an Internet connection, and get it that way, or ask someone there, or at the Austin Systems Center, to do it for you. I'm sure they have them. SLCS is there to serve the entire Schlumberger community - They'll feel hurt if you don't ask them. Signed, a (soon to be former) Schlumberger employee.
ted@NMSU.EDU (11/28/89)
this is taken directly from the emacs distribution package. GNU Emacs availability information, 13 March 1988 Copyright (C) 1986, 1987, 1988 Richard M. Stallman Permission is granted to anyone to make or distribute verbatim copies of this document provided that the copyright notice and this permission notice are preserved. GNU Emacs is legally owned by the Free Software Foundation, but we regard the foundation actually as its custodian on behalf of the public, since all software ought to be the common property of mankind. The foundation permits everyone to have and run copies of GNU Emacs, at no charge, and to redistribute copies under certain conditions which are designed to make sure that that all modified versions of GNU Emacs remain as free as the versions we distribute. These conditions are stated in the document "GNU Emacs General Public License", a copy of which is required to be distributed with every copy of GNU Emacs. It is usually in a file named COPYING in the same directory as this file. If you do not know anyone to get a copy of GNU Emacs from, you can order a tape from the Free Software Foundation. We distribute Emacs version 18 on 1600bpi industry standard mag tape in tar format. We will also ship it on 1/4" Sun cartridge tapes in tar format and on 1600bpi magtape in VMS interchange format. We also distribute nicely typeset copies of the Emacs manual. See the order form at the end of this file. If you have Internet access, you can copy the latest Emacs distribution from host prep.ai.mit.edu. There are several ways to do this; see the file `FTP' in the same directory as this file for more information. Even better, get the latest version of the file from `/u2/emacs/etc/FTP' on prep.ai.mit.edu for the most current arrangements. It may also be possible to copy Emacs via uucp; the file `FTP' contains information on that too. Emacs has been run on both Berkeley Unix and System V Unix, on a variety of types of cpu. It also works on VMS and on Apollo computers, though with some deficiencies that reflect problems in these operating systems. See the file MACHINES in this directory for a full list of machines that GNU Emacs has been tested on, with machine-specific installation notes and warnings. Note that there is significant variation between Unix systems supposedly running the same version of Unix; it is possible that what works in GNU Emacs for me does not work on your system due to such an incompatibility. Since I must avoid reading Unix source code, I cannot even guess what such problems may exist. GNU Emacs is distributed with no warranty (see the General Public License for full details), and neither I nor the Free Software Foundation promises any kind of support or assistance to users. The foundation keeps a list of people who are willing to offer support and assistance for hire. We will list anyone who agrees never to ask customers to keep secret anything they are told or given as part of the support. It is usually in a file named SERVICE in the same directory as this file. However, I plan to continue to improve GNU Emacs and keep it reliable, so please send me any complaints and suggestions you have. I will probably fix anything that is clearly (to me) a malfunction. I may make an improvement if I consider it worth the effort, but you should not be surprised if I don't think I can spare time for it. I hope to keep Emacs stable now, and avoid putting much time into it, so I can work on other parts of the GNU system. If you are on the Internet, report bugs to bug-gnu-emacs@prep.ai.mit.edu; on Usenet, use the address ..!ucbvax!bug-gnu-emacs%prep.ai.mit.edu. Otherwise, phone the foundation at +1 617 876-3296, or write to the address listed below. If you are a computer manufacturer, I encourage you to ship a copy of GNU Emacs with every computer you deliver. The same copying permission terms apply to computer manufacturers as to everyone else. You should consider making a donation to help support the GNU project; if you estimate what it would cost to distribute some commercial product and divide it by five, that is a good amount. If you like GNU Emacs, please express your satisfaction with a donation: send me or the Foundation what you feel Emacs has been worth to you. If you are glad that I developed GNU Emacs and distribute it as freeware, rather than following the obstructive and antisocial practices typical of software developers, reward me for doing so! Your donations will help to support the development of more useful software to be distributed on the same basis as GNU Emacs. Eventually we will have a complete imitation of the Unix operating system, called GNU (Gnu's Not Unix), which will run Unix user programs. For more information on GNU, see the file GNU in this directory. Richard M Stallman Chief GNUisance, President of the Free Software Foundation Free Software Foundation Order Form 26 April 1988 All software and publications are distributed with permission to copy and redistribute. Quantity Price Item ________ $150 GNU Emacs source code, on a 1600bpi industry standard mag tape in tar format. The tape also contains: * GDB (the GNU source-level C debugger) * MIT Scheme (a dialect of Lisp) * Hack (a rogue-like game) * Bison (a free, compatible replacement for yacc) * The X window system (a window system for bitmap displays written at MIT) (version 10r4) * GNU Chess (a chess playing program with an interface to X). ________ $175 Same data as above on a Sun DC300XL 1/4" cartridge tape. ________ $150 GNU Emacs only, on a 1600bpi industry standard mag tape in VMS backup format. ________ $150 GNU C Compiler source code, on a 1600bpi industry standard mag tape in tar format. The tape also contains: * Gawk (the GNU implementation of the AWK programming language) * GNU Assembler * Bison (a free, compatible replacement for yacc) * The X window system (a window system for bitmap displays written at MIT) (version 11r2) * GNU versions of ld, make, size, nm and strip * Flex (Vern Paxson fast rewrite of lex) ________ $175 Same data as above on a Sun DC300XL 1/4" cartridge tape. ________ $15 GNU Emacs manual (~300 pages). These manuals are phototypeset and offset printed, with illustrated covers, a GBC plastic ring binding that stays open flat, and a tear-out reference card. Thus, a 1600 bpi tape and one Emacs manual come to $165. ________ $10 GDB Manual (~55 pages, side stapled.) ________ $10 Texinfo Manual (~30 pages, side stapled. Texinfo is GNU's structured documentation system, included with GNU Emacs This manual describes how to write Texinfo documents). ________ $10 Termcap Manual (~60 pages, side stapled. Documents the termcap library and GNU's extensions to it.) ________ $60 Box of six GNU Emacs manuals. ________ $1 One GNU Emacs reference card. ________ $5 Ten GNU Emacs reference cards. Prices are subject to change without notice. ________ Massachusetts residents please add 5% sales tax to all prices. ________ Shipping outside North America is normally by surface mail. For air mail delivery, please add $15 per tape or manual, $1 for an individual reference card, or 50 cents per card in quantity ten or more. ________ Optional tax deductable donation. ________ Total paid Orders are filled upon receipt of check or money order. We do not have the staff to handle the billing of unpaid orders. Please help keep our lives simple by including your payment with your order. Make checks payable to Free Software Foundation. Mail orders to: Free Software Foundation, Inc. 675 Mass Ave Cambridge, MA 02139 All software from the Free Software Foundation is provided on an "as is" basis, with no warranty of any kind.
dbarnes@public.BTR.COM (David B. Barnes dbarnes@btr.com) (11/19/90)
I head from someone that Gnu Emacs is "free". Is this true?
I'm not a sysadmin, but I'm curious as to how one would go
about getting Gnu emacs for this system (our emacs is fairly
crippled).
Whom does on contact? What are the procedures?
--
--------------------------------------------------------
David Barnes dbarnes@btr.com
Menlo Park, CA ..!{decwrl,mips,fernwood}!btr!dbarnes
--------------------------------------------------------bob@MorningStar.Com (Bob Sutterfield) (11/20/90)
In article <1022@public.BTR.COM> dbarnes@public.BTR.COM (David B. Barnes dbarnes@btr.com) writes:
I head from someone that Gnu Emacs is "free". Is this true?
Yes, for certain values of "free" :-)
I'm curious as to how one would go about getting Gnu emacs for this
system (our emacs is fairly crippled). Whom does on contact? What
are the procedures?
Get GNU Emacs and other GNU software via anonymous FTP from
prep.ai.mit.edu:pub/gnu/emacs-18.55.tar.Z or via anonymous UUCP from
osu-cis!~/gnu/emacs/18.55/emacs-18.55.tar.Z-part-[aa-br]. Write to
uucp@cis.ohio-state.edu for instructions if you need them.david@dogmelb.dog.oz.au (David Le Blanc) (02/01/91)
Could someone please mail me the location of the latest GNU Emacs?
Please be specific, since I have to use a mail server. Hence
please supply archive machine name/internet id(optional)
and FULL path please!
Thanks
-- David
--
Email: david@dogmelb.dog@munnari.oz | Division of Geomechanics,
TEL. (03) 881 1355 | CSIRO, P.O. Box 54
FAX (03) 881 2052 | Mt Waverley 3149,
| AUSTRALIA.