On Fri, 18 Aug 2006, Aidan Kehoe wrote:
Ar an seachtú lá déag de mí Lúnasa, scríobh Mike Kupfer:
> It appears to result from running "gnuclient -nw" from the same shell
> that I started XEmacs in. If I run "gnuclient -nw" from a different
> shell, things work normally. Want me to file a formal bug report (M-x
> report-xemacs-bug)?
No, I can reproduce. There's some logic related to TTYs and controlling
processes here that I need to understand some more before I can fix this,
though. Workaround; don't start TTY gnuclients from the same shell you
started a window system XEmacs.
I have some more odd behaviour regarding gnuclient -nw:
Start xemacs from a random tty.
Start gnuclient -nw from another shell. Works fine. Can ctrl-z out of
there, and fg back in.
But fork gnuclient -nw from another program (eg, crontab -e), via
$EDITOR=a shell script, and ctrl-z now just waits indefinitely until I
killall -CONT gnuclient.
Sometimes, related to this (circumstances I can't recall, but may try to
reproduce if you can't reproduce), gnuclient will keep on updating the
screen, I think there have been conditions where both the shell and xemacs
fight for and get the keyboard input randomly.
Does anyone else see this?
--
Tim Connors