On 30 September 2016 at 13:28, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> But I've catched another thing. After Ctrl-C in .recursiveedit the
> timeouts at select() in raw_getbyte() stop occuring. Here is simple

I've investigated this further. There is calc_timeout() called in the
select-loop:

  case ZTM_MAX:
      /*...*/
      calc_timeout(&tmout, do_keytmout);
      // MY DEBUG
      FILE *_F = fopen("/tmp/recursive.txt", "a+");
      fprintf( _F, "^^^ LOOP-CALLED calc_timeout: tmout.tp == %d\n", tmout.tp );
      fclose(_F);
      break;


The calc_timeout is capable of setting tmout.tp to ZTM_NONE. I have 3
debug prints:

-- tmoutp->tp <- ZTM_NONE / calc_timeout( do_keytmout: 0 ), keytimeout: 4
== CALC_TIMEOUT() one more chance (timedfns)
-- CALC_TIMEOUT() !tfnode break

Code of the last debug message is below:

            LinkNode tfnode = firstnode(timedfns);
            Timedfn tfdat;
            time_t diff, exp100ths;

            if (!tfnode) {
                // MY DEBUG
                FILE *_F = fopen("/tmp/recursive.txt", "a+");
                fprintf( _F, "-- CALC_TIMEOUT() !tfnode break\n",
tmoutp->exp100ths );
                fclose(_F);
                break;
            }

So, the linked list doesn't have any elements, and calc_timeout()
exits with ZTM_NONE instead of ZTM_FUNC like it does all the time (so
normally it executes further the for(;;) there and overwrites initial
ZTM_NONE with ZTM_FUNC). This is after the lucky Ctrl-C. Wonder why no
ZTM_KEY? Also, believe me, I occured 2 spontaneous stopping of
timeouting right after shell started. Tried to catch this on asciinema
but no luck. It looket like – few timeouts occured and then they
stopped. Didn't have precise debug prints then..

Best regards,
Sebastian Gniazdowski