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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 30 Dec 2014 08:04:41 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: Helmut Eller <eller.helmut@gmail.com>
> 
> On 12/29/2014 10:26 PM, Eli Zaretskii wrote:
> 
>     Why doesn't it put me on "display_line"s line, and display its
>     definition at the same time?  This is a regression from the old tags
>     feature, where just "M-. RET" will already show the first matching
>     definition.
> 
> 
> It's a tradeoff. Otherwise, you'd see two new buffers at once, possibly covering both windows (if you have two).

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.

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

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.

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.

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

> Compared to `find-tag', you see the list of all possible definitions (and only if there are several). What are the odds that the first location is the right one anyway?

With completion? excellent.  Moreover, the old find-tags employed some
logic in its completion, so that matches that are more likely appear
first.  I generally found the results very good, certainly in
languages which require symbols to have unique names on the source
level.

>     Further, this buffer's name, *xref*, has no mnemonic significance, and
>     there are no clues as to what it wants to tell me or what is expected
>     of me.
> 
> 
> 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*"?

>     The candidates are not mouse-sensitive, either, which is
>     un-Emacsy.  It functions like *Completions*, but it ain't one.
> 
> 
> One might argue that using the mouse is also un-Emacsy.

That ship sailed a long time ago.

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

>     By trial and error I found out that I'm expected to move to the
>     candidate I want with cursor movement keys,
> 
> 
> Or with `.' and `,', which are a bit easier to press right after `M-.'.

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

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.

> > Moving up an down is slow, probably because it visits files
> 
>     without waiting for RET or some other gesture to select a candidate
>     (why was that design decision made?).
> 
> If you look at the related thread in emacs-devel, you'll see that it hasn't been discussed at all. Helmut implemented it this way, and apparently everyone that looked at it (the few people that did), liked it. I expect it will have its admirers, since helm-swoop, a package with the same visual effect, is pretty popular.

I described above one use case where I think this reaction to moving
point will not be appreciated by users, since Emacs moves point as
result of scrolling.

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

> > Hitting RET on the first line,
> 
>     the one that shows the file name, results in "No reference at point",
>     which is not really useful.
> 
> 
> Would you prefer to navigate to the first line of that file? That seems unlikely.

My point is that putting me on that line when the buffer pops up makes
little sense, because that line is just a heading.

>     Another peculiarity is that once I press <down> arrow once, I can no
>     longer get back to the first line, the one that shows the source file:
>     pressing <up> on the 2nd line doesn't move point, but it does return
>     the original buffer to the window above *xref*.  Weird.
> 
> A bit weird, yes. Would you prefer not to "return the original buffer"?

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.

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

> Since when do we have a working completion interface that uses a GUI dialog ("open file" doesn't count)? If it's as fully functional, then sure, we should use that.

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?

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

>     In sum: please make the new feature at least as good as the old one it
>     replaces.
> 
> I'd say it's already much better, but maybe not in all respects. And the latter would be a tough goal.

I don't think we can deprecate/obsolete find-tag unless xref is at
least as good.  And I don't see any reasons why it couldn't become as
good or better, the issues I mentioned seem to be minor and easy to
fix.

>     And when introducing new exhibits, like the *xref* window,
>     please make them self-explanatory and convenient/natural to use for
>     newbies and veterans alike.
> 
> That's a great ideal to strive for, but a poor criterion for acceptance (convenient and natural are subjective notions). 

I agree it's subjective, but I think I provided explanations for my
views.

> When the veterans don't participate in the discussion about a new feature, I suspect having follow-up discussions in bug reports would often be inevitable.

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.  Perhaps a
prominent announcement of the intent to replace Tags, with explicit
reference to that word in the Subject, would have done a better job of
attracting people who might have had something to say about this.

Thanks.