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

[Dmitry Gutov]

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

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?

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

> 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. But sure, that 
shouldn't be hard to add (and would increase discoverability).

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

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

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.

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

> 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"?

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

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.

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

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

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