Re: Asynchronous insertion / saving of buffers

[Ted Zlatanov]

On Fri, 20 Apr 2012 15:49:11 +0200 Michael Albinus <address@hidden> wrote: 

MA> Ted Zlatanov <address@hidden> writes:
>> Maybe you can approach this similarly to url-future.el?
>> 
>> I intended to make it generic but only had use for the URL retrieval
>> case; you'll see it's easy to adapt it to be generic.  Futures map well
>> to combinations of synchronous/asynchronous operations, in my
>> experience, and they can be chained.

MA> Maybe. Unfortunately, I don't understand how to use it, reading the
MA> source. Do you have an example which demonstrates its usage?

Sorry, I have done a bad job documenting it :)  If the explanation below
is helpful, I'll change the docs in the file.

The idea is not new; Scheme has `delay' and `force' to do similar work.
It's a way to promise work but not necessarily use it immediately.

So let's make a future to promise the evaluation of 2+2:

#+begin_src lisp
(let ((f (make-url-future :value (lambda () (+ 2 2))
                          :callback (lambda (future) (debug future))
                          :errorback (lambda (future &rest error)
                                       (debug future error)))))

  (message "Future completion status before call: %s, value %s"
           (url-future-completed-p f)
           (url-future-value f))
  (url-future-call f)
  (message "Future completion status after call: %s, value %s"
           (url-future-completed-p f)
           (url-future-value f)))

#+end_src

This will print (with a debugger call you can `c' out of, in the callback):

Future completion status before call: nil, value (lambda nil (+ 2 2))
Future completion status after call: t, value 4

Replace (+ 2 2) with (+ 2 nil) in the value to see error handling.

Emacs Lisp doesn't have support for delayed evaluation, so this was a
way to work around that limitation and provide a generic interface.  I
don't know if the language could support tighter integration with
delayed evaluations without core changes.

Futures can be cancelled in this implementation.

It's under url-future-* because we wanted to see how useful it would
prove before making it more prominent.  If you find this approach
useful, let me know; if not and you think it could be useful with some
API or code changes then that's good to know as well.

Thanks
Ted