From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Tue, 5 May 2020 11:14:44 +0100 Message-ID: References: <0c88192c-3c33-46ed-95cb-b4c6928016e3@default> 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="109418"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Richard Stallman , Emacs developers , Stefan Monnier , =?UTF-8?B?7KGw7ISx67mI?= , Dmitry Gutov , Eli Zaretskii , Drew Adams To: Philippe Vaucher Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 12:15:50 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 1jVuc7-000SKq-Sf for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 12:15:47 +0200 Original-Received: from localhost ([::1]:51606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVuc6-0000gV-Ur for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 06:15:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58220) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVubL-0008Vr-Sb for emacs-devel@gnu.org; Tue, 05 May 2020 06:14:59 -0400 Original-Received: from mail-io1-xd42.google.com ([2607:f8b0:4864:20::d42]:44725) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jVubK-00013L-UN; Tue, 05 May 2020 06:14:59 -0400 Original-Received: by mail-io1-xd42.google.com with SMTP id z2so1329371iol.11; Tue, 05 May 2020 03:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W39/d0GAt0y7lNMzqDWj2pkChlnZ1t6GMgbBekeDNpc=; b=Aj8aWEoco+/IPYc7mujaoNbfLTdQdqf6hBm4yDsvuiOx2LLJWihYgCiojGldYpZXNt 7eDid+cYQYzt9TN7LzQyWgTQsTCPWQOhxMFHQV7283l6cc/VVc6U/lh4JjyHbLc9SOlm 2oF3RnZeVHdbkEBOALgg3YQpCLXEKZvGFWXosMo+fdA7bLEtk8AwpBiSMaoqFCvchNLh IQPlCcldzVaUfNaTJF2hXoFyvpVVvO1vrdfkJd81uN+e09WGq+PYirvJ2Mx0t2uA1Sl3 f/OnxecCPbm3H6fmpgHhl3dM4ezA6pru6zpBk30Xhtl5hvEbZxft3iyzAjZOVimsQPfS XwPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W39/d0GAt0y7lNMzqDWj2pkChlnZ1t6GMgbBekeDNpc=; b=OD77tb8EUIpUJQLJQ3A1/jlbNPI6ceIxm5alrXUGUnZdxjOqPb3XEWJBrDSCSEx+Sx Ewl5hBVykWLdplBdPzqKqoPbsjV+p43Wr2YtlIVhZGagV782GcnkUhTqKLSw34aKZV6U y6LGyaLIzbmmauc5Eo2Xfi6VCM27pNzEfogBpOkjCwpXw/NfIVUpdgSipe/4xnnnWDGO hBLtRSbF5/0X7YYPGIrerNpj1Qojzrq3eAtY973auW7JIdznFHdHHbEBiKhRYmsugW4W muSV10thUlzCd829/w1ppKftW1oU629MJQmwy/W7752/Z9YqtQWEiIgWYO3/09Hl65pe N4sQ== X-Gm-Message-State: AGi0Pub0NHFgx8K9E+dcOcjIy6sLHMK9iXmNzai56tv+QHRT2v2kCFhY Tl4sAS+XonUL86FhAFpKbRCeLH0K4ReokbUY09M= X-Google-Smtp-Source: APiQypIpd7au5HlotF0MOLW34e1t8DIEaL/XBH+YvNKUi13XW+wb1fYc3SgAQf4K8kaW9HBC39kK50jAQnxR+1onQZA= X-Received: by 2002:a6b:6a13:: with SMTP id x19mr2538854iog.175.1588673697035; Tue, 05 May 2020 03:14:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::d42; envelope-from=joaotavora@gmail.com; helo=mail-io1-xd42.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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:248960 Archived-At: On Tue, May 5, 2020 at 8:26 AM Philippe Vaucher wrote: > > > Don't forget that completion can now use substring > > and other kinds of matching. > > You understand that substring completion fails as soon as the term is > too generic? e.g "string", "regexp" or "list", the list is just a lot > of noise. Have you actually tried Drew's suggestion? Starts an Emacs -Q and (setq completion-styles '(flex)), or just M-x fido-mode. Then C-h f for "string". You get a _little_ noise but it's not "a lot", by far. And the little noise you _do_ get from internal functions in other packages is pretty easy to remove if you boost things by their mentions in the manual. In fact there's a patch at the end of this message. > Also it doesn't quite work when the order is "reversed", e.g> C-h f > "string TAB multibyte" would not return the desired function > because it has to be "multibyte TAB string". But that's never going to work either way, unless you alias all the multi-word symbols to all their possible permutations. You'll always get a group of people that really expected it to be multibyte-string and group of people that expect string-multibyte. Oh, maybe we should all be searching for "multibyte" instead! Bam. First 5 results: multibyte-string-p string-to-multibyte string-as-multibyte set-buffer-multibyte multibyte-char-to-unibyte To be clear. I'm not presenting these examples to be antagonistic. I'm kind of sympathetic to your laziness to read the manuals, I'm lazy myself, a reasonably good trait in programmers. So I really do use these tools (and work on them) to get around an imperfect world instead of demanding that the world adjust to my rigid way of thinking. That said, it is possible to devise a completion style that will take two words and match them against candidates in different ways, maybe even matching them against other properties besides their names. I haven't found it really useful, yet. But it's not absurd to think about that and writing a smart completion style for Emacs is a much better (and more interesting) contribution to it than the renaming sledgehammer. Also sometimes, I'll read the manual and be really impressed by its quality, too. Jo=C3=A3o Anyway here's the "use the manual to bump up flex score" patch. diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index f6e2b236f3..1590b954b7 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3191,6 +3191,12 @@ flex-score-match-tightness than the latter (which has two \"holes\" and three one-letter-long matches).") +(defvar flex-score-adjustment nil + "If non nil a function of to adjust score of a flex match. +Function is passed three arguments: MATCH, PATTERN and +preliminary SCORE. It should return a factor by which to +multiply SCORE to reach the final value.") + (defun completion-pcm--hilit-commonality (pattern completions) (when completions (let* ((re (completion-pcm--pattern->regex pattern 'group)) @@ -3279,9 +3285,16 @@ completion-pcm--hilit-commonality 'completions-first-difference nil str)) (unless (zerop (length str)) - (put-text-property - 0 1 'completion-score - (/ score-numerator (* len (1+ score-denominator)) 1.0) str))= ) + (let ((prelim + (/ score-numerator (* len (1+ score-denominator)) 1.0)= )) + (put-text-property + 0 1 'completion-score + (* + (if (functionp flex-score-adjustment) + (funcall flex-score-adjustment str pattern prelim) + 1) + prelim) + str)))) str)p completions)))) Then do this: (setq flex-score-adjustment (lambda (m _p _s) (if (assoc m (info-lookup->completions 'symbol 'emacs-lisp-mode)) 4 1))) Then try C-h f string, C-h f process