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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: dgutov@yandex.ru, 19468@debbugs.gnu.org
> Date: Mon, 27 Apr 2015 13:21:07 -0400
> 
> > I certainly hope that at least the Semantic one materializes soon
> > enough, otherwise it sounds like all this move to xref was for the
> > benefit of unbundled packages,
> 
> IMO one of the main tasks of the maintainers is to provide
> infrastructure that consolidates the features that are duplicated out
> there in many different packages, all mutually slightly incompatible.
> 
> So the usefulness does not directly depend on whether that feature is
> used by bundled or unbundled packages.  Emacs thrives in large part
> thanks to all the unbundled packages out there and we shouldn't treat
> them as second-rate citizens.

We shouldn't treat the Emacs core as second-rate citizen, either.  A
feature as central to code development and Emacs in general as finding
definitions and references of symbols cannot thrive only (or mainly)
outside the core, IMO.

> > and users of Emacs are just punished by having to learn a new UI for
> > no real advantage.
> 
> I like the new UI, FWIW.

Where did you see me say I dislike it?  I'm just saying that learning
a new UI for the sake of a new UI is a waste.  I _am_ prepared to
learn a new UI if it brings new useful functionality with it.

> BTW, w.r.t the use of etags, what do you think of the patch below, which
> lets the elisp-xref functionality fallback on etags for functions/vars
> that aren't currently bound?

What's it supposed to do?

Anyway, I once again think that if we will mostly "fall back on etags"
every time the new back-ends are somehow imperfect, then what exactly
did we gain with this move?  I heard more than once in recent
discussions that the etags back-end is less than perfect, to put it
mildly; after hearing this so much, I wonder how it makes sense to
fall back on it all the time.  If it's not good, let's replace it with
something better, not fall back on it.

> > That said, the usual way in Emacs to provide minor variants of a
> > command is via special values of the prefix argument, like, for
> > example, "C-x C-s" does.
> 
> The different ways to call xref-find-function are to distinguish
> jumping to the definition or to "all uses", and currently few backends
> support those features

Sounds like another feature that was planned, but never implemented.
Once again, why did we switch to xref if so much of its promise is yet
to come?

> I don't think we have a clear idea yet of how they should be
> presented to the user

There's prior art out there in other IDEs, we could start by learning
from them.

> and there are too many variants to collapse them all into C-u.

"C-x C-s" manages to provide no less than 4 variants with C-u, so I
see no problem to use it with this command.  That said, ...

> So they'd probably be provided via different commands instead of all
> being accessed via M-.

... I won't mind this alternative, either, although we don't have too
many keys left to use for those other commands.