Re: UI inconveniences with M-.

[Stefan Monnier]

>> In the "M-. find-tag" example, the UI does let you see all matches.
>> It's just that there's only one.
> We already agreed that there were at least 2.

No, we agreed that in some ideal world there could be two.  But the
backend as it is written now, only returns one for that case.

> More importantly, the issue that I was raising in that example is that
> the results change too radically when the back-end is changed.  IMO,
> it makes no sense to display more than 140 candidates with one
> back-end, and only one with another, in the default configuration.

I agree the 140 "matches" are absurd and need to be fixed.
The single match of the other backend is what I want, OTOH.

> Once again, I never said that a single match should be popped in a
> buffer.  I said that I don't expect to see a single match in this
> case, because that's a lie!

No, it's not a lie and I would even argue it's neither a bug nor
a misfeature.  You expect etags-style information from the xref/elisp
backend, but that's simply not the info it tries to give you.

> compelled to respond.  But my perspective in filing the bug report was
> the perspective of a user looking at the results through the UI, and
> trying to use that UI to manipulate the results.

See, you use the term "UI" in a completely different way.  When I say
"UI" in this discussion, I'm talking about the code which takes the info
from the backend and makes it available to the user.

So the fact that one backend returns 1 item and the other returns 140 of
them is completely outside of the control of the UI.
Maybe the resulting end-user experience sucks, but that's not the fault
of the UI but the fault of the backends.

The reason why I use the term UI in this way is because the API is
designed so that you can have several UIs using the same API (just like
you can have several backends).

>> >> Arguably, the find-tag advice in org-ctags.el could be offered as well,
>> >> if org-ctags.el happens to be loaded
>> > ??? Why should the xref matches depend on what is and isn't loaded?
>> Because that's how xref/elisp works.
> If so, then it's much less useful than I thought.

And to me, it makes it more useful.

> I don't see how such a back-end can even be a candidate for becoming
> the default.

And I don't see how we've live with the etags.el UI for so many years.
I've tried several times to make real use of it, but always found it
completely unpalatable.  What with having to build those damn TAGS
files, remember to refresh them, remember where they are, constantly
tell Emacs again where they are, deal with its inability to find the
right spot and having to repeat the "C-u M-." finger gymnastics
umpteen times.

xref/elisp may not let you jump to those functions/vars that aren't yet
loaded, but beside this little detail, it *just works* without any
extra setup, nothing.

> Apropos pops up a new window, and 'q' quits it, so that problem has a
> solution there as well.

But the apropos is just an intermediate, what I want to see is the
corresponding source, and by the time I'm there, I can't so easily use
`q' to go back.

>> Not at all.  Many (most?) packages which offer a functionality along the
>> lines of "M-. to jump to the definition" use an implementation technique
>> which is fundamentally similar/equivalent (obviously, they don't query
>> a running Emacs, but they query a running REPL).
> Think about compiled languages.

AFAIK, JDEE used the same approach for Java.

[ There's no such thing as "a compiled language".  I guess you mean
  "think of the case where your language's implementation uses good old
  static compilation scheme".  ]

I don't claim that all backends will have to work this way.  Just that
it's a common implementation technique.

> If those many use mainly ELisp or REPL-type language interpreters, I
> can understand why.  But Emacs is not limited to those.

And neither is the xref API.

> Until that problem is solved in core, I don't see how a back-end that
> requires to load a package can be the default.

Agreed.

>> > That's one way of looking at it.  Another is to say that etags gave
>> > you more information and thus allowed to find more loose matches,
>> > which is helpful when your memory is failing you.
>> M-. jumps to the definition of the "thing under point".  There's no
>> memory involved.
> I was talking about "C-u M-."

C-u M-. also lets you do loose matching, via completion, if your memory
is failing you.

>> If you're not sure what you're looking for, then you're expected to use
>> the completion facilities in C-u M-.
> Completion shows only part of the matches, we've been through that
> already.  It doesn't by default show substring matches.

For one, you can make substring the default by tweaking the completion
styles configuration, if you so prefer.  The default completion is
partial-completion, which is actually "more powerful" than substring
matching: e.g. "*find-tag" would not only match "find-tag-tag" and
"my-own-find-tag" but also "my-finder-tag".

But there's nothing magical about substring matching anyway.  etags.el
used it because it was easy to implement, not because it is the best
thing there is.  Of course, it's good, but partial-completion is also
good, and many other options are also good.

> I didn't say "unfiltered".  I asked for user control of the amount of
> filtering or of looseness of the matches.  In etags.el terms, think
> about giving the user control on what goes into find-tag-tag-order.

That's OK, then.  It seems that etags is simply unable to give
sufficiently reliable data to filter it effectively, so we're stuck with
heuristics and user-knobs to choose where they're rather get bitten.

> Once again, I question the decision to switch to this UI, when we

I know, but that's just a waste of time.  The backends won't come before
this system is standard and common place (and they'll take their time,
because in the mean time they can keep using their ad-hoc UI which also
works on older Emacsen).

> But having 2 orders of magnitude difference between the results
> _by_default_ is absolutely insane!

Agreed, because the etags backend sucks right now.

> It's not!!  There are partial matches shown by completion -- they are
> the next candidates.

Again, you choose to look at it this way because you're used to the way
etags.el worked.  But to me, "find-tag" and "find-tag-tag" are not two
different matches to my request.  They're just two completely unrelated
things: either I'm looking for one or I'm looking for the other.

The design of xref is based on the hope that the backend can return
a very small list of candidates, ideally of length 1.  That's not always
the case, but for most potential backends (other than those based on
heuristic techniques like regexp-matching) it's pretty close.

>> >   . if the criteria for filtering of the matches are very different
>> >     between the possible back-ends, there should be some agreed-upon
>> >     uniform default that returns roughly the same number of matches
>> >     with all back-ends, and the rest should be controlled by user
>> >     options
>> I don't see what that could concretely look like.
> User options to control how loose the matches are, and the default
> level of looseness that yields similar results.

Feel free to implement another UI on top of this API which provides this
functionality.  I sure will stay away from it, because I have no use for
something which wastes my time showing me unrelated functions whose name
just happen to contain the name of my function as a substring.

On the contrary, I want a tool that's precise, and gets me directly to
the only corresponding definition (in the 99% of the cases where
there's indeed only one) with a single key-press and no questions asked.


        Stefan