Re: UI inconveniences with M-.

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> etags.el also failed miserably in some scenarios which xref/elisp
>> handles acceptably.  E.g. try C-u M-. diff-mode-abrev-table RET.
> I don't see diff-mode-abrev-table in TAGS, so I don't understand what
> you want to demonstrate with that.

Exactly that: etags fails to find the definition site of
diff-mode-abrev-table, whereas xref/elisp does find it.

>> As I said, going back to etags.el is not an option.
> It's definitely an option for this curmudgeon, if the new-and-improved
> solution will not become better.

Of course you can.  I'm only talking about the default.

> What do you tell users whose use case is similar to mine?  "Use
> xref-etags-mode"?  Then why did we switch away of etags.el, if we
> still need to use its core machinery?

We do want to support the etags backend for a long time to come.
The old etags.el UI on the other hand, will most likely be phased out
(or rewritten on top of the new API no it can also be used with other
backends).

> I don't want 2 different commands.  I know about etags-apropos as
> well, but never used it, because I never needed to.  Forcing me to use
> 2 different commands where I could use one is an annoyance.

It's a tradeoff.  The upside is that M-. gets you there much quicker
then M-. RET C-u M-. C-u M-., and that xref-apropos gives you a quick
overview of all the matches, compared to cycling through C-u M-. where
you never know how long the cycle will be nor where it will take you next.

> Anyway, I'm out of this discussion.  Good luck selling your ideas and
> use cases to others.  I'm not sold.  And I don't enjoy having to read
> uncalled-for profanities in response to legitimate questions and
> issues.

I've found you didn't have many constructive suggestions and spent too
much time complaining about how the new system doesn't work like the
old one.
That's frustrating.


        Stefan