GNU bug report logs - #17893
24.4.50; (error "Marker does not point anywhere")

Previous Next

Full log

Message #64 received at 17893 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17893 <at> debbugs.gnu.org, "Charles A. Roelli" <charles <at> aurox.ch>
Subject: Re: bug#17893: 24.4.50; (error "Marker does not point anywhere")
Date: Mon, 20 Nov 2017 11:51:45 -0500

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.