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

Previous Next

Package: emacs;

Reported by: Juri Linkov <juri <at> linkov.net>

Date: Fri, 13 Nov 2020 08:33:01 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


Message #63 received at 44611 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Juri Linkov <juri <at> linkov.net>
Cc: João Távora <joaotavora <at> gmail.com>,
 44611 <at> debbugs.gnu.org
Subject: Re: bug#44611: Prefix arg for xref-goto-xref
Date: Sat, 19 Dec 2020 23:41:17 +0200
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'?




This bug report was last modified 4 years and 87 days ago.

Previous Next


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