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: BIKESHED: completion faces Date: Wed, 6 Nov 2019 13:40:41 -0800 (PST) Message-ID: <5e0c941c-e625-4e42-87b3-91a5a1a1f38f@default> References: <> <> <> <<4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru>> <> <> <<87pni7p83l.fsf@gmail.com>> <> <> <<83h83ignrz.fsf@gnu.org>> <> <<83ftj2gma8.fsf@gnu.org>> <<87zhhaxalt.fsf@gmail.com>> <<83bltpgffr.fsf@gnu.org>> <> <<83tv7gg9oz.fsf@gnu.org>> <<7916c845-1ce2-4abd-937f-09036cd60bec@default>> <<83pni4g2iq.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="113017"; mail-complaints-to="usenet@blaine.gmane.org" Cc: dgutov@yandex.ru, joaotavora@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 06 22:41:17 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 1iST3F-000TIU-A9 for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 22:41:17 +0100 Original-Received: from localhost ([::1]:35388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iST3C-00064P-PB for ged-emacs-devel@m.gmane.org; Wed, 06 Nov 2019 16:41:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56097) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iST2u-00064E-9J for emacs-devel@gnu.org; Wed, 06 Nov 2019 16:40:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iST2s-00028I-SU for emacs-devel@gnu.org; Wed, 06 Nov 2019 16:40:55 -0500 Original-Received: from userp2120.oracle.com ([156.151.31.85]:41586) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iST2l-00024t-V6; Wed, 06 Nov 2019 16:40:49 -0500 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xA6LdYp7183441; Wed, 6 Nov 2019 21:40:44 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=YqxC/sKSlKDbblNZGfMBytlDPaeUqVjT7yhXhyr7WQA=; b=AazgNzE7XCglBADr9M+5bDwfT6Ig5S901PVCxr2pEhIO5A+ycxySRzGoGdoG1AtPvcoN X8zNBIf9FzxhHRzgEzHBY1bUvCB+g8jYT9zpHevvvdjF0axSjYKs3pfLXLAjEqt5OvT9 rP6aTEVJ9p3INpTASyiX6b3jkWHIaTF0oAUi72wotlYalq42Qmd8Ka6IVuzjUwWUUJU1 ZVWTZP/u7wDjdlf4d4zne3Al8ReKKSB8N6H4YWXmotGRMerP5wSPm33cue/tSwS5A8RO 59185c1Q1pvrGWMWd5Ib1zXKj4GlJsJs6647s9U6/0xjiRIPwX3b4ncDobRaVFlTa/Ys rA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2w41w0sw6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 06 Nov 2019 21:40:44 +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 xA6LYkaO097992; Wed, 6 Nov 2019 21:40:43 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 2w41wd9nn1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 06 Nov 2019 21:40:43 +0000 Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xA6LegG6032238; Wed, 6 Nov 2019 21:40:42 GMT In-Reply-To: <<83pni4g2iq.fsf@gnu.org>> 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=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911060209 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=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911060210 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.85 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:241878 Archived-At: > > Completion is not just about choosing a completion > > candidate - at least it _need not_ be only about > > that. It's also about exploring a set - the set of > > things that match your current input. >=20 > Yes, but I don't see how highlighting what exactly matched is of any > help in that case. Especially with the weirdo matches some aggressive > completion styles produce. I care about the candidates and about how > to narrow the list, not about how and why the completion picked up > these particular candidates. If you care about the set of candidates as a whole, and are not just trying to "find the one", or if you're interested in redefining that set (including possibly narrowing it), then "what exactly matched" your input can be very helpful info. Vanilla Emacs doesn't let you operate on the set of matching candidates. And it doesn't update that set incrementally as you change your input. So your not appreciating the value of what-parts-currently-match feedback is understandable. Maybe think about the fact that other UIs have added similar such behavior, and it's come up independently. This wheel has been discovered multiple times. At least it was independent in the case of Icicles, and I'm guessing the same was true for at least one of VScode, Sublime, and Atom. It's not (at least in the case of Icicles) as if such highlighting was present at the outset. It came naturally out of using the different kinds of matching - i.e., out of practice. With basic prefix matching, sure, the only thing you need to look for, to understand why you get the candidates you do, is the matching prefix (hence "first difference"). With other kinds of matching it's not always obvious why this and that are candidates. Highlighting the parts that match helps. But I don't imagine I can convince you. > > Among other things, knowing what & how your input > > matches can help you adjust it to match different > > sets of candidates. >=20 > That's what the "first difference" highlighting solves. No, sorry, it doesn't. And there's really no special significance for "first difference". > > Icicles highlights matches for your input with > > different faces. See attached screenshot. >=20 > Sorry, I'm unconvinced. I cannot think of a > situation where such highlighting would help me. Yes, I imagine you can't. Sorry, but I don't have the energy, time, or will to try to help you with that. Maybe someone else does (or not). I think one key to understanding is to practice with different ways of matching. Another is to think of operating on the set of matches. Perhaps, with the latter for example, you can guess how it can help to know whether all candidates have a common match part and what that part is. Or not.