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

Previous Next

Full log

Message #70 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 <at> aurox.ch
Subject: Re: bug#17893: 24.4.50; (error "Marker does not point anywhere")
Date: Mon, 20 Nov 2017 13:59:12 -0500

>> > 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:
> If so, it doesn't work well enough:
>  emacs -Q
>  C-u C-h i elisp.info RET
>  M-: Info-tag-table-marker RET
>   => #<marker at 3901363 in *info*>
>  M-n
>  M-: Info-tag-table-marker RET
>   => #<marker in no buffer>

Maybe there's a bug, indeed.  Does the above lead to undesired behavior?
[ It's been a while since I last looked at those things.  ]

> I guess we will have to walk all the local variables and find markers
> in them, like GC does.  Is there any other way?

I don't think it can be done reliably: whether a marker needs to be
cloned or not may depend on what the marker is used for; and some of the
markers that need to be cloned could be stored elsewhere than in
buffer-local vars.

And in order to clone such a marker, we'd need to clone all objects
found on the "spine" between the local var and the marker.  In some
cases such a "clone" is again difficult to do automatically and
reliably, because what needs to be done again will depend on semantic
details to which such a generic code at the C level doesn't have access.

>> Hence clone-buffer-hook, which doesn't solve the problem in itself, but
>> makes it possible to fix it manually where needed.
> I think this kind of problems is impossible to solve from Lisp, as we
> don't expose enough information about markers, and for a good reason.
> For starters, that hook assumes that every mode knows exactly what
> local variables could need special handling, but that's an illusion.

No.  It just assumes that whichever package owns a marker that needs
special treatment should register itself on that hook.  Maybe that's too
much to ask, but it's definitely not "impossible".

> For example, the user could have set all kinds of local variables
> behind the back of Emacs which hold markers.

Then it's his responsibility to add a function to clone-buffer-hook to
handle those (in the unlikely case that she actually cares about
interaction between those vars and clone-buffer, that is).

> As another data point, there are 6 users of clone-buffer in Emacs
> core, and only one of them bothers to set up a clone-buffer-hook.

Do these suffer from problems?  When I introduced clone-buffer
(motivated by Info-mode), I also introduced the Info-clone-buffer hook
function because it was simply indispensable to get it working.
But I remember using it in other cases where such a hook didn't
seem necessary.


        Stefan

Previous Next

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