[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 08:04:41 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

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

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.


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

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.

reply via email to

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