GNU bug report logs - #44611
Prefix arg for xref-goto-xref

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 44611 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#44611: Prefix arg for xref-goto-xref
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 <dgutov <at> yandex.ru> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.