Re: UI inconveniences with M-.

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Tue, 28 Apr 2015 22:41:27 -0400
> 
> >> > Emacs 24 also had "C-u M-." to go to the next one.  This one doesn't;
> >> > moreover, if you try "C-u M-.", you get prompted for the symbol again,
> >> > and if you type the same one, you get nowhere.  The other matches are
> >> > only available via completion, see below.
> >> Maybe we should write an xref-old-ui-mode.
> > I didn't ask for the old UI.  (If I want it, I can still have it,
> > since the etags.el commands are still available.)  I'm okay with the
> > new UI.  This bug report is about the new UI, and its goal is to make
> > the new UI better.
> 
> Then I don't understand what you mean by the text I quoted.  E.g.:
> 
>    if you try "C-u M-.", you get prompted for the symbol again,
>    and if you type the same one, you get nowhere

If this part of my response gets in the way, just disregard it.
(FWIW, it was an attempt to demonstrate that there's no functionality
in the new UI that is equivalent to "C-u M-." in the old UI.  But it's
not an important point, so feel free to forget about it.)

> > old UI was consistent and complete: it always displayed the first/next
> > match and provided a command to go to the next/previous one.  By
> > contrast, the new UI is inconsistent: with some back-ends it shows the
> > list of matches and allows to navigate it, with others it shows only
> > the first match and does not give any way to get the next match.
> 
> 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.

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.

> If you want, we could make this case popup an *xref* buffer with a
> single entry

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!

> > But that's largely immaterial: this bug report is not about the
> > back-end, it's about the UI.
> 
> I wouldn't be so sure.

I am.  We keep discussing the back-ends because you and Dmitry
consistently shift the discussion in that direction, so I feel
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.

If some changes are needed in the back-ends to make the UI be better,
then so be it.  But it is not a requirement, and I don't feel I know
enough at this stage to even talk intelligently which changes are
needed and in what parts of this puzzle.

> >> 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.  I don't see how
such a back-end can even be a candidate for becoming the default.

> > That would make xref exactly equivalent to "M-x apropos", which means
> > this mode of operation would make xref entirely redundant.
> 
> To you, maybe.  Personally, I find it's *much* quicker to use M-. than
> to use C-h f RET <go-to-the-link> RET

So adding the default guessing depending on what's at point is all
that you need?

> and it has the added benefit that M-, brings me right back if I need
> to.

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

> > To say nothing of the fact that this doesn't scale to any language
> > except ELisp.
> 
> 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.

> > We could offer this mode as an optional feature, but it certainly
> > shouldn't be the default.
> 
> Many users here disagree.

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

> > (One of my worst annoyances is to type a C-h command and be presented
> > with "[No match]", because some package is not loaded or some function
> > is not available in the Emacs configuration I happen to be using.)
> 
> Yes, that's a long standing problem, indeed.  I have a local hack which
> tries to add to loaddefs.el a concise description of where definitions
> might be found (basically, for each file, list the few prefixes used in
> that file), so that "C-h f" can load those packages when needed.
> It's "proof of concept" and it has occasionally rendered my Emacs
> session unusable (e.g. because it ended up deciding to try and load,
> say, w32-fns.el to see if it might contain the definition).  I think
> I've now solved most of those problems in the w32-* files, but the
> underlying risk is still there.

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.

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

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

> > Bonus points for making the filtering optional, since some people
> > might like that, and in some situations even you might need it.
> 
> I disagree.

Then you won't get bonus points from me.

> The filtering is needed by the design of the xref API.
> If you want to see the "unfiltered" data, then use M-x xref-find-apropos.

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.

> > Saying that the back-end returns a confusingly large amount of bogus
> > matches, and then switching to a UI that assumes much smarter
> > back-ends (which don't really exist) makes very little sense to me.
> 
> The smarter backends already exist

Where are they?

> in so far as there is already code out there which provides the
> needed functionality.  It just doesn't use the xref API yet, because
> it was written before xref.el.

Ah, so they don't really exist.

Once again, I question the decision to switch to this UI, when we
clearly didn't yet get our act together and are not really prepared to
use it.  The _potential_ to use it exists, but it is currently not
usable.  We should have waited until it was, IMO.

> >   . the UI should depend much less on the back-end, ideally not at all
> 
> You keep repeating this, but that is absolutely meaningless to me (kind
> of like "it doesn't work" in bug reports):
> - This consistency was trivially obtained with the old etags.el code
>   since it had one 1 backend.
> - What the fuck should the new UI do if one backend returns 1 match and
>   another returns a hundred (as in your "find-tag" example)?

It depends on which one is closer to the correct result, obviously.
If 100 is closer, fix or rewrite (or throw away) the back-end that
returns only 1; if 1 is closer, filter the 100 results to return less
than 10.

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

> >   . there should be a way to go to the next/previous match if the
> >     *xref* buffer is not displayed (or not created in the first
> >     place); if this happens because there's only one match, we should
> >     say so explicitly
> 
> The only case where the *xref* is not displayed is when there's only
> 1 match returned by the backend.  So "go to the next/previous match" is
> again meaningless.

It's not!!  There are partial matches shown by completion -- they are
the next candidates.  If we are not sure the user will want them, we
can ask for confirmation, like we do, for example, in Info's search
that fails to find a match and needs to cross the node boundary.

> >     and should display an indication of the fact that there's only one
> >     match
> 
> The current code "displays" this indication by jumping to the sole match
> instead of jumping to the *xref* buffer.  I think it's clear enough.

We do show similar indications in other cases.  Again, Info's 'i'
comes to mind.

More generally, a UI that does nothing and expects the user to
understand what it means is IMO a bad UI.  At the very least, it
leaves the user wondering whether she hit a bug.

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