Re: Questions about throw-on-input

[yyoncho <yyoncho@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4365 bytes --]

Sorry, I accidentally pressed send before finishing my reply.

I was about to suggest using the quit-flag to indicate - "instead
of quitting process events during the execution of the block", like that

(let ((quit-flag :process-events))
  (slow-operation))

Not sure if this will work but in case it works, it will be great!

Thanks,
Ivan

On Fri, May 8, 2020 at 7:36 AM yyoncho <yyoncho@gmail.com> wrote:

> Hi Stefan,
>
> Thank you for your reply! Can you elaborate on "won't have the desired
> semantics"? I would suggest something crazier - using inhibit-quit to
>
> Thanks,
> Ivan
>
> On Fri, May 8, 2020 at 4:59 AM Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > 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.
>> >>
>>
>>

[-- Attachment #2: Type: text/html, Size: 6391 bytes --]