Emacs 29.0.60 running on Windows 10 with Msys2 and Git for Windows.

I'm trying out the consult package, particularly functions such as consult-grep and consult-man, and I'm finding that I apparently don't know how to use them. After starting emacs with emacs -q, I first execute

(require 'package)
(setq package-enable-at-startup nil)
(add-to-list 'package-archives
             '("melpa" . "https://melpa.org/packages/"))
(add-to-list 'package-archives
             '("org" . "http://orgmode.org/elpa/"))
(when (not package-archive-contents)

to tell emacs where to find packages. Then, in the scratch buffer, I execute

(require 'consult)

Now I do M-x consult-grep and in the minibuffer I get

Grep (Project .emacs.d): #

Typing anything, including .*, after # and hitting return results in

Grep (Project .emacs.d): #.* [No match]

The grep command emacs finds (if it's calling grep at all) is the one from Git for Windows,

(executable-find "grep")

M-x grep works just fine. Is there configuration that I'm missing, or does consult have trouble on Windows, or what?

  • emacs.stackexchange.com/tags/elisp/info
    – Drew
    Apr 20, 2023 at 21:17
  • Have you also tried consult-ripgrep (it require to have ripgrep installed on your system). It works perfectly on my system (much better than grep / consult-grep. But I'm on GNU/LInux Arch.
    – crocefisso
    Apr 20, 2023 at 22:30

2 Answers 2


Here is my config which works well on my system (GNU Linux Arch, Emacs 28.2). use-package is installed by default on Emacs 29 (below 29 you have to install use-package manually). It should work on Windows if grep or ripgrep are installed properly (I remember it working on my Windows 10).

Package Management

Emacs Package Repositories

(require 'package)
(setq package-archives
   '(("melpa" . "https://melpa.org/packages/")
     ("elp" . "https://elpa.gnu.org/packages/")
     ("gnu-devel" . "https://elpa.gnu.org/devel/")
     ("nongnu" . "https://elpa.nongnu.org/nongnu/")

Package config tool (use-package)

Package installation

  • Auto install all packages called by use-package
(require 'use-package-ensure)
(setq use-package-always-ensure t)

Package update

  • Keep packages called by use-package automatically updated
(use-package auto-package-update
  (setq auto-package-update-delete-old-versions t)
  (setq auto-package-update-hide-results t)



(use-package consult
  (define-prefix-command 'Consult)
  (global-set-key (kbd "C-c s") 'Consult)
  ("C-f" . consult-line)
  ("C-c s f" . consult-find)
  ("C-c s g" . consult-grep)
  ("C-c s l" . consult-line)
  ("C-c s L" . consult-line-multi)
  ("C-c s k" . consult-keep-lines)
  ("C-c s r" . consult-ripgrep)
  ("C-c s u" . consult-focus-lines)
  (setq consult-narrow-key "<"))

Note: the search is performed on the directory (and sub-directories) where the buffer from where you launch the command is located.

  • My init.el file already uses use-package, although I don't update automatically as you do. I prefer to do it manually. I just did that through package-list-packages. No difference; I still see the same behavior. I posted the results from emacs -q to ensure that no other packages were messing things up. Apr 20, 2023 at 23:29
  • I just tried consult-git-grep, which works. Go figure. Apr 20, 2023 at 23:30
  • I just installed ripgrep; turns out consult-ripgrep works, too. But... consult-man, consult-find, and consult-locate all exhibit the same broken behavior. Apr 20, 2023 at 23:40
  • Probably not related to emacs or consult, but to how Windows handles GNU CLIs (like find).
    – crocefisso
    Apr 21, 2023 at 0:03

The problem seems to lie in competing executables in Git for Windows, MSYS2, and MinGW. I followed this advice from help-gnu-emacs to remove all MSYS2 executables from PATH and exec-path. An except from the post:

Completely segregate MSYS2 from the native Windows applications. Don't add the MSYS2 bin directory to your system-wide Path, and have Path only reference directories with native Windows and MinGW executables.

If you need some Unix application to be callable from Emacs, always try to find a native Windows port of it; do NOT be tempted to install an MSYS2 port. (Note that the MSYS2 project distributes both MSYS2 ports and MinGW64 ports, so you need to be aware of what you install. Unfortunately, some packages exist only as MSYS2 apps, because no one ported them to MinGW.)

Now consult-grep works as advertised. Unfortunately, however, MinGW does not provide man, find, or locate; those executables exist only in MSYS2.

One other fix was required: The complete path to the Git for Windows executable has to be specified, as follows

(defvar my-git-dir "C:\\Users\\rdprice\\Apps\\Git\\bin")
(defvar my-git-executable (expand-file-name "git.exe" my-git-dir))
(setq vc-git-program my-git-executable)

Including a path to git in exec-path would pick up other MSYS2 or Git For Windows executables, so all you can do is just point emacs directly to git.exe.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.