From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: xref-find-matches and stuff Date: Sat, 09 May 2015 13:34:05 +0300 Message-ID: <831tiqox9e.fsf@gnu.org> References: <5546DD4A.2080709@yandex.ru> <87r3qvnld1.fsf@gmail.com> <5548E08A.4090305@yandex.ru> <87mw1jndul.fsf@gmail.com> <554964CE.3040809@yandex.ru> <87oalxn756.fsf@gmail.com> <554AAD41.6060506@yandex.ru> <87vbg4lgn6.fsf@gmail.com> <554CB069.8090002@yandex.ru> <87sib7j9yf.fsf@gmail.com> <554CE8B2.7080408@yandex.ru> <87fv76kj0s.fsf@gmail.com> <83fv76p6ts.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1431167655 11434 80.91.229.3 (9 May 2015 10:34:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 May 2015 10:34:15 +0000 (UTC) Cc: spinuvit@gmail.com, emacs-devel@gnu.org, dgutov@yandex.ru To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 09 12:34:08 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yr25A-0006pe-DN for ged-emacs-devel@m.gmane.org; Sat, 09 May 2015 12:34:08 +0200 Original-Received: from localhost ([::1]:58846 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yr259-0001Az-MM for ged-emacs-devel@m.gmane.org; Sat, 09 May 2015 06:34:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yr24x-0001Aq-3j for emacs-devel@gnu.org; Sat, 09 May 2015 06:33:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yr24t-0004yq-Tq for emacs-devel@gnu.org; Sat, 09 May 2015 06:33:55 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:53604) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yr24t-0004yh-LB for emacs-devel@gnu.org; Sat, 09 May 2015 06:33:51 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NO200I00VU4W600@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 09 May 2015 13:33:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NO200ILBW0DMTB0@a-mtaout23.012.net.il>; Sat, 09 May 2015 13:33:50 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186355 Archived-At: > From: Helmut Eller > Cc: Vitalie Spinu , dgutov@yandex.ru, emacs-devel@gnu.org > 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.