Re: "gnuclient -nw" oddity (was "[COMMIT] gnuclient bug on Ben's part")
Ar an chéad lá is fiche de mí Lúnasa, scríobh Tim Connors:
> > 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?
I see the crontab behaviour; looks like there are a lot of quirks of
gnuclient’s interaction with process groups that need to be worked out. (I
don’t think McKusick, Joy and the rest had gnuclient and XEmacs or anything
like them in mind mind when they came up with the idea first.)
I haven’t seen the keep-updating-the-screen behaviour. I do occasionally see
a broken reaction to terminal size changes; gnuclient will think the
terminal two or three characters by two or three characters, and the only
way to get a usable frame is to C-x 5 0 then call gnuclient again.
--
Santa Maradona, priez pour moi!