Re: xref-find-matches and stuff

[Helmut Eller]

On Sat, May 09 2015, Eli Zaretskii wrote:

>> > Back-ends that mis symbols make no sense, IMO.  They should be fixed
>> > not to miss them.
>> 
>> There are many situations where it's desirable to show fewer than more
>> symbols; irrelevant symbols should be filtered out.  In other words:
>> most people prefer high Precision[*] over high Recall[*].
> Yes, but it's UI's task to tell the back-end which of these to prefer.

A language specific backend is in a much better position to decide what
is relevant than the language agnostic UI.

> A back-end that misses symbols without being told so should be fixed.

There may be many good reasons why a backend may decide to "miss"
symbols.  Ignoring code that's not loaded into Emacs is a very good
strategy most of the time and doesn't need to be "fixed".

> It's possible that preferring precision over recall should be the
> default, but that's not to mean the back-end cannot honor the opposite
> preference when told so.
>
> It also makes no sense to have back-ends with different defaults in
> this respect; that will produce the same confusing user experience as
> I reported.

I see no reason why different backends shouldn't have different
precision/recall trade-offs.

[...]
>> E.g. the etags backend has relatively high Recall but very low
>> Precision.
>
> I thought I already debunked this fallacy.  The etags back-end
> provides a very fine-grained control over its preferences, it's just
> that we didn't use that feature, and instead always told it to return
> as many symbols as it could.  It's small wonder you regard the results
> as "very low-precision".

Let's use the src/TAGS file and then do C-u M-. Lisp_Object RET in
src/alloc.c.  That returns 1000 results.  Only the 2 typedefs in lisp.h
are relevant; everything else is irrelevant.

Recall: 2/2 = 100%
Precision: 2/1000 = 0.2%

Yes indeed, I consider 0.2% as "very low-precision".
Feel free to disagree.

Helmut