[Top][All Lists]

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

Re: UI inconveniences with M-.

From: Dmitry Gutov
Subject: Re: UI inconveniences with M-.
Date: Sat, 2 May 2015 00:11:28 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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

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

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


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

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.

reply via email to

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