GNU bug report logs - #28814
26.0.90; When *xref* window is needed, original window-switching intent is lost

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 28814 <at> debbugs.gnu.org
Subject: Re: bug#28814: [BUMP, PATCH] (26.0.90; When *xref* window is needed,
 original window-switching intent is lost )
Date: Wed, 25 Oct 2017 17:49:09 +0300

On 10/25/17 4:29 PM, João Távora wrote:

> It seems you’re talking, in part, of the expectations of users coming
> from more "modern" UI’s, like Sublime’s.

Naturally, I want all kinds of users to be happy with Emacs. And the 
"modern" editors have the right idea in some of their design decisions.

> I can understand that argument,
> but I also argue that not drifting too much from the (twitchy, I’ll
> admit) window popping behavior of Emacs is useful in its own right.

I'm arguing that what in the cases we want to quit the xref buffer right 
after, we actually want some sort of richly-decorated *completion* UI 
where the user picks one destination (or we could call it a selection 
UI; something other editors often use popups for).

And once they pick it, Emacs can pop the destination in some window or 
other to its heart content.

> For example, I’d argue that Emacs users are almost universally used to
> ’C-h f/c/m’ stuff bringing up obtrusive windows that they can quit by
> typing ’q’ and get back to their original configuration (provided, yes,
> that they don’t mess with the window configuration in the
> meantime).

But the window configuration changes that happen while the user selects 
the destination in the xref buffer, can't be undone with 'quit', with 
out without your patches.

> If that UI can be improved, it certainly should. (I have some very old
> ideas about a single window dedicated frame for help windows that could
> be discussed and developed). But whatever is done it should be done to
> Emacs as a whole, to preserve consistency.

If you're talking about window management in general, that seems 
orthogonal to me.

> In the meantime, my xref patches try to stay close to the current
> paradigm.  Additionally, they should benefit automatically from any
> future improvements.

Let's wait for Eli's opinion.

>> But 'a' (correct me if I'm wrong) normally replaces a buffer in the
>> *current* window. And kill the previous buffer.
> 
> I can’t correct you because I had no idea of that convention either. I
> just mentioned ’a’ because I read it somewhere in the discussion.

The binding I have in mind is in dired-mode. There, 'a' replaces the 
current buffer with another.

I don't recall any other 'a' bindings, off the top of my head.

> I’ll
> be fine with any key that means "yes I’ve really decided I want to go
> here now take me there and bury this buffer".  As a last resort, an
> unbound command that I can remap RET to, or a decent interface that
> allows me to write such a command.

I'd also be fine with any of those. :) 2 or 3 sound best, though.

>>> Of course my priority goes towards RET doing xref-quit-and-goto-xref and
>>> something else doing xref-goto-xref. If that default isn’t changed, I’ll
>>> probably to that remap in my init file..
>>
>> So you'd always use "something else" to navigate to
>> project-find-regexp search results?
> 
> No, I’d use "n" or "SPC". These work fine as always.

SPC is not bound by default. And you'll probably use 'n' in 
xref-find-definitions output as well.

> When I find the one
> I want to edit, I press "RET". I’m a big boy, I can find the *xref*
> buffer again :-)

Would you prefer similar behavior in *Grep* buffers as well? If you 
still use those.

Previous Next

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