[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master fe939b3 1/2: Fix reference to `tags-loop-continue' in doc str

From: Robert Pluim
Subject: Re: master fe939b3 1/2: Fix reference to `tags-loop-continue' in doc string
Date: Sun, 04 Aug 2019 14:03:24 +0200

>>>>> On Fri, 02 Aug 2019 20:27:22 +0200, Lars Ingebrigtsen <address@hidden> 
>>>>> said:

    Lars> Robert Pluim <address@hidden> writes:
    >> Ah, you mean like this? I hope I have the eval-when-compile stuff
    >> right. And if you do 'dired-do-search' followed by
    >> 'xref-find-definitions' it would be easy to confuse yourself.
    >> We could find a new binding for fileloop-continue, which also breaks
    >> backwards compatibility, but then at least thereʼs a default binding.

    Lars> [...]

    >> +(eval-when-compile (declare-function fileloop-continue "fileloop" ()))

    Lars> I don't think this is necessary -- you can just have the
    Lars> `declare-function' without any `eval-when-compile'.  But you should
    Lars> probably include the arg list?

I did :-)


    (defun fileloop-continue ()

    >> +    (if (ring-empty-p ring)
    >> +        ;; Just in case we were in a fileloop sequence
    >> +        (fileloop-continue)

    Lars> Yes, that's what I wondered would work.  Are there any drawbacks to
    Lars> doing something like this?  Perhaps the interface becomes a bit...
    Lars> unpredictable?

Itʼs perfectly deterministic, just potentially confusing :-)

It begs the question why xrefs replaced a 'do the next thing' type
binding with a 'go back' type binding in the first place. Iʼm tempted
to say that xref-pop-marker-stack should use a different binding, and
M-, should be fileloop-continue, but the xref one has existed for 5
years now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]