[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefan Monnier
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Mon, 27 Apr 2015 00:30:41 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

>    . I tried the ELisp back-end and found that it somehow affects the
>      UI, so that the UI behaves differently than with the default
>      etags back-end, when the user types something that is "complete,
>      but not unique": when using the etags back-end, Emacs displays a
>      list of candidates in the *xref* buffer, whereas with the
>      elisp-mode back-end it shows the "complete" candidate, doesn't
>      display *xref*, and doesn't insert the other candidates into
>      *xref*.  Is this difference intended?  It's confusing, to say the
>      least.

I don't understand exactly the scenario you're talking about.  Can you
give a recipe?

>      But what are the alternatives, if any?  I could only find
>      something related in ada-mode and in elisp-mode.  This means
>      that, for example, for C/C++ and Java, etags is the only
>      available back-end, and this change is currently just a different
>      UI wrapping the same basic functionality?  Is there any further
>      development planned for the near future?

There should very much be other backends on the way, e.g. using Semantic
(for C/C++), SLIME (for CL), ...

>    . The doc string of xref-find-function mentions several variants of
>      invoking the function, but there doesn't seem to be any way of
>      controlling that when invoking the function interactively, is
>      there?  I think it would be good to be able to lookup only the
>      definitions or only the references of a symbol.

Indeed, the current UI does not offer access to all features of the API.
Improvements welcome,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]