Subject: bug#44611: Prefix arg for xref-goto-xref

From: Dmitry Gutov <[email-masked]>
Date: Mon, 28 Dec 2020 02:36:03 +0200

On 25.12.2020 17:42, Eli Zaretskii wrote:
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>> Date: Fri, 25 Dec 2020 16:49:39 +0200
>>
>>>> Changing the latter to use the xref UI (which will have to be renamed
>>>> and become a separate package, BTW) is also likely to encounter much
>>>> bigger resistance than anything we've done in this area before: people
>>>> don't have the same expectations for new commands as they have for
>>>> existing ones, so I'm surprised you asked this (given your overall
>>>> backward compatibility stance, much stronger than mine).
>>>
>>> An optional feature cannot hurt, even if and when it becomes the
>>> default.  Thus, there's no need for me to object to such long-term
>>> plans, if they are announced and proceed at a controlled pace
>>> (including the decision when it becomes the default).
>>
>> This endeavor might need more of an encouragement than "I don't object".
> 
> I didn't have encouragement in mind.  I'm asking if this is the plan,
> or some kind of desire.  If it is, then I can understand that.  If
> there's no such plan, then I don't think I understand why we need to
> make Xref behave similarly and have the same key bindings.

I think I explained that? "Some kind of desire", yes, there is.

In particular, there is movement in splitting the "show xrefs" action 
into two different behaviors: one for definitions (when we expect to 
almost always have very few hits, and usually just one), another for 
anything else like references, "apropos", or grep hits (see the commit 
8c38345629 I just made for some better understanding).

And the latter behavior, governed by xref-show-xrefs-function, might as 
well become even closer to grep-mode.