rohit@hpindda.HP.COM (Rohit Aggarwal) (02/26/88)
Hello
Has anyone got gnu to work in the server mode on an ASCII
terminal?
I changed gnu's .emacs file to start the server when I enter
gnumacs and then I put gnu in the background. Now when I
try to run another application that uses the editor gnu I
get the gnu server msg output stating the port number and
then I get a line like "Waiting..... ".
Thank You in advance.
-------------------------------------------------------------------------
Rohit Aggarwal (UUCP : ...!hplabs!hpda!rohit)
Hewlett Packard (IND) (ARPANET : rohit%hpindlm@hplabs.HP.COM )
Cupertino, CA, 95014 (Pac Bell: 408 447-3042
USA
--------------------------------------------------------------------------fuchs@gmdka.UUCP (Harald Fuchs) (02/29/88)
In article <3590013@hpindda.HP.COM> rohit@hpindda.HP.COM (Rohit Aggarwal) writes: > Has anyone got gnu to work in the server mode on an ASCII > terminal? > > I changed gnu's .emacs file to start the server when I enter > gnumacs and then I put gnu in the background. Now when I > try to run another application that uses the editor gnu I > get the gnu server msg output stating the port number and > then I get a line like "Waiting..... ". > GNU Emacs must run in the foreground in order to be able to respond to an emacsclient. This can be achieved by two means: - Start up an Emacs subshell (M-x shell) and run your application there. - Use X windows or something of the kind. Harald Fuchs UUCP: ...!uunet!unido!gmdka!fuchs X.400: fuchs@karlsruhe.gmd.dbp.de
fuchs@gmdka.UUCP (Harald Fuchs) (02/29/88)
In article <3590013@hpindda.HP.COM>, rohit@hpindda.HP.COM (Rohit Aggarwal) says: > Has anyone got gnu to work in the server mode on an ASCII > terminal? > I changed gnu's .emacs file to start the server when I enter > gnumacs and then I put gnu in the background. Now when I > try to run another application that uses the editor gnu I > get the gnu server msg output stating the port number and > then I get a line like "Waiting..... ". GNU Emacs must run in the foreground in order to be able to respond to an emacsclient. This can be achieved by two means: - Start up an Emacs subshell (M-x shell) and run your application there. - Use X windows or something of the kind. Harald Fuchs UUCP: ...!uunet!unido!gmdka!fuchs X.400: fuchs@karlsruhe.gmd.dbp.de
mike@turing.UNM.EDU (Michael I. Bushnell) (03/01/88)
In article <262@gmdka.UUCP> fuchs@gmdka.UUCP (Harald Fuchs) writes: > >GNU Emacs must run in the foreground in order to be able to respond to an >emacsclient. This can be achieved by two means: >- Start up an Emacs subshell (M-x shell) and run your application there. >- Use X windows or something of the kind. > > Harald Fuchs Not so. In fact, I can prove it. This article got posted, right??? I had my emacs stopped (^Z) and was using rn. Saw this, and decided to post. So, Pnews called up 'ol emacsclient, which printed "Waiting for Emacs...". Then I ^Z-ed out of Pnews, and fg-ed my emacs. Whereupon, server read in the header and I wrote this. Shortly, I shall type C-x #, save the buffer, and ^Z emacs and fg Pnews. And then, lo and behold, emacsclient will print "Done."...and if I list the article, it's still there. No need for subshells, windows, or any other garbage. Guess why??? Emacs client can connect to a socket even when the owner is a sleep. It can even write...remember UNIX? PSEUDO-synchronized I/O. Anyway, once emacsclient has connected and written its little message into the kernel's buffer, it makes no difference if it runs or not. When I resume emacs, it reads that buffer and *POW* there we are. Geez. I wish 'ol RMS would fix the manual on this one. Michael I. Bushnell Internet: mike@turing.unm.edu UUCP: mike@turing.unm.edu Bitnet: mike@turing.unm.edu CSnet: mike@turing.unm.edu YourFavoriteNet: mike@turing.unm.edu Golly, don't domains make everything simpler? For peoply who run UUCP but haven't switched over to smail *yet*, you can try {ucbvax,gatech}!unmvax!turing!mike. Or write: {Box 295, Coronado Hall} or {Computer Science, Farris Engineering Center} University of New Mexico Albuquerque, NM 87131 Or call: (505)277- [2992=dorm][6116=work] I work for the CS department. But don't blame them.
trost@reed.UUCP (Trost [no first name]) (03/03/88)
In article <264@gmdka.UUCP> fuchs@gmdka.UUCP (Harald Fuchs) writes: >GNU Emacs must run in the foreground in order to be able to respond to an >emacsclient. This can be achieved by two means: >- Start up an Emacs subshell (M-x shell) and run your application there. >- Use X windows or something of the kind. Au contraire! I use the emacs server from a plain terminal daily. All you have to do is type ^Z when it says "Waiting for emacs..." and then bring emacs back into the foreground by %em or whatever. When you're done, you do a ^X#, then stop emacs, and then type %- at the csh; emacsclient says "Done", and you continue merrily on your way. -- ...!(ogcvax|tektronix)!reed!trost (UUCP) This text is in the public domain; no rights have been reserved, nor is there any sort of warranty or guarantee of merchantability or fitness.
heiser@ethz.UUCP (Gernot Heiser) (03/05/88)
In article <3590013@hpindda.HP.COM> rohit@hpindda.HP.COM (Rohit Aggarwal) writes: > I changed gnu's .emacs file to start the server when I enter > gnumacs and then I put gnu in the background. Now when I > try to run another application that uses the editor gnu I > get the gnu server msg output stating the port number and > then I get a line like "Waiting..... ". The emacs server was ment to be used with a window system. You can start Emacs on one window, start the emacs server, and then in a different window run an application that uses the emacs server (and hence your original emacs running in a different window) to edit. The only ways to use the server with a normal ASCII terminal is when you run the application from the Emacs shell window or from the emacs terminal emulator. Alternatively you could (probably, I never tried this) suspend your application after the "Waiting..... " message appeared, foreground your suspended emacs and edit. -- Gernot Heiser Phone: +41 1/256 23 48 Integrated Systems Laboratory CSNET/ARPA: heiser%ifi.ethz.ch@relay.cs.net ETH Zuerich EARN/BITNET: GRIDFILE@CZHETH5A CH-8092 Zuerich, Switzerland EUNET/UUCP: {uunet,...}!mcvax!ethz!iis!heiser
allbery@ncoast.UUCP (Brandon Allbery) (03/10/88)
As quoted from <844@unmvax.unm.edu> by mike@turing.UNM.EDU (Michael I. Bushnell): +--------------- | Not so. In fact, I can prove it. This article got posted, right??? | I had my emacs stopped (^Z) and was using rn. Saw this, and decided | to post. So, Pnews called up 'ol emacsclient, which printed "Waiting | for Emacs...". Then I ^Z-ed out of Pnews, and fg-ed my emacs. | Whereupon, server read in the header and I wrote this. Shortly, I | shall type C-x #, save the buffer, and ^Z emacs and fg Pnews. And | then, lo and behold, emacsclient will print "Done."...and if I list | the article, it's still there. +--------------- Why so much work? Why doesn't emacsclient write its message and then SIGCONT the stopped emacs, which then would discover a message on the socket and read "keystrokes" from the socket rather than stdin and either display directly (modulo tostop) or send the display to emacsclient (which could just "cat" it)? It'd certainly be easier for the user than having to ^Z/fg all over the place, and it doesn't sound all that difficult to write. (Okay, maybe you can't get away with it -- but I'm fairly certain I could use a "permanently" backgrounded emacs with message queues under System V to do it.) -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
aglew@ccvaxa.UUCP (03/16/88)
For a while I was doing all my notes (news to you) reading under terminal-mode, using emacsclient as the editor. Whenever I went to edit a note, the emacsserver window fell into place automatically. This worked fine, except for braindamaged programs that require 24x80 screens (I'd give myself 26x82 if I had a Sun). Plus, terminal-mode is a bear - not for any inherent reason, I just haven't done all the things necessary to make it useful. Terminal mode needs to be made to write into a virtual screen larger than the window; it needs to have both buffered and unbuffered input; it needs to be able to emulate terminals instead of requiring its own termcap; and it would be nice to integrate it better with shell mode. All things on my list of "When school is over" hacks.
rbj@ICST-CMR.ARPA (Root Boy Jim) (03/19/88)
Why so much work? Why doesn't emacsclient write its message and
then SIGCONT the stopped emacs, which then would discover a message
on the socket and read "keystrokes" from the socket rather than
stdin and either display directly (modulo tostop) or send the
display to emacsclient (which could just "cat" it)? It'd certainly
be easier for the user than having to ^Z/fg all over the place, and
it doesn't sound all that difficult to write. (Okay, maybe you
can't get away with it -- but I'm fairly certain I could use a
"permanently" backgrounded emacs with message queues under System V
to do it.) --
Because that's not how it was designed to work. The emacs server may
already be running in another window. In this case, the `window' exists
in time rather than in space. Anyway, how would the server know how to
get back to the client? You'd only have solved half the problem.
Brandon S. Allbery, moderator of comp.sources.misc
{well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
--- I have seen the FUN ---perry@sambation.bellcore.com (Perry Metzger) (03/20/88)
>> Why so much work? Why doesn't emacsclient write its message and >> then SIGCONT the stopped emacs, > >Because that's not how it was designed to work. The emacs server may >already be running in another window. In this case, the `window' exists >in time rather than in space. Anyway, how would the server know how to >get back to the client? You'd only have solved half the problem. Oh, come on. This isn't a legitimate objection. You can easily determine if there is an emacs running on the same tty or pty, so the question of "do I send it a SIGCONT" is easy to handle. Similarly, the client can pass its pid to the emacs in server mode and get a signal back telling it to wake up. I think the benefits of having a scheme like this would be great. Most people in the world still use terminals, not bitmapped displays. Providing something that they can use conveniently is a big plus.
aj@zyx.UUCP (Arndt Jonasson) (03/23/88)
In article <6227@bellcore.bellcore.com> perry@bellcore.com (Perry Metzger) writes: > [discussion about complexities with using Gnu Emacs in server mode] > >Oh, come on. This isn't a legitimate objection. You can easily >determine if there is an emacs running on the same tty or pty, so the >question of "do I send it a SIGCONT" is easy to handle. Similarly, the >client can pass its pid to the emacs in server mode and get a signal >back telling it to wake up. > >I think the benefits of having a scheme like this would be great. Most >people in the world still use terminals, not bitmapped displays. >Providing something that they can use conveniently is a big plus. On a perfectly vanilla Unix system (no sockets, streams, ptys, shared memory or messages), it is possible to implement a sort of job control, making it possible to switch back and forth between Gnu Emacs and almost any process running under it. Scenery: You start Emacs early in your login session. When you need an inferior shell, perform the 'suspend-emacs' command, which on Unix systems without job control will put you in an inferior shell. Then use that shell for whatever you need to do. When you need to run Emacs again, don't exit the shell, and don't start a new Emacs. Just do the command 'pop'. It will bring you back to the suspended Emacs. The 'suspend-emacs' command will bring you back to where you were when you typed 'pop'. This works not only for shells, but for all programs that allow the user to spawn programs (rn, mail, vi, Lisp, ...). This is immensely useful when all you have is a single screen. Even in a window system, I often use it instead of having to create a new window and leave the Emacs window unused. This scheme requires some rather small (but non-trivial) changes to the Gnu Emacs C code, no changes to the Emacs Lisp code, and the additional program 'pop'. Here is how it's done: Emacs keeps the pid of the inferior shell in a variable. Only if it is 0 will 'suspend-emacs' create a new shell. If it isn't 0, there is a temporary file /tmp/pop<n> where <n> is the pid of Emacs. In that file is the pid of the 'pop' process. To suspend, Emacs sends the 'pop' process a certain signal (SIGUSR1 in System V) and then goes to sleep. The 'pop' process simply exits upon receipt of the signal. [Perhaps this is telling it backwards..] When 'pop' is invoked, it creates the above-mentioned file with its own pid in it. The pid of Emacs is taken from the environment variable POPID, where Emacs will have put it when it created the inferior shell. 'pop' sends Emacs a signal and then does a 'pause', ignoring INT and QUIT signals. -- Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden email address: aj@zyx.SE or <backbone>!mcvax!enea!zyx!aj
rbj@ICST-CMR.ARPA (Root Boy Jim) (03/24/88)
From: Perry Metzger <sambation!perry@BELLCORE.ARPA> >> Why so much work? Why doesn't emacsclient write its message and >> then SIGCONT the stopped emacs, > >Because that's not how it was designed to work. The emacs server may >already be running in another window. In this case, the `window' exists >in time rather than in space. Anyway, how would the server know how to >get back to the client? You'd only have solved half the problem. Oh, come on. This isn't a legitimate objection. You can easily determine if there is an emacs running on the same tty or pty, so the question of "do I send it a SIGCONT" is easy to handle. Similarly, the client can pass its pid to the emacs in server mode and get a signal back telling it to wake up. I think the benefits of having a scheme like this would be great. Most people in the world still use terminals, not bitmapped displays. Providing something that they can use conveniently is a big plus. I didn't say it couldn't be done. I said that is not how it was designed. And of course, sending an extraneous SIGCONT shouldn't really hurt. You mention an interesting point about terminals. The bitmap freaks are actually saying `who uses terminals anymore?' And the laser printer freaks think that no one uses line printers anymore either. Hmmmmph! (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 You mean you don't want to watch WRESTLING from ATLANTA?