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

From: João Távora <[email-masked]>
Date: Sat, 19 Dec 2020 22:36:12 +0000

I'm fine with anything new as long as backward compatible.
Both ideas or none of them seem fine at this point. Thanks.

On Sat, Dec 19, 2020 at 9:41 PM Dmitry Gutov <[email-masked]> wrote:
>
> Hi Juri,
>
> On 19.12.2020 22:38, Juri Linkov wrote:
> >>> I'd expect TAB rather to iterate over multiple matches,
> >>> i.e. like TAB in browsers go to the next match.  Even in the *Completions*
> >>> buffer TAB moves to the next completion.  And in icomplete-mode
> >>> the closest analogy to picking one result is 'C-j'
> >>> (icomplete-force-complete-and-exit).
> >>
> >> If people like it, I'm totally fine with changing the binding to 'C-j'.
> >
> > I'm very sorry for beating this horse again, but after trying to use xref
> > as a replacement of grep, typing 'C-x p g' pops up a grep-like buffer
> > and due to habit of typing the same keys that are supported by grep-mode
> > where among them is TAB bound to compilation-next-error to browse the
> > results forward, but instead of going to the next match, it does the
> > worst thing imaginable - kills the output buffer.
> >
> > Therefore, I propose this patch that binds TAB and S-TAB to command
> > that behave like compilation-next-error and compilation-previous-error:
>
> Sure, why not.
>
> What about that 'C-j' binding, though? Or are you (and Joao?) satisfied
> with 'C-u RET'?

-- 
João Távora