From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-36712-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 27556 invoked by alias); 30 Sep 2015 09:41:22 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 36712
Received: (qmail 11792 invoked from network); 30 Sep 2015 09:41:21 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID
	autolearn=ham autolearn_force=no version=3.4.0
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=content-transfer-encoding:content-type
	:date:from:message-id:mime-version:subject:to:x-sasl-enc
	:x-sasl-enc; s=smtpout; bh=FukipIJNYiaYt6HV7pTFxbF3uKE=; b=ZeObV
	ERO3Hh/G6LEtgxj4QeSzKOfEVwJLkl3wsH6+g22dpLwxyoNZ3m7JtCgkvFC6UrIQ
	dBnaMZ3WI8Qypk0FFimvQhDI33ZtA85gBfC59xvuCgaxARMXXl9xWRQVM8VZPVp+
	cAzPlq0ky2YH0IsqFS5qDwTWhUUz5mhlq7wvvc=
X-Sasl-enc: ckaZyumH7EJjKsbByxeQ8Ui1WoP830FDsS9vfxJmmE6E 1443606080
To: Zsh hackers list <zsh-workers@zsh.org>
From: Andrew Janke <floss@apjanke.net>
Subject: zcurses input timeout and window resizing
Message-ID: <560BAE3B.5050409@apjanke.net>
Date: Wed, 30 Sep 2015 05:41:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Zsh folks,

I'm running in to an issue with the interaction between "zcurses 
timeout"/"zcurses input" and terminal window resizing. On OS X, it seems 
that if you resize a window while waiting on a "zcurses input", the 
timeout will effectively be ignored, and "zcurses input" will block 
until actual input is received.

Sounds like this was a known possible issue. The Src/Modules/curses.c 
file has a comment due to it interacting poorly with unspecified 
behavior of getch wrt handled signals.

https://github.com/zsh-users/zsh/blob/6ff0628182ac74bbf22dc02edcc9a148f12767db/Src/Modules/curses.c#L1072-L1104

      * There remains a potential bug here in that, if the caller has set
      * a timeout for the read [see zccmd_timeout()] the countdown is very
      * likely restarted on every call to wgetch(), so an interrupted call
      * might wait much longer than desired.

I think I'm actually running in to that potential bug here on Mac OS X 
10.9.5.

Test code:

#!/bin/zsh

# test_zcurses_resize.zsh
#
# Test how window resizing interacts with zcurses

zmodload zsh/curses

zcurses init
zcurses timeout stdscr 1000

logfile=test_zcurses_resize.log
rm -f $logfile
while (( 1 )); do
   printf "%4s: %s %s stty: %s\n" $SECONDS $LINES $COLUMNS "$(stty 
size)" >>$logfile
   zcurses input stdscr key keypad mouse
   printf "%4s: input received: \$?=%s k='%s' kp='%s' m='%s'\n" \
     $SECONDS $? "$key" "$keypad" "$mouse" >>$logfile
done

# end test_zcurses_resize.zsh

"watch -n 0.5 tail -15 test_zcurses_resize.log" to see results.

When I run it on OS X (in iTerm2 or Terminal.app) and resize the window, 
it stops producing new output indefinitely, until I actually hit a key 
or do mouse input. On Debian Linux 8, it still works after the resize, 
with the "zcurses input" timing out as expected. Tested on both zsh 
5.0.2 and 5.1.1.

Any known workarounds to this? Maybe it's dependent on the version of 
curses? My OS X zsh is linked against libncurses.5.4.dylib; the Debian 
one against libncursesw.so.5.

The "tetriscurses" example program seems to stay live through window 
sizes on the same OS X system, and I can't figure out what it's doing 
differently to keep the timeout working through window resizes.

Cheers,
Andrew