Re: [PATCH 2/2] git-gui: revert untracked files by deleting them

> > +             after idle [list after 0 [list \
> > +                     delete_helper \
> >                       $path_list \
> > -                     [concat $after [list ui_ready]]
> > +                     $path_index \
> > +                     $deletion_errors \
> > +                     $deletion_error_path \
> > +                     $batch_size \
> > +                     ]]
>
> Using `after idle` means in theory we put an undefined maximum time
> limit on the deletion process. Though I suspect in real life it would be
> a pretty short time.
>
> Nonetheless, should you instead do this asynchronously, instead of
> waiting for the event loop to enter an idle state? This means using
> `after 0` directly, instead of doing `after idle [list after 0...`. I
> haven't tested it, but AFAIK this should also keep the UI active while
> not depending on the state of the event loop.
>
> What benefits does your way have over just passing the entire list
> (without batching) to an async script to do processing in the
> background?

> An after idle that reschedules itself causes trouble, as the manual warns (PYK 2012-09: the docs no-longer contain this warning, but it still applies):
>
>      At present it is not safe for an idle callback to reschedule itself
>      continuously.  This will interact badly with certain features of
>      Tk that attempt to wait for all idle callbacks to complete.
>      If you would like for an idle callback to reschedule itself
>      continuously, it is better to use a timer handler with a zero
>      timeout period.
>
> Even this warning is oversimplified. Simply scheduling a timer handler with a zero timeout period can mean that the event loop will never be idle, keeping other idle callbacks from firing. The truly safe approach combines both:
>
>     proc doOneStep {} {
>      if { [::sim::one_step] } {
>          after idle [list after 0 doOneStep]
>          #this would work just as well:
>          #after 0 [list after idle doOneStep]
>      }
>      return
>     }
>     sim::init .c 640 480
>     doOneStep
>
> This skeleton should be considered the basic framework for performing long running calculations within a single Tcl interpreter.