> If the back-end conceals potentially useful information, it should be
> fixed not to do so.
"Conceal" makes it sound like it's ill-intentioned, done on purpose
or something.
For (defadvice find-tag ...), the problem is in advice.el.
Patches welcome, but since this library is on the way out AFAIC, I'd
recommend you don't bother spending time on it.
> That you personally find that information always redundant does not
> mean it's true for everyone else. There's more than one use case for
> these queries, see below.
We can't know what the user wants and handle all conceivable scenarios.
Maybe the user really wants to jump to this chunk of code somewhere that
does (fset foo bar) and hence ends up overriding the "official"
definition of the function. But unless you can solve the halting
problem and read the user's mind at the same time, we'll have to settle
for something imperfect.
etags.el also failed miserably in some scenarios which xref/elisp
handles acceptably. E.g. try C-u M-. diff-mode-abrev-table RET.
> That's your misunderstanding. I described my user experience from
> using this new feature; I never said where the fixes should be made,
Well, you kept insisting that it's not a question of backend, so maybe
you didn't say where the fixes should go, but you did say where the blame
should go.
> Says you. 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.
The 140 hits are just a list of locations. The UI has no fucking clue
whether these are function definitions or what, nor does it know in
which language the file is written.
> IOW, the separation of functionality is in the wrong place. To be
> useful, some of the "smarts" need to be on the UI side, where user
> control can be best implemented, and where user intent is known much
> better.
The UI has to be agnostic. So the smarts can't be in the UI. The API
can be extended to provide the extra smarts that the UI might need, of
course. E.g. we could add to the API a function that sorts/groups the
entries, so the etags backend can sort them based on "likelyhood" rather
than group them by file.
> I very much hope Emacs will continue to be able to support the kind of
> activities I described above, which AFAIK are very important part of a
> software developer's job throughout the industry.
You fail to understand why complaint about etags.el. I'm not
complaining about `etags', but about the etags.el front-end, which is in
need of improvement to handle the case where the user is navigating
several completely different projects and doesn't want one to pollute
the other one.
>> I've tried several times to make real use of it, but always found it
>> completely unpalatable. What with having to build those damn TAGS
>> files, remember to refresh them, remember where they are, constantly
>> tell Emacs again where they are, deal with its inability to find the
>> right spot and having to repeat the "C-u M-." finger gymnastics
>> umpteen times.
> Those are exaggerations.
Partly, yes. I'm just venting my frustration with the tool, and
pointing out that if xref/elisp (and xref/etags) has some downsides,
etags.el had its own set of downsides. And some of those shouldn't be
that hard to fix (tho they would probably be a lot easier if we didn't
have to worry about annoying some old-time users because they'd have to
slightly change their habits).
> Building TAGS is almost instant, even in Emacs,
The problem is not computer-time but human-time.
> you need only refresh them very seldom, and Emacs offers the
> place from which to load them so you don't need to remember.
If Emacs knows where the file is, the user shouldn't need to be queried.
> But this, again, is immaterial for this discussion. I hope you will
> agree that, whatever issues we have with etags, replacing it with
> something that lacks important functionality is not a good idea.
As I said, going back to etags.el is not an option.
> That "little detail" all but invalidates most of my use cases.
Then don't use that backend. E.g. use xref-etags-mode.
>> C-u M-. also lets you do loose matching, via completion, if your memory
>> is failing you.
> I don't think completion is the right tool for these searches, because
> the name alone doesn't tell enough.
Don't pretend you don't know about xref-apropos.
> See above: you assume that the division of functionality between the
> UI and the back-ends is at the right place.
No I don't. I don't assume the API is fixed either. All I assume is
that the UI can't know about the programming language or about the
quality of any given answer, or any such thing.
>> But to me, "find-tag" and "find-tag-tag" are not two different
>> matches to my request. They're just two completely unrelated
>> things: either I'm looking for one or I'm looking for the other.
> 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.
And that's not what M-. for. For that we have xref-apropos.
> And therein lies its weakness. I actually don't understand how this
> kind of assumption could be allowed to exist, when the _default_
Because this assumption is known to be obtainable, with help from the
toolchain (the compiler will generally know with 100% certainty the few
possible definitions matching a particular use).
Stefan