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: new-flex-completion-style Date: Thu, 14 Feb 2019 22:03:57 +0000 (UTC) Message-ID: References: <20190202232827.27331.87300@vcs0.savannah.gnu.org> <20190202232828.4AE452159A@vcs0.savannah.gnu.org> <87lg2mynrg.fsf@gmail.com> <871s4czm5n.fsf@gmail.com> <1f4513ab-cd39-4543-9b1a-743e1307dd54@default> <23b6cda2-0f37-4c41-b664-5353505c0cd1@default> 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="222225"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Daniel Pittman , Stefan Monnier , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 14 23:04:20 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.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1guP7D-000vfU-TX for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 23:04:20 +0100 Original-Received: from localhost ([127.0.0.1]:55836 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guP7C-0000Jb-9w for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 17:04:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guP71-0000I3-U9 for emacs-devel@gnu.org; Thu, 14 Feb 2019 17:04:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guP70-0004e7-7r for emacs-devel@gnu.org; Thu, 14 Feb 2019 17:04:07 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:44304) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guP6z-0004cv-TW for emacs-devel@gnu.org; Thu, 14 Feb 2019 17:04:06 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x1ELnAwU165856; Thu, 14 Feb 2019 22:04:03 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-2018-07-02; bh=1P/wVJ3ZHN/no3s9tI+9yfSfFRKWABl3gpETIU7iRiE=; b=ZbU9L0cRg76Nh9PsrNtKKQ+mAR7MB/AgjoOIwJQkH3HwH4/ro8YyDxfZoRMR3YNVZlHX KpXpRX5zHVVdseHwU4aeie9kBT+vYe6XI7WbJaDWroHuu1cmxTyy87/fiaICXEWo59zM UNBgowi2So90lRXUmwhu5MChgBjMEVfP54LdWQfHkyLym2nSt6glyPodrpj5/saDf+7b WsZjB9Pxr/kLvKTqLoGNm6ZRWKmmHS8V+UrvWB9oid2DjnykrBda/bSzNIf9msG5iqTh r6HCBAbblBtus2Sq2YPiHBWUjWgHrlTRD5Mw4AtOc33p5hAOhCxrm5Vczj2kgBveiZVn rA== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2130.oracle.com with ESMTP id 2qhre5tm0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 22:04:03 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x1EM42nn008543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Feb 2019 22:04:02 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x1EM3woR023926; Thu, 14 Feb 2019 22:03:58 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4810.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9167 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 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-1810050000 definitions=main-1902140144 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 141.146.126.79 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:233346 Archived-At: > > Can you see that some of the following predefined orders > > might be advantageous in particular contexts/use cases? > > Can you see that whether matching is scatter, regexp, > > basic prefix, or others, any of the following can be > > useful? >=20 > No, I can't. Seriously? You can't imagine that someone completing buffer names might want to (sometimes) put more recently used buffer names before others for better visibility or for quicker cycling access? You can't imagine anyone ever wanting a different order of candidates than what you would define based on match scores? Match scores are tightly linked to sort order only for certain kinds of matching. And even then such an ordering is typically "all other things being equal", i.e., for lack of any more meaningful sort. What you say sounds bizarre to me. Different contexts can call for different sort orders. And different commands provide different contexts, as do different user preferences. Take Info nodes for `g', for instance. Can't you imagine that sometimes you might want to see completion matches in book order, and other times in order of the dates of your past visits, and other times in order of the number of your visits, and other times in alphabetical order? And even for, say, number of visits, can you imagine that sometimes you want to visit nodes that you've visited a lot, and other times you might want to visit nodes that you've never visited? Do you really feel that one size (one order) fits all? > That's probably input for the style vs category vs table > vs UI debate, where I'd rather, like Stefan, go for the path of > least redesign which seems to plug sorting to a style. My own opinion on that is that what's important is that a user be able to control such things on the fly. Sort order, for example: be able to immediately change it by hitting a key while completing. AFAIK (I could be wrong; I don't bother following this evolution), vanilla Emacs doesn't even give users a way to change completion styles on the fly. Adding a sort order or a category or whatever else to a style definition doesn't help if a user can't turn on a dime, switching to a different style. What's more: As long as accommodation is attempted by _combining_ such (pretty independent) things: sort order, match method, categories, users will lose. Why? Because even if you give them a way to quickly switch styles they can't switch parts of a style. With 3 axes (order, matching, category) and with, say, 4 choices per axis, that's a lot of possible combinations. To allow a user to pick any of those combinations s?he'd need a style for each combination! And then s?he'd have to be able to remember them all and keep track of them. No, the right approach, I think, is to let users move at will, fluidly, along any such axis, to get any combination anytime. All a user needs to remember in that case is a key to choose something on a given axis. But no, I'm not trying to design or redesign vanilla Emacs completion. I tried to communicate all of this long ago, and several times. No takers. So be it. Been there; done that. (I have, however, seen several of the ideas picked up by other completion systems: Helm, Ivy, even Ido and Icomplete in some cases.) > Perhaps I'll change my opinion with specific use cases where > using my proposed sorting function with flex isn't a good > solution. You should be able to change from, or to, it on the fly, when you find that useful. Then, being a believer in your thing, you would set it as your preferred default behavior. But you'd still be able to pop out of the box when you felt like it, and _without_ customizing some preference and then starting over.