emacs-devel
[Top][All Lists]
Advanced

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

Re: xref-find-matches and stuff


From: Eli Zaretskii
Subject: Re: xref-find-matches and stuff
Date: Sat, 09 May 2015 15:20:50 +0300

> From: Helmut Eller <address@hidden>
> Cc: address@hidden
> Date: Sat, 09 May 2015 13:43:24 +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 language specific backend is in a much better position to decide what
> is relevant than the language agnostic UI.

How would the back-end be able to know what the user-level feature
wants?  It can't.

The API for the invocation of the back-end must specify that in terms
that are abstractions of language-specific features.  Any language has
variables and functions, some have classes and macros, etc.  I see no
problems here.

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

A back-end should not decide anything, it should perform the job as
instructed.  Otherwise, it's not a back-end, but a large part of
application-level knowledge.

> Ignoring code that's not loaded into Emacs is a very good
> strategy most of the time and doesn't need to be "fixed".

Then tell the back-end when to ignore it and when not to ignore.  It's
not up to the back-end to decide.

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

Sigh...  I described what that does in terms of user experience.

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

Feel free to actually look at the code which does that.  There, you
will see that this is what we ask etags to do.

Then try your example again, after this small change:

  (setq etags-xref-find-definitions-tag-order
        '(tag-exact-match-p tag-implicit-name-match-p))

Feel free to disagree with yourself now.



reply via email to

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