From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: VOTE: Changing completions-common-part face's default Date: Thu, 7 Nov 2019 08:57:15 -0800 (PST) Message-ID: <18f69d65-953e-46fd-9a5c-6edb1e58932b@default> References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> <87h83ipoi0.fsf@gmail.com> <93235eb5-8e04-7182-e2a4-49fbe610ee2b@yandex.ru> <28d4ae09-daca-324b-2fa6-9d7138d710fa@yandex.ru> <87zhh82d8c.fsf@gmail.com> <1e1aa5a7-a35b-2ef5-6caf-10e02dd0c6ea@yandex.ru> <3cfbe69a-c274-f4f2-f3f5-9eb4c8500bb8@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="100993"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Stefan Monnier , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 07 17:59:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iSl8U-000QA9-Ji for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 17:59:54 +0100 Original-Received: from localhost ([::1]:45646 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSl8T-0005XC-6g for ged-emacs-devel@m.gmane.org; Thu, 07 Nov 2019 11:59:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45821) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iSl6Q-0004Cc-NM for emacs-devel@gnu.org; Thu, 07 Nov 2019 11:57:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iSl6P-0004hd-1d for emacs-devel@gnu.org; Thu, 07 Nov 2019 11:57:46 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:39276) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iSl6O-0004hI-OS for emacs-devel@gnu.org; Thu, 07 Nov 2019 11:57:44 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA7GsQCR178297; Thu, 7 Nov 2019 16:57:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=yrKMAWh/sRCVYIQdVkS6J7w2S2jT6Svbvp9Ps4m585M=; b=bPgt/4Q8U69fdIE/SMFZapAVn3jc+iC70crYnct//9ewQxMLEbvFXNYiTpCmXYLglbGK YwhImej9RDeL3LZzJp8pPx95WyAliJHuRNeUr7yb9acsmuy9eMhcETjnZH4sCuuB3x56 h7MHXZtUYF9Pvs4CU155D7K89hV+4KmWCmAXVIcbuWbzUq+js2R5m/gwBMBH4fcqglNa XB4k74cNrKBouQuY7WlI3/ZpCZqtJ9HrrQGOqPi03ulxZQQp3TaPqWI1WInwlQVUFeMe Yza8IH3hHe7VmmHIGV67nSzvfUvXCIHyR0pgJGIX5bMiHQI0NnuNrITm64aBsGGnLGvp yQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2w41w17kqr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Nov 2019 16:57:18 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA7Gs3xa086014; Thu, 7 Nov 2019 16:57:17 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3030.oracle.com with ESMTP id 2w41wfcdcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 07 Nov 2019 16:57:17 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id xA7GvGA9003382; Thu, 7 Nov 2019 16:57:16 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4900.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9433 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=897 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911070159 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9433 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=981 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911070159 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241942 Archived-At: > As soon as flex/fuzzy/scatter became accessible and popular > (because of programming speed) they decided to use ways to > highlight the matches, very often boldface. So it's not a > "trend" at all. We should ask Drew who probably has had such > system in place for a much longer time. I can't speak to any trends. Different kinds of fuzzy matching have existed outside and inside Emacs for a long time, in various 3rd-party libraries. AFAIK, I (in Icicles) was the first to use such kinds of matching for _completion_ - that's all. That dates back to 2006 or before. More generally, beyond various kinds of what is sometimes called "fuzzy" matching, there are kinds of matching other than basic, prefix-only matching - substring matching, for example. And some of those were added to Emacs, including for completion, and including fairly long ago, ultimately as `completion-styles'. "Fuzzy" matching can, if you like, include so-called "flex" matching (Icicles calls this "scatter matching"). The basic scatter match is a "poor man's fuzzy". It just uses a simple regexp constructed from the chars you type, by inserting `.*' between them - typing `abc' uses regexp `a.*b.*c'. What Icicles also provides "SPC scatter" matching, which, IIUC, what is used by Ivy (but someone can correct me). It's like scatter matching, but it matches the parts of your input that are separated by SPC chars - it matches arbitrary text at the separations between those parts. On their own, such scatter matching does not provide or use any scoring. But some more-truly "fuzzy" matches do sometimes provide scoring. Icicles highlighting of matches is pretty simple. It doesn't bother to try, for some kinds of fuzzy matching. For those that translate to using a regexp, such as the scatter matches, highlighting is trivial (`string-match-p'). I already spoke to the utility of highlighting the matched part (plus, in the case of Icicles, the part that is common to all matching completions). I'll just add, since someone brought this up: it's not about not trusting the matching algorithm. It's not about checking by eyeball, to see if there are matches shown that you don't think really belong there. Not at all. It's, yes, partly that "fuzzy" etc. completion is not always obvious; the results are not always what one might expect. But more importantly, it's just to provide you _feedback on what you're doing_. You're matching input against a domain of possible candidates - you're exploring that domain. Visually connecting what you do with what you get really does help. And, since the contrary has been said several times now in this thread, it's _not_ just about figuring out what the next char you type should be. The "next char you type" is only one way to interact with the set of possible candidates and the set of current matches. Focusing on that's based on thinking in terms of prefix matching, choosing a single candidate, and immediately exiting completion. Besides the "next char you type", there's what chars you might delete, and where, what chars you might insert, and where - and many other actions, which might have nothing to do with editing your input. When you can act in many different ways on particular, or all, current matches, it really helps to be able to distinguish them in terms of which of their parts match the input pattern. Dunno how to explain this more, briefly. I'm sure that those users who've used completion setups that let you act on multiple candidates or in multiple ways, or that let you match in more complex (sometimes unclear) ways, get it. For those who don't, I say play with it, and you will. FWIW, I'm _not_ a big proponent of fuzzy matching. I'm a big proponent of substring and regexp matching. What I use, myself, the vast majority of the time, is regexp matching, which includes substring matching. But YMMV. And Icicles does provide several kinds of fuzzy matching. This page describes them: https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles