On Mon, Jan 30, 2017 at 12:28:21 +0000, Roy Marples wrote: > On 30/01/2017 11:40, Valery Ushakov wrote: > > It was my impression that the traditional interface was for a program > > to just set global ESCDELAY variable directly and that set_escdelay() > > was a wrapper function intended to provide internal locking for > > multithreaded programs. I.e. it's not a setter that hides where and > > how the value is stored. > > > > From a quick look at the code in current it looks like you've broken > > this for existing programs that just set the ESCDELAY variable > > directly, since the new code ignores the variable. > > That's a fair observation. > > Maybe we should store a bit on the screen to indicate whether we should > use the screen variable or the global variable?
It's not clear what would be the right thing to do since ESCDELAY is non-standard (does anyone know if it predates set_term? my guess would be yes). I guess the least ugly backward compatible solution would be to use the global variable in getch() and save/restore its value in the screen's structure when set_term() is called. -uwe
