Re: Imports / inclusion of s.el into Emacs

[João Távora]

On Tue, May 5, 2020 at 8:26 AM Philippe Vaucher
<address@hidden> 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ão

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