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

[Bart Schaefer <schaefer@brasslantern.com>]

On Jan 24,  9:46am, Greg Klanderman wrote:
}
} For slow completion due to calling out to a separate process for
} completions (_git comes to mind) if that is not currently
} interruptible it seems like there might be some hope of adding a
} timeout or ensuring C-c will interrupt.

This is the thing I had a hard time reproducing.  Even if I force
the completion function to be very busy with a loop, I can interrupt
it.  (Oddly the value of $? is always 0 in _main_complete after I
hit ^C, so I can't detect the signal and issue a message.)

} The biggest problem I've had with completion being unresponsive was
} due to automounts at work (currently have ~53k under a handful of
} mount points).  Using the fake-files zstyle mostly works until
} completion tries to stat all those automounts

I think this is analogous to the situation that started this thread.

} to determine the file type in order to append a '/' or ' '.

... which is difficult to do if there's an external program doing the
stat.  Not impossible, but it means passing a lot of structured data
through a pipe, which might slow down more common cases.

(Maybe this is why Meino wants "find -print0 -ls". :-> )

} So locally I run zsh with a
} small patch (to ztat()) that uses a shell variable to configure
} automount roots under which all immediate entries are assumed to be
} directories without stat'ing.  Works great, though I don't think
} several years ago you were willing to incorporate that into zsh.

Doesn't sound terrible, but I don't think it would solve the original
problem, which if I'm right is that NFS listing is big/slow after the
mount is already completed.