Re: [Feature suggestion] (user configurable) timeout for generating completion lists

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 20,  4:13pm, Arseny Tolmachev wrote:
} 
} Sometimes you press [Tab] by instinct when in directory that is
} network-mounted and has some millions files in it.
} In this situation zsh basically ignores the [Ctrl+C] and don't respond to
} anything for a bit of time.

There are two possible situations here.  (Probably more than two, but
only two likely ones.)

(1) The shell process is actually in "disk wait" condition, blocked to
wait for the NFS volume to respond.  If this is the case, there's not
a lot that can be done; any timeout that might be set up will also be
held until the disk condition clears.

(2) The shell is chewing CPU cycles for a large amount of file data,
but ignoring or deferring some signals while it does so.  In this case
there's some hope of a timeout working.

It could also be switching back and forth between these two states ...
but that can be treated as case (2) except that it might take longer
for the timeout to work.

} It would be very great if there was a way to specify a timeout for
} completion generation for zsh. Error message can be something like
} "completion timeouted".
} What do you think about this?

I've been poking at it for a couple of hours trying to repeatably induce
case (2), and I can't get reliably force it to happen.  It would be
helpful if somebody who experiences this problem could attach to the
stuck zsh with gdb and grab a stack trace.  Note that in case (1) above,
gdb is likely to end up wedged as well.

Anyway, anything we could do for a timeout would likely require handling
a signal, which pretty much means we're going to bail out of the shell
functions (e.g., _main_complete and everything below it) that perform
completion.  I don't immediately see how to produce an error message in
that case without messing up the ZLE display unless we also have a shell
level trap handler (instead of a purely internal one).  But in order to
even get that far, we have to know what's holding things up.