Vertico does not sort by history

[cccslater]

Hi! I am having trouble getting vertico to sort suggestions by history. My minimal config (elpaca/savehist/vertico):

(defvar elpaca-installer-version 0.12)
(defvar elpaca-directory (expand-file-name "elpaca/" user-emacs-directory))
(defvar elpaca-builds-directory (expand-file-name "builds/" elpaca-directory))
(defvar elpaca-sources-directory (expand-file-name "sources/" elpaca-directory))
(defvar elpaca-order '(elpaca :repo "https://github.com/progfolio/elpaca.git"
                              :ref nil :depth 1 :inherit ignore
                              :files (:defaults "elpaca-test.el" (:exclude "extensions"))
                              :build (:not elpaca-activate)))
(let* ((repo  (expand-file-name "elpaca/" elpaca-sources-directory))
       (build (expand-file-name "elpaca/" elpaca-builds-directory))
       (order (cdr elpaca-order))
       (default-directory repo))
  (add-to-list 'load-path (if (file-exists-p build) build repo))
  (unless (file-exists-p repo)
    (make-directory repo t)
    (when (<= emacs-major-version 28) (require 'subr-x))
    (condition-case-unless-debug err
        (if-let* ((buffer (pop-to-buffer-same-window "*elpaca-bootstrap*"))
                  ((zerop (apply #'call-process `("git" nil ,buffer t "clone"
                                                  ,@(when-let* ((depth (plist-get order :depth)))
                                                      (list (format "--depth=%d" depth) "--no-single-branch"))
                                                  ,(plist-get order :repo) ,repo))))
                  ((zerop (call-process "git" nil buffer t "checkout"
                                        (or (plist-get order :ref) "--"))))
                  (emacs (concat invocation-directory invocation-name))
                  ((zerop (call-process emacs nil buffer nil "-Q" "-L" "." "--batch"
                                        "--eval" "(byte-recompile-directory \".\" 0 'force)")))
                  ((require 'elpaca))
                  ((elpaca-generate-autoloads "elpaca" repo)))
            (progn (message "%s" (buffer-string)) (kill-buffer buffer))
          (error "%s" (with-current-buffer buffer (buffer-string))))
      ((error) (warn "%s" err) (delete-directory repo 'recursive))))
  (unless (require 'elpaca-autoloads nil t)
    (require 'elpaca)
    (elpaca-generate-autoloads "elpaca" repo)
    (let ((load-source-file-function nil)) (load "./elpaca-autoloads"))))
(add-hook 'after-init-hook #'elpaca-process-queues)
(elpaca `(,@elpaca-order))

(elpaca elpaca-use-package
  (elpaca-use-package-mode))

;; Persist history over Emacs restarts. Vertico sorts by history position.
(use-package savehist
  :ensure nil
  :config
  (savehist-mode 1))

;; Enable Vertico.
(use-package vertico
  :ensure t
  :init
  (vertico-mode 1)
  :custom
  (read-file-name-completion-ignore-case t)
  (read-buffer-completion-ignore-case t)
  (completion-ignore-case t))

;; Emacs minibuffer configurations.
(use-package emacs
  :custom
  ;; Enable context menu. `vertico-multiform-mode' adds a menu in the minibuffer
  ;; to switch display modes.
  (context-menu-mode t)
  ;; Support opening new minibuffers from inside existing minibuffers.
  (enable-recursive-minibuffers t)
  ;; Hide commands in M-x which do not work in the current mode.  Vertico
  ;; commands are hidden in normal buffers. This setting is useful beyond
  ;; Vertico.
  (read-extended-command-predicate #'command-completion-default-include-p)
  ;; Do not allow the cursor in the minibuffer prompt
  (minibuffer-prompt-properties
   '(read-only t cursor-intangible t face minibuffer-prompt)))

No matter what command I type/what files I open, the sort order remains the same. I have history and recentf in ~/.config/emacs as expected. :/

Any help appreciated ☺️

[yudin-s]

Vertico is sorting, but it only has useful history data when the current completion command uses a real minibuffer history variable and the historical entries match the current completion base.

A few concrete checks:

1. savehist-mode must have run before you expect persisted entries after restart. In a minimal elpaca setup I would put it in :init, so it is enabled immediately:

(use-package savehist
  :ensure nil
  :init
  (savehist-mode 1))

2. While a Vertico minibuffer is open, check the active history variable:

M-: minibuffer-history-variable

Vertico sorts from that variable. If it is t, or if the command uses a dynamic table without a useful history variable, there is nothing meaningful for vertico-sort-history-* to promote.

3. File completion is special. Vertico normalizes history relative to the current file-completion base, so ~/foo/bar.txt in history only helps when the current base makes that candidate comparable. It is not a global recentf sorter. If what you want is recent files first, use recentf-open-files / Consult commands, or add a category-specific display sort instead of expecting find-file to behave like recentf.

4. To verify the sort path directly, try a command with a simple history variable, for example M-x, run a rarely used command once, then open M-x again and type the same prefix. That should move the history match up. If M-x works but files do not, your config is fine and the difference is the file completion/history base.

Vertico also lets you override sorting per category. For example, if you want directories-first file sorting without relying on history:

(setq completion-category-overrides
      (quote ((file (styles basic partial-completion)
                    (vertico-sort-function . vertico-sort-directories-first)))))

So the likely answer is: your setup is basically correct, but history sorting is command/history-variable based, not a universal recentf/frequency ranking layer. First inspect minibuffer-history-variable in the exact command where it looks wrong.

If this points you in the right direction, please mark the answer as accepted so the thread is easier to find later.

[cccslater]

Thanks for the swift and detailed reply!

1. I have fixed this now
2. I believe it's extended-command-history. Describe variable shows my command history as I expect (lots of 'restart' as I troubleshoot!)
3. I might've worded my question badly, this is not what I was after
4. When I run any command with M-X it does not move up the suggestion pile the next time I M-X. This is what I was hoping to fix.

[yudin-s]

Thanks, that narrows it to execute-extended-command / extended-command-history, not file completion.

One detail I should have made clearer: Vertico's normal default is vertico-sort-history-length-alpha, and vertico-sort--history reads the active minibuffer-history-variable, so extended-command-history is the right history variable for M-x. However, Vertico also respects a completion metadata display-sort-function before vertico-sort-function. If the command/category supplies or inherits another display sort, changing only vertico-sort-function may not visibly change M-x.

The quick test I would try is to force the override only for M-x:

(use-package vertico
  :custom
  (vertico-multiform-commands
   '((execute-extended-command
      (vertico-sort-override-function . vertico-sort-history-length-alpha))))
  :init
  (vertico-mode)
  (vertico-multiform-mode))

Then run one uncommon command through M-x, open M-x again, and check with the same prefix. If it moves up with vertico-sort-override-function, the history is fine and the missing piece was another sort function taking precedence. If it still does not move, the next thing to inspect while the M-x minibuffer is open is:

minibuffer-history-variable
extended-command-history

The first should be extended-command-history, and the command name should appear near the front of the second.

[cccslater]

Forcing the override has not worked, commands still do not rise up the suggestion list. I'm not sure how to inspect minibuffer-history-variable while the minibuffer is open. If I M-X so that the vertico minibuffer appears, doing M-: to evaluate minibuffer-history-variable closes the minibuffer.

…

On Wed, 29 Jul 2026 at 08:06, Serge Yudin ***@***.***> wrote: Thanks, that narrows it to execute-extended-command / extended-command-history, not file completion. One detail I should have made clearer: Vertico's normal default is vertico-sort-history-length-alpha, and vertico-sort--history reads the active minibuffer-history-variable, so extended-command-history is the right history variable for M-x. However, Vertico also respects a completion metadata display-sort-function before vertico-sort-function. If the command/category supplies or inherits another display sort, changing only vertico-sort-function may not visibly change M-x. The quick test I would try is to force the override only for M-x: (use-package vertico :custom (vertico-multiform-commands '((execute-extended-command (vertico-sort-override-function . vertico-sort-history-length-alpha)))) :init (vertico-mode) (vertico-multiform-mode)) Then run one uncommon command through M-x, open M-x again, and check with the same prefix. If it moves up with vertico-sort-override-function, the history is fine and the missing piece was another sort function taking precedence. If it still does not move, the next thing to inspect while the M-x minibuffer is open is: minibuffer-history-variableextended-command-history The first should be extended-command-history, and the command name should appear near the front of the second. — Reply to this email directly, view it on GitHub <#677?email_source=notifications&email_token=BKUDSI7WNR6OAUGPBFSCU635HGO7XA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGIZTIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17823418>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKUDSI7ISCG5RXSSKV2Z7UD5HGO7XAVCNFSNUABIKJSXA33TNF2G64TZHMZTKMZXHA3DCMRRHNCGS43DOVZXG2LPNY5TCMBVGAYDGNRXUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKUDSI3LYUTSVGQWXGIBAQD5HGO7XA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGIZTIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BKUDSI7SS7FRS56YWCQ7JJ35HGO7XA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZYGIZTIMJYUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[cccslater]

The damn thing's fixed itself! Thanks so much for your help @yudin-s but I think it was a system update that fixed it 😅