Terminal resize while pick is running

[prahlad]

If we resize the terminal after pick is initiated, the choices doesn't print as expected.
This may be because the variables 'lines', 'columns' are not getting updated, if the terminal size is disturbed after 'setupterm' been executed.
One possible solution may be to capture the event SIGWINCH and update the variables accordingly.

[Anton Lindqvist]

On Tue, May 03, 2016 at 06:06:12AM -0700, prahlad wrote:

If we resize the terminal after pick is initiated, the choices doesn't print as expected.
This may be because the variables 'lines', 'columns' are not getting updated, if the terminal size is disturbed after 'setupterm' been executed.
One possible solution may be to capture the event SIGWINCH and update the variables accordingly.

Agreed, even tho it is not a concern of mine but a interactive program
should behave well and resize accordingly. Some thoughts regarding the
implementation:

• We don't want to be interrupted while doing important work. The
  SIGWINCH signal should therefore only be allowed while the program is
  waiting for user-input (inside the get_key function). This can be
  achieved using ppoll(2).

• The signal handler should be kept as short as possible to avoid any
  potential data-race:

  void
  onsignal(int sig)
  {
  resize = sig == SIGWINCH;
  }

• The get_key function could return -1 if it was interrupted which then
  can be checked in the selected_choice function and if the global
  variable resize is set call ioctl in order to obtain the new
  dimensions and lastly reset the resize variable.

• The SIGWINCH signal is not portable(?) and its presence should be
  detected using autoconf.

Are you interested in implementing this?

[prahlad]

If I understand this correctly, you want to allow the signal only while we are waiting and block during processing part. In that case there is a chance that we may miss the event if we signal get blocked.
May be signalfd will suit here, which will block the signal and sends it through a fd and the handling can be defered through poll.

edit:looks like signalfd is not portable

[Anton Lindqvist]

On Wed, May 04, 2016 at 05:05:05AM -0700, prahlad wrote:

If I understand this correctly, you want to allow the signal only while we are waiting and block during processing part. In that case there is a chance that we may miss the event if we signal get blocked.
May be signalfd will suit here, which will block the signal and sends it through a fd and the handling can be defered through poll.

Correct, but I still think it's a reasonable trade-off.

[Anton Lindqvist]

Resizing support has been implemented and will be released soon.