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

[Michael Heerdegen <michael_heerdegen@web.de>]

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.

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

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

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.

Just extrapolating my university knowledge however...


Michael.