From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Add user customization fido-completion-styles Date: Tue, 2 Jun 2020 13:51:36 -0700 (PDT) Message-ID: <47051525-ddc5-414f-a2ea-d84065d5100a@default> References: <87r1uzn018.fsf@gmail.com> <953E1512-6420-4AE8-AF29-15AB151B6344@schwartzmeyer.com> <877dwpn2id.fsf@gmail.com> <3483a8d9-1474-45cf-afad-8d276b96ef3f@default> <87sgfdl5jw.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="83158"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 02 22:52:25 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 1jgDtY-000LVS-RE for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jun 2020 22:52:24 +0200 Original-Received: from localhost ([::1]:52270 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgDtX-0005MX-Pf for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Jun 2020 16:52:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgDt2-0004uh-EV for emacs-devel@gnu.org; Tue, 02 Jun 2020 16:51:52 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:57534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgDt0-0005IU-Sa for emacs-devel@gnu.org; Tue, 02 Jun 2020 16:51:51 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 052KaidZ043291; Tue, 2 Jun 2020 20:51:47 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-2020-01-29; bh=4aWl6Oic3mw0fUiCOVWOl7aI93RKy5twphlG7WDS4B4=; b=yUZklVi0wPFzqukn1KXAfHnDVqZ+4KxlA9yBg7Zu4rvn8E9alqmJrOAODqOIID7dw+Gq pbB/8EQWUxHxVQ0NI6+rKVOyRblqZ8W5teW2fMC6XVOwnAuZctHKFatT8MhV8YEvWROX q3iIs11nXcrFN89lZ+HJBVs50sGmSkw6NoE421I8Ms9T+zBO6Cw16PIwImnTlhhBqC7+ OTotaaddEwxerIUzhzofTvzkHufHiO+EtwqKvpxkzo9ajYEYBbMl2grIHbU6OPk/kA2V hrLHeMpbpUG1vJn6Zh26r8h7YaROsqpwf8Nni9O8HXsH7JTXTdWIe+LSLG/4BjKNVDpL 5Q== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 31bfem60hw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 02 Jun 2020 20:51:47 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 052KdPv3147184; Tue, 2 Jun 2020 20:51:46 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 31c12ptxn1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 02 Jun 2020 20:51:46 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 052KpigY032039; Tue, 2 Jun 2020 20:51:44 GMT In-Reply-To: <87sgfdl5jw.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5005.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020150 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9640 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 suspectscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 phishscore=0 clxscore=1015 impostorscore=0 adultscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006020150 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/02 16:51:49 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:251783 Archived-At: > > As for performance, for `M-x' there certainly is > > no problem. `M-x' with no input pattern to match > > shows the 6000-some candidates immediately. >=20 > Certainly it doesn't _show_ 6000 candidates, right? > You must mean it calculates them quickly and shows > the top-sorting set quickly. That's great, I guess, > and I join in asking if Emacs shouldn't do that. No, it can show them all. Sure, because of Emacs's display code, it shows only as many as fit in the `*Completions* window. But I'm using a separate frame for `*Completions*', and I can shrink its font size to show zillions of them. Yeah, at a certain point the font size becomes too small (no such font). But there's no problem calculating and showing lots of candidates. However, with Icicles flx sorting, the score for each candidate, when there's no input pattern, i.e. (flx-score CANDIDATE ""), is nil. And as I mentioned, when either of the flx scores is nil the candidates are compared alphabetically. `flx-score' (from `flx.el') is meaningless for empty input. (See my previous mail about this.) Things are slower when an input pattern is used. E.g. with `M-x b' I see a pause of a couple sec, for 864 candidates. So yeah, flx sorting isn't super rapid. But that's OK. Icicles users can change sort orders anytime, on the fly. > I didnt' dig down very intensively, but my naive > profiling shows the bulk of the work to be in > `all-completions' or thereabouts to be the > main sink of cpu time: I was reporting about Icicles, not icomplete. But yes, Icicles uses `completion-all-completions' too (in this context). > As you know, all-completions is a C function. > The 1% is suspicious, I don't know if I should > trust it. >=20 > Anyway, I'm curious how Icycles evades this. See above. I was speaking of the empty-input case, where `flx-score' returns nil, in which case the sort predicate falls back to comparing alphabetically. Also, Icicles sorts (and displays candidates) outside the standard completion code. It sorts the current set of completions at the end. > Anyway2, I wasn't trying this in an Emacs -Q. > When I do, and I set icomplete-compute-delay to 0, > then M-x is practically instantaneous. >=20 > Maybe the default 0.3 value of that variable is > excessively conservative. (FWIW, Icicles's delay for the number of sec to wait before updating *Completions* incrementally is 0.7 sec, by default. But there's no wait if the number of candidates is =3D< the value of option `icicle-incremental-completion-threshold', whose default value is 1000.) > So, to summarize: I do believe could be some > shortcuts for the notable case of no input pattern > to give a speed boost, maybe showing them them > their relevant minibuffer history. Yes, for that notable case. I'd say no, to using input-history order. (And what do you do if two candidates to compare can't be compared by flx and one or both is not a previous input?) In Icicles, one of the available sort orders is sorting "by last use as input". A user can switch to that anytime during completion. In general (most cases), that's not a good default sort order. It all depends on the user, and on what kind of candidates s?he's sorting, and why. That last-use-as-input sort order is defined as: Non-nil means S1 was used as input more recently than S2. Also: S1 < S2 if S1 was used as input previously but S2 was not. S1 < S2 if neither was used as input previously and S1 `icicle-case-string-less-p' S2. > I don't believe there's some kind > of magical speed pickup to be had. Agreed. Sorry if I gave a false impression in that regard. FWIW, I'm a firm believer in giving users control over this kind of thing, as opposed to trying to bake in some optimal combination that an Emacs developer thinks is a good idea in general, but without giving users an easy way to override that. Yes, a given command (given kind of completion candidates) can call for a given kind of sorting by default - that default sorting behavior should be up to the designer of that command. But past that, a user should be able to choose the kind of (default) sorting to use, including for a specific predefined command, and in general. And beyond that, a user should be able to change the current sort order on the fly, while completing. (Icicles allows all of that.) > Even the C rewrite of parts of > completion-pcm--all-completions now seems dubious. I can't speak to that. > > This way of combining yes-no-maybe predicates is > > described here: > > https://www.emacswiki.org/emacs/ApplesAndOranges >=20 > Have you tried `fido-mode` and/or flex? Can you > think of specific ways to improve it? If so, > patches are very welcome. No, sorry. And I'm no expert on flex matching or fuzzy matching (of any kind). Icicles lets users use different kinds of matching, some of which are provided by other 3rd-party libraries, if you load them. > It's a bit harder, I admit, to try to learn Icicles > and decide which features to migrate. But if you > can point some laser-targeted improvement to the > flex algorithm (in efficiency of functionality) > are very welcome. I don't have anything to help wrt flex. I just enable Icicles to use library `flx.el' which has been around for years. I do the same for other kinds of matching. See this doc page: https://www.emacswiki.org/emacs/Icicles_-_Completion_Methods_and_Styles These are the matchings that require other libraries, for use by Icicles: * Swank fuzzy-symbol matching requires `el-swank-fuzzy.el'. * Fuzzy matching requires `fuzzy-match.el'. * Jaro-Winkler matching requires `fuzzy.el' (in package `autocomplete'). * Levenshtein matching requires `levenshtein.el'. (There are 2 kinds of Levenshtein matching.) The only "fuzzy" matchings I define in Icicles itself are these: * Scatter matching (sometimes called "flex" elsewhere). This is just regexp matching with `a.*b.*c=E2=80=99 * SPC-scatter matching (some other packages use this). This matches input parts that are separated by SPC chars, matching arbitrary text at the separations between those parts. IOW, it's as if regexp `.*' were inserted in place of each substring of SPC chars. HTH.