Re: xref-find-matches and stuff

[Eli Zaretskii]

> From: Helmut Eller <address@hidden>
> Cc: Vitalie Spinu <address@hidden>,  address@hidden,  address@hidden
> Date: Sat, 09 May 2015 11:06:45 +0200
> 
> 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 back-end that misses symbols without being told so should 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.

> Ideally we would like to have both high Precision and high Recall,
> but in practice a trade-off is needed.

The trade off is up to the user and/or UI, not up to the back-end.

> 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".

> IMO a bad trade-off compared to the much better Precision of the
> elisp/find-func backend.

This trade-off is the blame of the UI: it didn't instruct etags to be
more selective.

> Also I think that the generic/naive merging of backends as proposed so
> far will (always?) increase Recall but usually decrease Precision.

If the user wants that, it's their (users') funeral; we should honor
that.