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

[Dmitry Gutov <dgutov@yandex.ru>]

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.
>>
>> Example?
>
> 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.