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

[Helmut Eller <eller.helmut@gmail.com>]

On Tue, Dec 30 2014, Dmitry Gutov wrote:

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

As Dmitry says: that would replace the current buffer and at the same
time create and switch to the *xref* buffer.  I had tried that and it
didn't like it.

>> This is a regression from the old tags
>> feature, where just "M-. RET" will already show the first matching
>> definition.

It's not a regression as M-. is now a different command with a different
UI.  My goal was never to be 100% backward compatible with find-tag but
to make something better.  You lost your key binding for find-tag.  Sorry
about that, but there are only so many good keys.  Of course, you know
how to get the old key binding back.

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

I bet that after 15 minutes of using it, nobody will care what the name
of the *xref* buffer is.  So we can just as well use something short.

[...]
>> By trial and error I found out that I'm expected to move to the
>> candidate I want with cursor movement keys,

Trial and error isn't the worst way to learn things; at least if it
doesn't take too long.  Apparently you didn't even need to read any
documentation, which would indicate that the UI is not so unintuitive
after all.

[...]
>> Moving up an down is slow, probably because it visits files
>> without waiting for RET or some other gesture to select a candidate

For me, opening the file the first time is a bit slow, but after that
moving up and down is instantaneous.

[...]
>> 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:

That's as expected.  There is nothing to select on the first line.

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

I didn't implement that.  It's because of the save-window-excursion in
xref--next-line that Dmitry added.  In my proposal the other window
didn't change when the cursor didn't move.

>> In sum: please make the new feature at least as good as the old one it
>> replaces.

You can't make progress by keeping everything the same.

Helmut