Subject: bug#38797: 27.0.50; Feature request: provide the opposite of xref-pop-marker-stack

From: Mattias Engdegård <[email-masked]>
Date: Sun, 24 Oct 2021 15:24:31 +0200

24 okt. 2021 kl. 03.40 skrev Dmitry Gutov <[email-masked]>:

> - The removal of
> 
>  (defvaralias 'find-tag-marker-ring 'xref--marker-ring)
> 
> and the subsequent initialization of the aliased variable to a new ring will likely break any real code code which is still depending on that variable. Because now it is nil by default, and not a ring. Not sure what's the best solution, perhaps it's just time to remove it.

Right; I've resurrected find-tag-marker-ring as a zombie variable. Code manipulating it will have no effect but at least won't crash, which is probably a good trade-off.

>  (make-obsolete-variable 'xref-marker-ring-length nil "29.1")
> 
> is similarly pointless because the variable definition has been deleted. Declaring it obsolete does not help the fact that it is unbound now.

Correct -- resurrected as a zombie variable here too.

> * xref-go-back and xref-go-forward?

Good suggestions and now used. (I've still not added xref-go-back as an alias but that should probably be done.)

> - The slots in the docstring of xref--history (should we call it xref--location-history?) could be called (BACK-STACK . FORWARD-STACK).

Yes, done.

> - xref-set-marker-ring-length's fate is changed accordingly to what we choose to do with xref-marker-ring-length.

We could make it set the pointless xref-marker-ring-length but I didn't bother. I doubt anyone is using that function.

> - The FIXME about proposed xref--back-history-empty-p doesn't make much sense if the introduced function name is going to be private

Sorry, that wasn't the intention. I've added xref-back-history-empty-p for use in the new menu entry.
(I'll let someone else add it to the context menu because that seemed much more complicated.)

Revised patch attached.