Job management (CTRL+Z, fg) borks the display #48

New Issue

asdf · 2019-10-08T04:54:34Z

asdf commented

2019-10-08 04:54:34 +00:00

In Bombadillo, if the application is suspended using CTRL+Z and then brought back using the fg command, a few weird things happen:

The screen is not redrawn
Hotkeys are printed on the screen
Enter key draws new lines to the bottom of the screen
It's possible to eventually get back to normal by loading a new page (like a bookmark) twice.

In Bombadillo, if the application is suspended using CTRL+Z and then brought back using the `fg` command, a few weird things happen: 1. The screen is not redrawn 1. Hotkeys are printed on the screen 1. Enter key draws new lines to the bottom of the screen It's possible to eventually get back to normal by loading a new page (like a bookmark) twice.

sloum commented

2019-10-08 05:20:14 +00:00

I would guess that backgrounding it puts the terminal into a different mode and then does not return it to its previous mode afterward. I would very much like this to work. I winder if ctrl+z sends a signal to the running process? If it does, I can likely intercept it somehow and handle the change. Otherwise, I'm not sure how to do so, except to just set the terminal mode over and over again for each draw? But that seems like a really wrong solution.

sloum added the

bug

help wanted

labels 2019-10-08 05:20:21 +00:00

sloum commented

2019-10-09 02:58:38 +00:00

I have looked into this a bit. The signal package seems to let us catch this. I could not find a good example of how to do so, but have a vague idea. If we spin off a go routine that is set to signal.Notify for the signals we want, we may be able to handle this.

The two signals in question seem to be SIGTSTOP and SIGCONT. At least as best as I have been able to decipher.

I definitely think this would be nice to have. If anybody sees this issue and wants to work on it (yourself included @asdf) it would be appreciated. Otherwise I'll try to get to it, but there are a few other things I'd like to get to first.

I have looked into this a bit. The [signal](https://golang.org/pkg/os/signal/) package seems to let us catch this. I could not find a good example of how to do so, but have a vague idea. If we spin off a go routine that is set to signal.Notify for the signals we want, we may be able to handle this. The two signals in question seem to be `SIGTSTOP` and `SIGCONT`. At least as best as I have been able to decipher. I definitely think this would be nice to have. If anybody sees this issue and wants to work on it (yourself included @asdf) it would be appreciated. Otherwise I'll try to get to it, but there are a few other things I'd like to get to first.

asdf self-assigned this 2019-10-11 02:07:49 +00:00

sloum commented

2019-10-11 02:49:22 +00:00

Closed by #53

Closed by https://tildegit.org/sloum/bombadillo/pulls/53

sloum closed this issue

2019-10-11 02:49:22 +00:00

Sign in to join this conversation.