Doom-emacs: [BUG] ivy +fuzzy not working like it used to

[tam5]

What did you expect to happen?

How it used to work:

What actually happened?

How it works now:

This is just one example where relevance seems to have jumped from first to last, but across the board, the fuzzy matching seems to be worse than it used to be, at least in my experience.

Additional details:
Through a combination of git bisect and manual process of elimination, it seems like https://github.com/hlissner/doom-emacs/commit/a24b750c6c90cea0fe70b149d4f0ac7f19b1f632 is the last commit for which this was working as I would have expected.

I've also tried with all combinations of ivy +fuzzy +prescient, both, neither, etc.

If it helps at all, here is a link to my doom.d: https://github.com/tam5/doom.d

System information:

((emacs

  (version . "26.3")

  (features . "NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS")

  (build . "Sep 02, 2019")

  (buildopts "--with-ns '--enable-locallisppath=/Library/Application Support/Emacs/${version}/site-lisp:/Library/Application Support/Emacs/site-lisp' --with-modules")

  (windowsys . batch)

  (daemonp . server-running))

 (doom

  (version . "2.0.9")

  (build . "HEAD -> develop, origin/develop, origin/HEAD 8a9d8f03e 2020-01-05 20:12:24 -0500")

  (dir . "~/.doom.d/"))

 (system

  (type . darwin)

  (config . "x86_64-apple-darwin18.2.0")

  (shell . "/bin/bash")

  (uname . "Darwin 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov  9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64")

  (path "/usr/local/opt/ruby/bin" "~/.composer/vendor/bin" "~/Code/platform" "~/.emacs.d/bin" "~/bin" "/usr/local/bin" "/usr/bin" "/bin" "/usr/sbin" "/sbin" "/Applications/Emacs.app/Contents/MacOS/bin-x86_64-10_14" "/Applications/Emacs.app/Contents/MacOS/libexec-x86_64-10_14" "/Applications/Emacs.app/Contents/MacOS/libexec" "/Applications/Emacs.app/Contents/MacOS/bin"))

 (config

  (envfile . envvar-file)

  (elc-files . 0)

  (modules :completion (company +auto +childframe) (ivy +fuzzy +prescient) :ui better-company doom doom-dashboard doom-quit hl-todo indent-guides modeline nav-flash ophints (popup +all +defaults) treemacs vc-gutter vi-tilde-fringe window-select workspaces :editor (evil +everywhere) file-templates fold multiple-cursors rotate-text snippets :emacs dired electric ibuffer vc :tools docker editorconfig (eval +overlay) flycheck flyspell (lookup +docsets) lsp magit :lang data emacs-lisp go (java +meghanada) javascript markdown (org +dragndrop +present) (php +lsp) (python +lsp) rest ruby scala sh web :config (default +bindings +smartparens))

  (packages vmd-mode vue-mode sws-mode "(evil-embrace :disable t)")

  (elpa "n/a")))

[hlissner]

Turns out ivy and counsel have a number of hard-coded checks for flx against ivy--regex-fuzzy:

• https://github.com/abo-abo/swiper/blob/master/ivy.el#L3531
• https://github.com/abo-abo/swiper/blob/master/ivy.el#L3637
• https://github.com/abo-abo/swiper/blob/master/ivy.el#L4643
• https://github.com/abo-abo/swiper/blob/master/counsel.el#L1359
• https://github.com/abo-abo/swiper/blob/master/counsel.el#L1561

This means, by assigning our own delegates around ivy regex functions we're breaking flx functionality, including the old sorting behavior.

As of ae8dc27 this issue should be resolved. Let me know if that isn't the case and I'll reopen it. Thanks for bringing it to my attention!

[tam5]

Better, thanks!!