Hi dwk/Thomas, On 12/10/13 17:09, Jonathan McCrohan wrote: > On 20/09/13 20:33, d wk wrote: >> Sorry for taking so long to respond, I used an email address I don't check >> that often. I will be more vigilant in the future. Jonathan, your patch >> makes sense. Thanks for testing it more thoroughly than I did. Also, >> keyboardsetup() is using a similar method of usleep(1), which could be >> changed to usleep(1000). >> >> More thoughts from doing a bit of research: >> >> 1) There is a timeout() function (http://linux.die.net/man/3/timeout) which >> allows you to specify how long getch() should block for; timeout(-1) is >> nonblocking input and timeout(1000) is non-blocking input without having to >> call usleep. >> >> 2) For the specific case of the ESCAPE key, ncurses will by default wait >> for one full second before returning the ESC keypress to you. This is to >> support inputting extended keys like the arrow keys by typing (say) the >> full "ESC [ A" sequence (which corresponds to the up arrow key). If you >> don't want this but do want the ESCAPE key to work with a very short delay, >> just set the ESCDELAY environment variable: >> http://blog.rlucas.net/bugfix/curses_ui_escape_is_slow/ >> http://en.chys.info/2009/09/esdelay-ncurses/ >> >> I think by setting ESCDELAY you could easily change keyboardsetup() and >> getkey() to use blocking input, with the ESCAPE key still working. The only >> other place the code calls getch() is in correlation.c, where extra user >> input is discarded. You could implement that with timeout() or better yet >> use the built-in ncurses function for that purpose, flushinp() [ >> http://man.he.net/man3/flushinp]. >> >> If I have time this weekend I will write a patch for this, unless dettus >> beats me to it! > > Any update on this?
Ping? Any update on this? Thanks, Jon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
