From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: handling many matches Date: Sat, 2 May 2020 19:13:18 +0300 Message-ID: <14f6ff0f-afcc-5cc2-b8ce-491209c1e739@yandex.ru> References: <119c0543-387d-4fad-b7fe-b4e07a7be4f8@default> <837dxuvohj.fsf@gnu.org> <83wo5usaui.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="69531"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: jonas@bernoul.li, emacs-devel@gnu.org, monnier@iro.umontreal.ca, adam@alphapapa.net, kyle@kyleam.com, drew.adams@oracle.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 18:14:01 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUum9-000Hxr-Em for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 18:14:01 +0200 Original-Received: from localhost ([::1]:46606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUum8-0007Wc-GD for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 12:14:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43392) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUulX-0006YR-Ln for emacs-devel@gnu.org; Sat, 02 May 2020 12:13:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUulW-0000ME-PO for emacs-devel@gnu.org; Sat, 02 May 2020 12:13:23 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:39315) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUulW-0000M0-CM; Sat, 02 May 2020 12:13:22 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id y24so3638633wma.4; Sat, 02 May 2020 09:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4VfJn0dgNtT6xg1AN16DJBw+e2f5V/eAqHmm8/G+LfQ=; b=eiAblbdJEFS+TMthqJX4DiuXhEHtsriFlJoytr7cSLK9Bo+jSZOhr1GlzEy6nyX3BX N/haephGl+ArLIDxH6GmEsy1sR8HHtZUpLdKyE87VMG5ef8xVSEZNWV453+cvThghGTw +cj3zvfxPwumB7Of9m90yhFJ+4ac/MRKF8l6Zdtjr/WVjsqQxlHVO5/gK6Px8jcPoqaz BqSNyqmhaktPl9PNQpw7bhePB+i/pge2kmsCbWry6ykxAOUQU6nHsgLIGI0s/ewG4we5 oZs75LG0s79rP6/3aeTK7UfAR/avrmtW41OilvCCnP26DHuIL5+uCVmsCMRBwto1XChn NqMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4VfJn0dgNtT6xg1AN16DJBw+e2f5V/eAqHmm8/G+LfQ=; b=YGoQ3uJBgPfYyTS0Wc1r8HyVFTd5d2lgI/hpmq2/32PeZkKhikcISwyrXwWIwBSxY5 zfShQTA+pp25W2RgZYAtSlYzNdntAShQRBD3K/PMa6VnnGh/tObGpB1uhMqxsghvvXAR oTQ0JP9P6EeyMkH4hYcaQ0BnYWuMIvX5TDLLykhkP2bM4A1UiToiaNiQRRhaPmC2qMDK oGESYXU1Z9s4nPf1wph3spYoDlVFDbyHVYGG60DLPR/roBhBy5hGkI6Se4MZ8YytxGZj V24GsXHMTPgJcKxNYc9n3C+4myltbzamkJSltmmGGC6jBIhJXwfVyDSZ+p5BIRV9h7RF D6vg== X-Gm-Message-State: AGi0PubT+4yLUto+FR5seE/yJkk1pKGdqzfJS2YUEYqkWBIIz/9DXA7l icaH+ftiPDrDDu5ilDZWIEI= X-Google-Smtp-Source: APiQypKwIHt4zDiuUGm1ElPRntV6E1qwhTm4httn0jEWJ0q37G5w+bQGNNPlfX5Ba1UOtSCArh6YGQ== X-Received: by 2002:a1c:9d84:: with SMTP id g126mr4852718wme.184.1588436000566; Sat, 02 May 2020 09:13:20 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id u2sm7967383wrd.40.2020.05.02.09.13.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 May 2020 09:13:19 -0700 (PDT) In-Reply-To: <83wo5usaui.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32c; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32c.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::32c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248484 Archived-At: On 02.05.2020 16:52, Eli Zaretskii wrote: > If by "look" you mean to the user, then I envision a list of > completion candidates that somehow "knows" what I'm after, and places > those likely guesses near the beginning of the list. All fuzzy completion systems do that. Generally by scoring how well each string resembles the input string. Whether there are gaps between the matched characters, and so on. Our 'flex' completion style has this feature as well. >>> and only after that consider changes, like the >>> proposed "namespacing" of APIs, that will allow users to use >>> completion as a substitute for Help commands. >> >> Namespacing of APIs is a step that should help the users with the >> current default completion strategy. > > Like I said, I think the hopes it will deliver a significant enough > improvement are overrated. It will certainly bloat the lists of > candidates by factors, which is why I think it isn't a very good idea > as long as we don't have some smart scoring of candidates. The amount of "bloat" will be strictly limited by the number of aliases we add. I think there's a general agreement that we shouldn't go overboard. >>> It is IMO a bad idea to >>> flood the completion lists with many dozens of candidates and force >>> users to wade through them. I certainly wouldn't call that "progress" >>> for Emacs. >> >> Is that what fido-mode does? People seem to like it. > > I don't have a good idea of what fido-mode does, but the rather foggy > idea I do have says it just applies fuzzy search criteria, attempting > to find non-literal matches. If this is so, then I don't think fido > cuts it. You can try it. It uses 'flex', and thus it sorts the matches based on scores. > We need scoring that "learns" from what I do/did recently, > and from my habits. Otherwise the list of candidates will remain > hopelessly long, with no promise of having what I'm really looking for > anywhere near the beginning. There are systems like that, including in third-party Emacs packages. Personally, I'm not fond of the idea (the unpredictability, first of all), and I'd rather we polish the current scoring algo first. But it's good to have it customizable. > Compare with the Internet search: it almost always brings me hundreds > of hits, but I normally find what I was after among the first dozen. > Even more spectacularly, when I type a search phrase into the search > box, it guesses what my search phrase will be, and the guesses are > almost always very accurate, so much so that if I don't see a long > enough list of reasonable candidates, I usually go looking for some > typo in what I typed (and almost always find it). Some of the > candidates are based on my previous search phrases, and the ones I > typed are always ready to be reused, with a special indication to let > me know I recently used them. Right. There's some benefit in that. But also note that Internet searches can't really use fuzzy matching, at all. I'd venture to say that it will be difficult to combine fuzzy searches and historical scoring, too.