emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-tty problems involving virtual terminal


From: Stephen Berman
Subject: Re: multi-tty problems involving virtual terminal
Date: Fri, 23 Nov 2007 15:31:45 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux)

Sorry for the long delayed response.

On Wed, 19 Sep 2007 18:17:56 -0700 Dan Nicolaescu <address@hidden> wrote:

> Stephen Berman <address@hidden> writes:
>
>   > GNU Emacs 23.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of
>   > 2007-09-17 on escher
>   > 
>   > I recently updated to the post-multi-tty merge and have only begun to
>   > experiment with it.  The first couple of uses, involving the Linux
>   > console X client, were unproblematic, but today I unexpectedly had to
>   > use the multi-tty functionality from a virtual terminal and ran into
>   > some problems.  Before updating I didn't follow the various multi-tty
>   > threads very closely, so if what I describe below has come up before,
>   > I would appreciate a pointer and apologize for the redundancy.
>   > 
>   > I had Emacs running under X with the Emacs server started, as usual.
>   > Suddenly X locked up, but I was able to switch to a virtual terminal
>   > and invoked emacsclient, and everything was fine, all the buffers of
>   > my Emacs started under X were still open.  Then I killed the X server
>   > and restarted it.  When I logged in to the KDE desktop again, I
>   > noticed that Emacs (still only running as a client on the virtual
>   > terminal) was consuming 99% CPU.  I tried to exit Emacs on the virtual
>   > terminal with C-x C-c but it failed with a message to the effect
>   > "Cannot iconify sole frame" (I don't remember the exact wording).  I
>   > went back to the KDE desktop and invoked emacsclient again, starting
>   > an X client.  Then I returned to the virtual terminal and tried C-x
>   > C-c again; this time I got the message "The server still has clients;
>   > delete them? (yes or no)."  I type no and hit return and the virtual
>   > terminal immediately locked up without making a line feed.  I went
>   > back to X and the Emacs X client was gone and in the shell from which
>   > I had invoked it was the message "Waiting for Emacs...".  The
>   > emacsclient process launched from the virtual terminal was still
>   > running; I killed it but still the terminal remains locked up and I do
>   > not know how to unlock it.
>
> A bug fixing problems with Gtk+ and closing the X11 connection was
> checked in yesterday. Could you please try again your scenario?

In the intervening time I haven't had a spontaneous lockup of X so I
could not exactly reproduce the scenario.  (I did have occasion to start
emacsclient from a virtual console after X locked up, but that involved
an Emacs bug in the Gtk+ tool bar (since fixed) and I had to kill the
emacs process to unlock X.)  But I just tried the following on GNU Emacs
23.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.0) of 2007-11-21 on
escher.  I switched from X with a running Emacs to a virtual console,
there invoked emacsclient -t and got my running Emacs session.  I typed
C-z and in the shell restarted the X server.  Before logging back on to
KDE I returned to the virtual console and typed fg, and the shell
returned the string "emacsclient -t" but in fact no emacs or emacsclient
process was running any more.  Is this the expected behavior?  (In other
words, killing X under which Emacs is running also kills Emacs clients
spawned in a virtual console?)

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]