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

From: Eli Zaretskii <[email-masked]>
Date: Tue, 30 Dec 2014 18:00:24 +0200

> From: Helmut Eller <[email-masked]>
> Cc: Dmitry Gutov <[email-masked]>, [email-masked]
> Date: Tue, 30 Dec 2014 09:19:18 +0100
> 
> >> 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.

But that's what the old M-. did, so it should be at least an option,
IMO.

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

But etc/NEWS says that find-tag is now obsolete.  So I think the
replacement should be at least as good, in terms of usability and
speed.  I didn't ask for 100% backward compatibility, I'm asking for
convenience and speed.  I don't think they are unreasonable requests.

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

I don't see how the length of the buffer's name is important here.
Short names are okay if they explain themselves; this one doesn't.

We periodically have discussions full of flames about discoverability
in Emacs and its steep learning curve.  It is my impression as a user
that the name of this buffer, its specialized keybindings, and lack of
instructions, don't make the curve less steep, to say the least.  I
hope we can do better, as the problems don't seem to be grave or hard
to fix.

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

Turns out I missed '.' and ',', though.  So trial and error are
evidently less efficient than we would want.

> Apparently you didn't even need to read any documentation

What documentation?  These commands are not yet in the manual.

Or maybe you meant this:

  M-. runs the command xref-find-definitions (found in global-map),
  which is an interactive autoloaded Lisp function in `xref.el'.

  It is bound to M-., <menu-bar> <edit> <goto> <xref-find-def>.

  (xref-find-definitions IDENTIFIER)

  Find the definition of the identifier at point.
  With prefix argument, prompt for the identifier.

That's the entire doc string of the command, all of it.  (Btw, it
doesn't even say that if no identifier is found at point, it will
prompt even without an argument.)

I hope now you understand why I needed to "try and err".

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

Then why let me position point there?

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

Once again, no one asked for "the same".  I'm asking for the new
feature to be at least as convenient and fast as the one it replaces.

The two issues that I find annoying about this are: the first
candidate is not displayed until I press a key, and I'm unable to find
functions that the current major mode doesn't know about.  I hope
these can be fixed, they don't seem major to me.

Thanks.