[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19468: 25.0.50; UI inconveniences with M-.

From: Dmitry Gutov
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Tue, 30 Dec 2014 22:26:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

On 12/30/2014 05:41 PM, Eli Zaretskii wrote:

Sorry, I don't follow.  I started that from a single window, and
M-. already did split it into 2, and displayed the candidates in the
lower one.  So I already see 2 buffers, and showing the first
candidate in the upper window doesn't do anything I won't expect --
after all, I did ask to see something different from what I was
already seeing.

Changing buffer in two windows at once, like Helmut said, is a more radical change, more likely to confuse the user.

And you lose more context. In the example of ELisp, you could instead glance at the original buffer, see that you've jumped from a function call (so you need a function), and then simply choose the `defun' among the options, without even looking at its buffer.

And it seems inconsistent with your further complaint that movement visits 
files automatically (if it shouldn't, it shouldn't start with displaying the 
buffer at point either).

I see no inconsistency: we could display the first candidate
automatically, but not switch to others without the user's say-so.

Inconsistency would be this: you either automatically display the buffer of the candidate at point or not. You're asking to do it differently in quite similar contexts.

Imagine a situation where the list of possible candidates is very
long, longer than what the window shows.  Then the user might wish to
scroll the list of candidates before she makes up her mind about the
one she wants to see.  But moving point visits the candidates, which
is not what the user asked for in this use case.

I would use C-s for that, or indeed C-v/M-v.

Moreover, I see that scrolling the window by C-v/PageDn does _not_
visit the tags at point, while scrolling by up- and down- arrow key
does.  Looks like another confusing inconsistency.

This would be quite easy to solve, if displaying the tag at point after any movement command is indeed what we want to do.

So I suggest that the automatic visiting will be at least
customizable, if not switched off by default.

Here's a possible compromise: only do that automatically for `.' and `,', as well as provide a manual command (say, bound to C-o).

Speaking of the latter, do you see the value in undoing the window configuration change before the next command? We could expand this behavior to other `-display-' commands with the same binding.

Would you like it to be called the same as the current command? 
*xref-find-definitions-other-window*, *xref-find-apropos*, etc?

How about "*find-function-candidates*" or even "*Completions*"?

`find-function-candidates' doesn't match the command name, nor would it be the same for different commands in the xref package. Inconvenient, from the implementation's standpoint.

*Completions* is bad, because we're not completing text input.

One might argue that using the mouse is also un-Emacsy.

That ship sailed a long time ago.

Guess so.

But sure, that shouldn't be hard to add (and would increase discoverability).

More importantly, it will tell the user what she needs to do, even if
she doesn't use the mouse, because mouse-sensitive portions of Emacs
display generally behave very similarly.

If she doesn't use the mouse, how will she know the mouse-sensitive portions?

Or with `.' and `,', which are a bit easier to press right after `M-.'.

It would be nice to have some instructions to this effect.

I don't think having the instructions inside the buffer would be good. Unlike `report-emacs-bug', it can be used very frequently, and seeing the same simple instructions you already know is annoying.

Once again, this is not a UI that is used in other places in Emacs, it
is very different.  So you shouldn't assume that its keybindings are
known by users, especially keybindings such as '.' and ',' that are
not widely used in other programs, and therefore must be learned anew.

Should we expand it to other places in Emacs? Suggestions welcome.

This can be made configurable, though. For instance, `C-o' could be that "other 
gesture". Would you prefer the window configuration restored before point moves to a 
different line, or should the new buffer keep being displayed? The latter presents a 
challenge if we want `q' in the xref buffer to restore the original window configuration 
before xref-find-definitions was invoked, as long as the user hadn't made any manual 
changes thereafter.

Why is it a challenge?  Typing 'q' and 'C-o' can invoke different
functions, can't it?  I'm probably missing something.

The challenge is to preserve the window configuration, albeit only when it makes sense.

No, I prefer that the lines that show file names be not reachable at
all.  They are just clutter, as far as moving point is concerned.  Let
point jump over them.

If the point is at the first reference already, and we've configured xref not to display its buffer automatically, the user will have to reach for `C-o' instead of `.', to have it displayed.

     Finally, invoking the same command from the menu bar ought to present
     a dialog box with the candidates, according to the general rule: if a
     command was invoked by a mouse gesture, selection of candidates is via
     a GUI dialog, not a special-purpose buffer.  But that doesn't happen.


Click File->Quit when you have unsaved edits.

Apparently, this is easier to implement using the native dialogs. How would you create a replacement for the *xref* buffer, without losing the grouping or ./, functionality?

But this is not completion, this is a list of completion results.
Completion happens _before_ the *xref* buffer is popped up.  Or am I
missing something?

I've just misunderstood. "Selection of candidates" makes me think of completion.

As a counterpoint, Buffers->Select Named Buffer... uses the minibuffer.

That _is_ completion.  I'm not talking about prompting the user for a
symbol, I'm talking about _displaying_ the matching symbols once the
user has typed her input.

Well, how about Buffers->List All Buffers, then?

I'm sorry I didn't participate.  The reason is that I never understood
this is meant as a replacement for find-tag etc., until you asked
whether to remove them from the menu bar.  The discussion was long
enough and focused on technicalities enough to turn me off.

The intention to replace find-tag came naturally later. Either way, maybe it's good that you didn't get into technicalities then, and evaluate this now purely on the basis of behavior.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]