Re: UI inconveniences with M-.

[Dmitry Gutov]

On 04/30/2015 04:42 PM, Eli Zaretskii wrote:

> While etags shows a very long list of potential matches, it produces
> them in the order of importance; I don't remember ever having to
> examine more than the first few hits (and thus wasn't even aware of of
> the sheer length of the full list).  So with the old UI the
> ridiculously long list of candidates was never in my face.  The new
> UI, by contrast, makes this acutely evident by showing me the full
> list, and on top of that it destroys the order produced by the
> back-end, which would allow me to look only at the few first hits.

That is unfortunate indeed. Browsing the xref-find-apropos results 
segregated by the match distance might prove useful.

> If I wanted to talk about the code, I'd say something like
> "this-and-that function does wrong things because of so-and-so".

I think both I and Stefan very much wanted you to look at the actual 
code here. It's much easier to make demands on functionality than to 
propose a clean and modular design.

> Through my naive-user eyes, filtering 140 hits to provide
> just a few is perfectly within the capabilities of the UI, at least in
> principle.

That is, of course, possible. But then we'll need to define some 
universal language-arnostic metadata that the UI would use to operate.

> It sounds more and more like it could be the fault of the design, and
> specifically of how functionality is divided between the back-end and
> the UI.  Let me elaborate.
>
> <...>
> To me, this means that separating the back-ends from the UI while
> leaving the UI "dumb" is basically unworkable, because such a
> separation does not really separate anything: there will still be a
> very high degree of coherency and cohesion between the two parts.  Or
> maybe there will only be one usable back-end, and the rest will
> bit-rot.

Sorry, all I see here is a lot of conjecture. The current 
implementations took not a lot of code, and they work well enough.

You seem to argue in favor of extracting some common code into the UI, 
but there's not much of it that I can see. Again, it would help if your 
proposals were more technical and lower-level.

> Likewise, people who mainly work with small projects, where the code
> line count is in hundreds or a small number of thousands, might never
> need the less-than-exact matches provided by etags: Grep is good
> enough and fast enough for that.  But you cannot do without etags in a
> larger project.  (You also cannot do without being able to find all
> references to an identifier, which is why I'm using ID Utils for the
> past 15 years, and was disappointed to learn that xref-find-references
> has no back-ends that implemented this kind of search.)

M-x xref-find-references is implemented now, for both backends, using 
Grep or one of the faster tools (semantic/symref makes the choice), and 
the "symbol bounds" matching. Hope you're happier now.

By the way, CEDET has had a similar feature for a while (try `M-x 
semantic-mode', then `C-c , G' on some function, in a C file). Arguably, 
even with a better interface.

Any reason why you haven't been using it?

> That "little detail" all but invalidates most of my use cases.  We
> seem to have very different development experiences, probably due to
> what each one of us does most of the time, but I hope you can see that
> there are valid use cases outside of your personal experience, and
> Emacs should support them if it wants to be a good IDE.

I'm sure we want it to be. However, I've seen no indication that the 
majority of users prefers find-tag over find-function. Maybe some hard 
data would change that.

> And I'm not even sure your ideas of how to solve that "little detail"
> are workable, because of the potentially adverse consequences of
> loading code you don't actually need (or want) to execute.  What if
> the code is buggy, or dangerous, or simply does things you don't want
> to be done in your Emacs session?

That's a valid concern, but you'd have to read that kind of project from 
top to bottom first. Then you can load it and proceed to use the 
navigation functions.

In any case, we should probably return to this example after it occurs 
in our ecosystem at least once.

> I don't know what that means, and don't know enough about JDEE to talk
> about it.  In any case, Java is not a "classic" compiled language, as
> a Jave development environment is generally capable of running the
> code in an interpreter.

There are several ones for C, example: 
http://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computing/184402054

Not that it has any relevance to the xref backend interface.

> But since it was already made the default, it means we must fix this
> ASAP.

-1.

> I don't think completion is the right tool for these searches, because
> the name alone doesn't tell enough.  So if we want to base that on
> name-completion, we are asking the user to type "something TAB" every
> time she needs another candidate.  I don't think this is a very
> convenient UI for this job.

Indeed, xref-find-apropos is better for that.

> See above: you assume that the division of functionality between the
> UI and the back-ends is at the right place.  I'm not so sure.  If I'm
> right, then when more back-ends come, we will see more problems, not
> less.

That's conjecture again.

> Assuming you know what you are looking for, yes.  I described a
> situation that is frequent for me where you generally don't, at least
> not well enough to be satisfied by a single exact match.

I'd like to repeat my suggestion:

- You can bind `M-.' to `xref-find-apropos' in your config.
- We can improve its output somehow.