Re: Questions about throw-on-input

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Out of curiosity, do you think that having a function
> (process-events) which will process all keyboard(?) events
> and resume the current invocation can be implemented easily?

It can be implemented, but it won't have the desired semantics.
If you want something robust you have 2 options:

- write in an event-driven style (or CPS style) so that you can easily
  stop at various points in the program and stash the rest of the
  computation for later.

- use a thread (which will basically do the same, but transparently,
  i.e. without the awkward programming style.)


        Stefan


> AFAIK a lot of gui toolkits have that kind of function, e. g.
> https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.application.doevents?view=netcore-3.1
>
> IMO it will be very useful for certain cases.
>
> Thanks,
> Ivan
>
> On Thu, May 7, 2020 at 3:37 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > From: Ivan Yonchovski <yyoncho@gmail.com>
>> > Date: Thu, 07 May 2020 10:31:23 +0300
>> >
>> >
>> > 1. In the following example:
>> >
>> > (dotimes (_ 10)
>> >   (message "Length %s"
>> >            (length
>> >             (let (result)
>> >               (catch t
>> >                 (let ((throw-on-input t))
>> >                   (dotimes (counter 10000000)
>> >                     (push (number-to-string counter) result))))
>> >               result))))
>> >
>> > .. after I execute the following block each of the 10 computations will
>> be
>> > canceled after pressing C-n for example, how do I force the handling of
>> > the command to be processed? I tried redisplay but it does not help.
>>
>> Invoking redisplay won't help because the commands which interrupted
>> the inner loop (C-n) were not yet executed.  Emacs will process them
>> only after the outer loop ends, because that outer loop is the last
>> command, and it is still being executed.  Emacs doesn't perform
>> commands in the middle of another command.
>>
>> > (message "Length %s"
>> >          (length
>> >           (let (result)
>> >             (catch t
>> >               (let ((throw-on-input t))
>> >                 (dotimes (counter 10000000)
>> >                   (push (number-to-string counter) result))))
>> >             result)))
>> >
>> >
>> > (run-with-idle-timer
>> >  0.0
>> >  nil
>> >  (lambda ()
>> >    (message "Length %s"
>> >             (length
>> >              (let (result)
>> >                (catch t
>> >                  (let ((throw-on-input t))
>> >                    (dotimes (counter 10000000)
>> >                      (push (number-to-string counter) result))))
>> >                result)))))
>> >
>> > The issue is with the second block, it seems like throw-on-input is
>> > disregarded when used in run-with-idle-timer. Can anyone confirm if this
>> > is a bug/desired behavior or I should use something else if I want to
>> > run cancelable tasks in on-idle?
>>
>> When the time function is run, Emacs binds inhibit-quit to t (so that
>> the user's C-g would not interrupt the timer function, for example).
>> And throw-on-input uses quitting to do its job.
>>
>> Why do you need to interrupt an idle timer like that?  The usual way
>> of doing this is not to call expensive functions in an idle timer, and
>> if you have a lot of processing, divide them into small enough chunks
>> and do it piecemeal.  That's what jit-stealth font-lock does, for
>> example.
>>