bug#17893: 24.4.50; (error "Marker does not point anywhere")

[Stefan Monnier]

> Bother: this is actually the tip of an iceberg.  Buffer local
> variables that get cloned by clone-buffer could hold any number of
> markers pointing into the original buffer.

Indeed.

> E.g., info.el itself maintains a per-buffer marker in
> Info-tag-table-marker; evaluate it after M-n and see what it
> tells you.

And for that reason, clone-buffer runs `clone-buffer-hook`, which
Info-mode uses to do:

    (defun Info-clone-buffer ()
      (when (bufferp Info-tag-table-buffer)
        (setq Info-tag-table-buffer
              (with-current-buffer Info-tag-table-buffer (clone-buffer))))
      (let ((m Info-tag-table-marker))
        (when (markerp m)
          (setq Info-tag-table-marker
                (if (and (marker-position m) (bufferp Info-tag-table-buffer))
                    (with-current-buffer Info-tag-table-buffer
                      (copy-marker (marker-position m)))
                  (make-marker))))))

which I believe DTRT.

> For mark-ring, I think it's easier to just reset it to nil in the new
> clone (it's arguably even more correct, since this is a fresh buffer),

I didn't think about it when I saw Charles's patch, but yes resetting it
to nil would make sense.

> but in general this is a ticking bomb, unless I'm missing something.
> If I'm right, the only solution is to walk all the markers that point
> to the parent buffer and clone them to point to the cloned buffer
> (this has to be done in C).

This can't be done in C because after creating those new markers, where
would we store them?  E.g. cloning all the markers that are in
`mark-ring` would just create new markers but it would fail to create
a new list holding those markers, stored in the new buffer-local value
of `mark-ring` (walking the markers doesn't tell us that they're
referred to from `mark-ring`).

Hence clone-buffer-hook, which doesn't solve the problem in itself, but
makes it possible to fix it manually where needed.


        Stefan