Re: Ben's XEmacs is inoperable at the console in GNU/Linux
Don't know if this is of any help, I got it when I did a killall xemacs from
another xterm. This, and the fact the cursor bliknks when the mouse is
clicked in the misbehaving console, leads me to restate my assertion that the
console is locked. It appears a better statement would be XEmacs does not
respond to keyboard input nor to mouse events (other than the cursor
blinking). I'll see if I can't generate a core, though I'm no pro at this.
Lisp backtrace follows:
next-command-event()
byte-code("..." [unread-command-event circ-tmout tmout
startup-message-timeout
add-timeout #<compiled-function (ignore) "...(5)" [nil ... ...] 3> nil
display-
splash-frame sit-for 0 next-command-event] 4)
# (catch tmout ...)
# (unwind-protect ...)
# bind (tmout circ-tmout)
command-line-1()
# bind (command-line-args-left)
command-line()
# (unwind-protect ...)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
Terminated
On Sunday 17 March 2002 12:26 pm, Steven T. Hatton wrote:
On Sunday 17 March 2002 09:27 am, William M. Perry wrote:
> Steve Youngs <youngs(a)xemacs.org> writes:
> > Hi Ben!
> >
> > Just found something else that's bad... really bad... show-stopper bad
> > even.
> >
> > Running XEmacs from a console in Linux, it'll load up, but that's all
> > it will do. Press any key once it's loaded and it just sits there
> > frozen solid. The only way out is to switch to another console and
> > kill the xemacs process.
> >
> > No core files are generated, any idea how I can help you debug this
> > one?
> >
> > On the plus side, from the console it loads fast. :-)
>
> I saw this just yesterday in the GTK build and thought it was GTK
> related. Are you building just with TTY support? X11? GTK?
>
> -bp
I get a locked up console when I try to run sans $DISPLAY. I should have
said something, but the system at work where I first saw this is suspect in
its own right. I have now verified this on my old reliable here at home.
-- STH