ESC Key very slow

  • Anonymous - 2014-04-16

    I'm exploring the possibility of using GNU Cobol to port/uplevel an ancient RM/COBOL application. The application is quite interactive via DISPLAY/ACCEPT w/o using a SCREEN SECTION. I'm trying to make this a "port" as much a possible - specifically making it operate as close to the original as possible.

    So far I've been able to easily see how I might deal with the screen, function keys, etc., but I've run in to a stumbling block with the Escape key. I did figure out how to make it work at all, but it's ridiculously slow. Function keys respond/are recognized instantly, but Escape takes about half a second or so to be recognized. This is going to cause some issues with my client. It seems to happen both in cygwin (2.1) (ncurses?) and with a native windows build of 2.0 using pdcurses.

    Any ideas?

  • Brian Tiffin

    Brian Tiffin - 2014-04-17


    ESCDELAY=25 ./tui-program

    Export an environment variable, ESCDELAY=in-milliseconds

    See if that has any effect with your versions. If it does, it may also exhibit the rare miss of proper cursor or function key detection, giving a three character squiggly string after an unintentional escape.

    Otherwise, old school, means digging around in stty settings and terminfo files and, well, yikes, voodoo. :-)

    Looked more, it might be better to try


    but I'm not sure if that works before curses init, it should.


    Last edit: Brian Tiffin 2014-04-17
  • Simon Sobisch

    Simon Sobisch - 2014-04-17

    Brians first variant will only work for cygwin/MinGW.

    It seems that ESCDELAY is not available in pdcurses at all (at least it doesn't have an exported function or static var for it).

    Just tested with pdcurses builds (OpenCOBOL 1.1 MinGW and GNU Cobol 2.0 Visual Studio, different pdcurses versions) on Win7 with


    I got all function keys immediately (both with/without ON EXCEPTION clause for ACCEPT) - no matter if/how ESCDELAY is set.

    @Brian: please investigate this further (meaning try and check the results ;-)) as I wonder if it would be useful to change libcob/screenio.c to

    +#ifndef    HAVE_LIBPDCURSES
    +   /* set the ESCDELAY via the environment before initscr is called; this
    +      means that it will be ignored by curses implementations that don't
    +      support it */
    +   if (getenv ("ESCDELAY")) == NULL) {
    +       setenv("ESCDELAY", "25", 0);
    +   }
        if (!initscr ()) {
            cob_runtime_error (_("Failed to initialize curses"));
            cob_stop_run (1);


  • Anonymous - 2014-04-21

    Thanks, I'll try those suggestions a bit later and post back my result.


  • Anonymous - 2014-04-21

    Just got a chance to try this under cygwin. The first variation Brian suggested works well, but the second doesn't work for me. But at least I have a working solution - thanks a lot.


    • Brian Tiffin

      Brian Tiffin - 2014-04-21



  • Simon Sobisch

    Simon Sobisch - 2014-04-22

    @Brian: Do you investigate the suggested change to libcob/screenio.c (especially the pro/con)?
    @Bill: Good that you have a working solution. Î suggest to get a SF login for further posts. Please tell us your conversion story (issues you had, how you solved them, ...)


    • Brian Tiffin

      Brian Tiffin - 2014-04-27

      Not yet, but will. I'm cluttering a Fedora libvirt setup with various virtual machines. Pretty amazing technology, but anyway, it'll allow for more comprehensive testing.


  • Bruce Martin

    Bruce Martin - 2014-04-28

    if you have found this site ( yet but Microsoft provides Virtual Machines for Testing internet Explorer on various versions of Windows. So If you want to test you Cobol generated HTML pages with IE.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks