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

[Mattias Engdegård]

24 okt. 2021 kl. 03.40 skrev Dmitry Gutov <dgutov@yandex.ru>:

> - 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.

0001-Add-xref-forward-history-bug-38797.patch
Description: Binary data