bug#23430: 25.0.93; iter-defun does not support special form save-current-buffer

[Dmitry Gutov <dgutov@yandex.ru>]

On 16.08.2020 16:33, Michael Heerdegen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Before we close this, I'd like to hear from somebody who understands
>> what generator.el is actually for.
> 
> I think it's just a straightforward implementation of generators as
> described here:
> 
>    https://en.wikipedia.org/wiki/Generator_%28computer_programming%29
> 
> I learned about them in university, and have used them once in a while.

Right. I was really wondering, though, whether we can/should use them 
more often.

> AFAIK handling asynchronous process output is not a good task for them.

Perhaps if we also used a separate thread for waiting for the output to 
come...

> I think: The problem of the concept of generators in an editor is that
> generators are good for saving the state of a computation, but Emacs as
> an editor has a lot of "environment" state (current buffer, value of
> point, ...), and when the computation represented by the generator
> messes with this state (or has side effects), the concept doesn't fit
> that well.
> 
> When working with streams, I make the handling of the according part of
> the environment explicit saving it in variables (iterators are closures)
> and "yield" outside of any xxx-recursion, in your introductory example,
> that would look like this:
> 
> #+begin_src emacs-lisp
> (require 'generator)
> 
> (iter-defun my-search (str buf)
>    (with-current-buffer buf
>      (goto-char (point-min)))
>    (let ((pos (point))
>          (yield nil)
>          (done nil))
>      (while (not done)
>        (when yield
>          (iter-yield yield)
>          (setq yield nil))
>        (with-current-buffer buf
>          (goto-char pos)
>          (if (search-forward str)
>              (setq yield (match-beginning 0)
>                    pos   (point))
>            (setq done 0))))))
> #+end_src

Thanks. I think this is fairly close to the approach I showed in the 
patch. Problem is, it's no shorter than an implementation one can write 
using plain functions. Longer, usually.

> I guess it would be nice if that could work implicitly in some way, but
> that would probably require the introduction of new special forms
> adapted to the situation, like `iterator-save-buffer-and-point' or so.

Perhaps.