See discussion in oantolin/embark#54

I like the new consult-after-jump-function but think it should behave the same as xref. That uses a hook not a function and defaults to both recenter and pulsing which is nice. I've modified xref to use reposition-window instead of recenter and think it would be great if consult either just used xref-after-jump-hook or set the default value of a consult-after-jump-hook to be the value of xref-after-jump-hook so I only have to set it once.

It would be nice if consult had functions for browsing their respective history files.

Thanks for the great package. Is there any plan to implement search functions like consult-rg/ag/grep?

I've tested enabling consult-annotate-mode by adding it to selectrum-prescient-mode-hook, but it still sets consult--selectrum-highlight-candidates to the default highlighting function.

I need to manually re-set it to #'selectrum-prescient--highlight for the highlighting to work correctly. Filtering still works correctly.

Is there a better way to load these packages?

Right now there are two implementations:

• consult--buffer-selectrum has narrowing support
• consult--buffer-default does not have narrowing support

@hmelman Pinging you since you mentioned the consult-line prompt before. I just added a preview command for goto-line called consult-goto-line. The question is now if the two commands should be renamed, but I am not overly eager to break existing setups and consult-line has been mentioned quite often already. Maybe it makes sense to consider this as soon as some other grep-based search command is added.

• consult-line -> consult-line-search
• consult-goto-line -> consult-line
• consult-grep, consult-project-search, ...?

Hi,

first of all thanks for this package and the effort put into keeping selectrum as simple as possible.

One thing to consider is faces definition in defcustoms. See the discussion with @protesilaos here: https://gitlab.com/protesilaos/modus-themes/-/issues/123

You should check with him a possibly better approach.

consult-line-history, consult-mark-history, consult-outline-history record histories including the line number prefixes, which are there for disambiguation of the lines. The history becomes useless after moving lines. There are two options:

1. Strip the prefix and add manually via add-to-history. However it seems that selectrum will always add to the minibuffer-history if :history is nil (See radian-software/selectrum#246). Stripping the prefix will lead to multiple candidates in case there are duplicate lines. Therefore the history again becomes less useful in jumping back and forth.
2. Cleanup the history before doing the completing-read. Only strip the prefix of the history elements which got lost, e.g., where the line in the buffer is not consistent with the prefixed line in the history. We have to ensure that only the prefix part is stripped (mark the prefix with a property?)

Ideas? Any preferences?

Hello,
i try to use completion-in-region after read the lines in documentation.
But i think, that i do not understand or use it correct.
I always get the following error after call it from minibuffer.

command-execute: Wrong type argument: commandp, selectrum-completion-in-region
Regards
Poul

The docstring of consult-buffer says it's an "Enhanced switch-to-buffer-other-window" and it should say "Enhanced switch-to-buffer"

If I initiate a search with consult-line with live previews enabled and then hit C-g to cancel it, the last line highlighted by the live preview stays highlighted until I initiate another consult-line. Is this an unexpected behavior?

I'd assume that this happens to other commands besides consult-line, but I haven't tried yet.

Hello, I'm very new to emacs, so it's likely I'm doing something incorrectly. That said, I tried out this package this morning using the example configuration in the readme, with the final line uncommented, and noticed that the annotations do not appear when I start up emacs and enter M-x. I can get them to appear if I run a command like consult-line and then enter M-x. Do I have something configured incorrectly?

Separately, I noticed that consult-apropos does not include key bindings like the default does. As a new user, this seems a little regrettable.

@s-kostyaev You contributed #20. Now I wonder if the isearch integration could not be improved even more. Would it make sense for consult-line to overwrite the isearch string always? Or maybe it would make more sense to rename consult-line-from-isearch to consult-isearch, which is just consult-line with taking the isearch string as initial input and overwriting the isearch string on the go such that one can switch seemlessly between consult-isearch and isearch. Does that make sense?

Hi,

I've just updated consult, and I am using it with selectrum (which I've just updated as well). When I am trying to use consult-history in shell-mode, after selecting the first candidate (cd in my case) I get this:

Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 3)
  #f(compiled-function (_ x) #<bytecode 0xad388804d736d71>)("" (#("cd" 0 2 (fontified t)) "emacs-q" "sudo apt update" "ebuild " "sysup " "clojure -M:outdated")
  #f(compiled-function (arg1 arg2 &rest rest) "Simplified completing read function.\n\nPROMPT is the string to prompt with.\nCANDIDATES is the candidate list or alist.\nPREDICATE is a filter function for the candidates.\nREQUIRE-MATCH equals t means that an exact match is required.\nHISTORY is the symbol of the history variable.\nHISTORY-TYPE must be 'input if the input string should be saved in the history.\nDEFAULT is the default input.\nCATEGORY is the completion category.\nSORT should be set to nil if the candidates are already sorted.\nLOOKUP is a function which is applied to the result.\nINITIAL is initial input.\nDEFAULT-TOP must be nil if the default candidate should not be moved to the top.\nPREVIEW is a preview function.\nNARROW is an alist of narrowing prefix strings and description." #<bytecode 0x119e3da330ad7d3e>)("History: " (#("cd" 0 2 (fontified t)) "emacs-q" "sudo apt update" "ebuild " "sysup " "clojure -M:outdated" ...) :history t :sort nil)
  consult-history()
  funcall-interactively(consult-history)
  call-interactively(consult-history nil nil)
  command-execute(consult-history)

Interestingly enough, I cannot reproduce this from emacs -Q. But I didn't change anything w/r/t consult or selectrum in my configuration.

Am I missing something? Feel free to ask for more information or tests on my side.

Allows prefix and suffix annotations in Emacs 28. This will help us avoid the 'display prefix hack. See also #4.

Hi,

First of all, thanks for the package, it's quite nice.

When I try to use embark-occur with consult-line candidates I get a new buffer with the candidates, however they are not "clickable" and do not allow to jump to the results. I tried the same with the original code from the selectrum wiki and the behavior is the same.

You can see the concerned config portion here https://github.com/mpenet/emax/blob/master/init.el#L327-L352.

I have the feeling we might need a custom embark-candidate-collectors fn

This is just a suggestion:

Would you consider adding a consult-flycheck command that would cycle through the entries in flycheck-list-errors, with jump to selected file at error point?

Can we add some category to consult-line? I would like to be able to change completion style for consult-line without changing the default one.

(use-package consult
  :straight t
  :bind
  ("C-x b" . consult-buffer)
  ("M-y" . consult-yank-pop))

This is the error

Debugger entered--Lisp error: (error "Could not find package consult in recipe repositor...")
  error("Could not find package %S in recipe repositories: ..." consult (org-elpa melpa gnu-elpa-mirror emacsmirror-mirror))

Hi! Thanks for this cool project.

There is no way to provide initial input into consult--read. So there is no way to implement consult-line-from-isearch or consult-line-symbol-at-point. It can be very useful. Also, after this change we can add initial input as consult-line optional argument (like swiper does). This makes implementation that kind of functions trivial.

Steps to reproduce

GNU Emacs 27.1
consult: b5cbc61

$ emacs -q
(require 'consult)
(setq completion-in-region-function 'consult-completion-in-region)

In eshell, run:

touch foobar
touch football
cat foo<TAB>

Expected

I'm prompted "Completion: foo|" where | indicates where I expect point to be.

Actual

I'm prompted "Completion: |foo".

This is a problem because I then type "b" (to try to complete "foob" to "foobar"), the minibuffer actually shows "bfoo" which fails to complete.

If the headline you choose for consult outline is folded, consult outline does not do what I would expect. If I choose the headline, I'd expect it to unfold the minimal amount necessary to view the headline. Instead, I'm taken to the top level headline. I can create a pull request on this as I do have code that worked for me to fix this.

use-package comes with imenu support: if you (setq use-package-enable-imenu-support t), then imenu will list all the use-package forms in the current buffer. You can add (?p . "Packages") to the emacs-lisp-mode alist in consult-imenu-narrow to support this.

Of course this is easy enough for each person to configure for themselves, but I thought that since use-package is pretty popular, it might be worth supporting out the box.

Hi,

I was wondering if there were any plans to add this package to GNU ELPA? It seems like it would be a good fit.

While the current line is highlighted, the matched strings are not. The current completion style or the selectrum highlight filter should be used to obtain the highlights.

Ping @okamsn

• Hiding counter and default format for commands which do not use the counter
• DONE Please recheck the comments in 6e4b699

Hi, firstly thanks for your awesome work here! I'm excited to be trying out consult for the first time, and just copy-pasted the suggested use-package sexps into my config files. However I'm using straight.el, and the sexps for consult-selectrum and -flycheck didn't work because straight.el didn't know to get them from the consult package. Adding :straight consult fixed this:

(use-package consult-selectrum
  :straight consult
  :demand t)

;; Install the consult-flycheck command.
(use-package consult-flycheck
  :straight consult
  :bind (:map flycheck-command-map
         ("!" . consult-flycheck)))

so I'd suggest mentioning that in the README.

@oantolin When using consult-line the candidates are first nicely sorted by line, but as as soon as I start filtering, the order gets messed up. I only see this with icomplete and not with selectrum. Do you also have this and is this expected? I am using the identity as cycle-sort-function and display-sort-function in consult--read as you are probably aware.

Currently neither minibuffer-force-complete nor tab cycling updates the preview.

For minibuffer-force-complete that's just a matter of advising it too, but tab cycling is tricky. The way tab cycling is implemented is that TAB is temporarily redefined via set-transient-map, and the command it is redefined to be is a lambda, not a named function.

The functions should be compatible with any completion-system based on the standard Emacs API, e.g., icomplete and selectrum.

Maybe helm and ivy should also be mentioned so people don't get the impression this wouldn't work for them. AFAIK helm fully supports the API, ivy (last time I checked) also supports it but doesn't support annotations or sorting defined via completion metadata.

After using consult-theme, I couldn't keep using selectrum because of an error in selectrum--minibuffer-post-command-hook saying that maximum lisp nesting exceeded.

When I try and use consult-line in an org file, I get this error:

Error during redisplay: (jit-lock-function 228) signaled (error "Invalid face" font-lock-comment-face org-block)
face-attribute: Invalid face: font-lock-comment-face, org-blockError during redisplay: (jit-lock-function 228) signaled (error "Invalid face" font-lock-comment-face org-block)

I have custom fonts set for font-lock-comment-face with (set-face-attribute), but I don't modify the org-block face anywhere. If I repeat the command a few times, it will eventually work.

I'm running on Emacs27 on linux. Updated to the latest consult (3471514) at the time of writing and the issue still occurs. Org version 9.4.2.

Thanks for your help!

Only already opened buffers are previewed. consult does not open files yet. It is also questionable if we want that. If we implement this it must be ensured that every file buffer which has been opened is closed again after preview.

I believe an earlier version of consult-buffer allowed narrowing to ephemeral/uninteresting buffers whose names start with a space.

Is there a reason this functionality was taken away? And if I'm mistaken (or confusing it with the function from the selectrum-wiki) can it be included in consult-buffer.

First of all, great stuff! I'd been using the selectrum wiki commands with some of my own modifications and this package has totally replaced all of that cruft I included.

On to the actual issue: I see in the screenshot showing M-x with consult-annotate-mode enabled that keybindings are shown as part of the annotations. But I don't see any such keybindings when this package is enabled.

Thanks @clemera.

This was one of the first commands I wrote and needs a bit of rechecking. Also there is no preview. See #8

Reading through consult a few of the prompt texts struck me as a litle off. I made a pass through the commands and have some suggestions to improve them. This is all minor stuff.

First the simple ones, just the changing the prompt text.

1. Imenu.el commands refer to "index item"s so I think consult-imenu should prompt "Go to index item: "

2. consult--yank-read just prompts with "Ring: " which is a little obtuse, I think "Yank text: " is clearer.

3. consult-line was one of the first that seemed off to me. It prompts now with "Go to line: " and at first I was thinking it was asking for a line number. "Go to line containing: " is clearer, but doesn't match with other things. I'm not completely satisfied with this suggestion, and as it stands it's consistent with other prompts, but I think it needs something because lines are so typically described by their number.

These I suggest changing the command name as well.

4. consult-minor-mode-menu should just be consult-minor-mode the way consult-theme doesn't have "-menu" appended.

5. consult-outline currently prompts with "Go to heading: ". I think the command name should match the prompt and "heading" is more accurate. Outline mode commands say "heading" but of course they also begin with "outline". I think using both is best. If not, I think both the command name and prompt should use the same term and I prefer heading over outline since that what the list of candidates is. So consult-outline-heading prompting as "Go to outline heading: "

See the comment by @clemera #1 (comment).
Not fixing this yet, because I am unhappy with the selectrum api, see radian-software/selectrum#242 and radian-software/selectrum#243.

@oantolin and I have some plans to factor out annotations into some separate package oantolin/embark#41, since there is overlap between embark annotations and the consult-annotate-mode. Ideally there won't be any change in functionality.

Hi,

just an idea maybe worth looking into. Also, there is insert-char-preview that offers a more generic approach than counsel-unicode.

What the title says. I wanted to test #26 (comment)
I ran M-x straight-pull-all. Then when it was done, I ran consult-line and saw the old behavior (e.g. go to start of the line). I quickly opened consult.el, and saw no versioning! No need to tell you how important version numbers are.
I solved the issue, but I still think that version numbers would be a great idea.

related #7

The default emacs theme does not seem to be considered a "theme" in the sense that it is not an available option for load-theme. So after using a custom theme if you want to switch back to the default theme you need to call disable-theme. Easy enough, but arguably rather intuitive as it is the only theme for which you have to do that. theme-looper had the clever idea of including the default theme as an option (called *default*) in it's wrapper around load-theme called theme-looper-select-theme so that you can switch to the default theme as you would with any other theme. It's worth considering doing the same thing for consult-theme.

todo/open for discussion

Seems feature complete? ;)

done

• consult-info dynamic info search based on consult--dynamic-collection. See #634 and #128 for an earlier draft. The wiki contains a version of consult-info too.
• More efficient consult-line-multi reimplementation based on consult--dynamic-collection (See #644)
• consult-lsp, available as a separate package
• consult-yasnippet, available as a separate package
• consult-eglot, available as a separate package
• consult-org-clock-in, consult-org-heading, consult-org-agenda (See #276)
• Add narrowing to consult-outline by using the outline-level function (#277)
• consult-xref show function, see xref branch and #216 implemented
• consult-outline extension for shell prompts (originally consult-prompt which gives a list of all shell/terminal prompts), see #130 discussion. Instead of implementing an extension/extra command, set outline-regexp=eshell-prompt-regexp in the eshell-mode-hook as documented in the wiki.
• consult-focus-lines which uses overlays in contrast to consult-keep-lines implemented
• consult-keep-lines with preview and filtering using the completion-style implemented
• consult-kmacro implemented
• consult-completion-at-point implemented
• consult-flycheck (see #51, cycle through errors with preview) implemented
• consult-imenu implemented
• consult-flymake implemented
• consult-global-mark support for global mark ring, ideally consult-mark should show both local and global marks and via l and g narrowing via can either narrow to the local ring or the global one implemented
• consult-major-command list commands corresponding to current major mode, similar to amx-major-mode-commands implemented as consult-mode-command
• consult-ripgrep (see #68, consider using xref facilities, xref-search-program, xref-matches-in-files) See also https://github.com/travitch/completing-read-xref.el implemented
• consult-match jump to matches in the buffer, needs dynamic recomputation of candidates, similar to swiper-isearch, implemented as consult-line-multi.

rejected

• transient menu for consult-ripgrep/grep/... (See #170 for a prototype, #238). It would be great to have a transient interface implemented as a separate package, based on consult-ripgrep etc.
• consult-kill-lines and consult-copy-lines variants of kill/copy-matching-lines in the style of consult-focus-lines (see #6 (comment))
• consult-org-capture (See #32 for a draft). I think capturing is better solved by access keys than by completing-read to quickly jump to a capture template.
• consult-link (collect all shr/eww/org/buttons links in a buffer and present them for completion, see also oantolin/embark#95 - this gives us an embark target collector for free). Maybe this functionality should not be added here - it would be a better fit for the link-hint package. See also ffap-menu.
• Evil-specific commands, should be maintained in a separate repository (see also evil-collection, https://github.com/emacs-evil/evil-collection/blob/master/modes/consult/evil-collection-consult.el)
• consult-hippie hippie or dabbrev expand (see #175 for a draft) rejected, not robust, see #175 discussion for alternative ideas
• consult-fzf and async functions which keep the background process alive (see experiment #189), the problem is that fzf, fzy etc do not support a pipe-mode. Therefore we cannot use them efficiently, but this may change in the future. For now it is possible to configure consult-find-command with a pipe into fzf. See https://github.com/minad/affe
• consult-flyspell, provided by see https://github.com/d12frosted/flyspell-correct, which uses completing-read by default, see also https://github.com/raxod502/selectrum/wiki/Additional-Configuration#correcting-spelling-errors-with-flyspell-correct
• consult-flycheck/flymake/error variants which shows the lines instead of the error. This could be built in to the existing commands via C-u? out of scope, no intention to implement this as of now
• consult-color out of scope, not sufficiently useful, there are better UIs for color selection than completing-read
• consult-emoji out of scope, could be implemented on top of insert-char by modifying the minibuffer-predicate of read-char-by-name to restrict the character range, now available upstream in Emacs 29
• consult-linux-app out of scope, available as a separate package https://github.com/SebastienWae/app-launcher
• consult-help interactive search through documentation, commands in M-x and other symbols (see radian-software/selectrum#241 for the suggestion). Note that this is different from what is provided by marginalia-mode. I have an implementation in the consult-help branch, see #67. While it would be very nice, it is too slow to be useful. Maybe computing the candidates dynamically would help. not implemented, use embark collect instead for a searchable help
• Alternative to consult-help - implement generic function which allows to search through marginalia annotations, basically transforming candidates such that they also include the annotations and make them searchable. not implemented, use apropos-documentation or embark collect instead for a searchable help
• consult-binding to browse keybindings, out of scope, use embark-bindings or describe-bindings + consult-focus-lines/consult-keep-lines

Contributions and new proposals are welcome. Note that Consult focuses on Emacs core functionality. Integrations with external packages should be provided by external packages, e.g., consult-lsp, consult-notmuch, ...

In many cases it is sufficient to use the built-in Emacs completing-read functionality. Therefore dedicated consult-* packages may not be necessary.

In principle from the side of consult everything is there. But Icomplete simply does not implement this. I have not yet found a point where I could hook into to make it work until there is upstream support.

See also oantolin/icomplete-vertical#16

The problem is the call to (mark t) in the :preview form, which returns nil. I guess changing (min (point) (mark t)) to (if (mark t) (min (point) (mark t)) (point)) should fix that, but maybe there's a more elegant way.

consult-buffer-other{window,frame} don't show the current buffer in the candidate list, but switch-to-buffer-other-{window,frame} do. This is convenient when wanting to view the same buffer in multiple places.

@clemera There is another maybe more interesting question I would like to hear your opinion on. Can we somehow support actions in consult? You are probably using embark? I looked into it but I think it is quite complex and I had hopes for something simpler. A lot of the complexity is due to the automatic detection mechanism. I don't know what other edge cases embark covers but the basic idea seems relatively simple to me.

Small example:

• There are two action functions which must be wrapped (action-default, action-switch-to-buffer-other-window)
• This wrapping could be done automatically when generating the action map (define-action-map)
• The test function adds the action keymap temporarily as a prefix map to the minibuffer-local-map

;;;  -*- lexical-binding: t -*-

(defvar action-default-command nil)

(defun define-action (name cmd)
  `(defun ,name ()
     (interactive)
     (let ((cand (selectrum-get-current-candidate)) ;; selectrum-get-current-candidates
           (orig-inhibit-message inhibit-message))
       (run-at-time 0 nil (lambda ()
                            (setq inhibit-message orig-inhibit-message)
                            (letrec ((hook (lambda ()
                                             (setq minibuffer-setup-hook (delq hook minibuffer-setup-hook))
                                             (delete-minibuffer-contents)
                                             (insert cand))))
                              (push hook minibuffer-setup-hook))
                            (push 13 unread-command-events)
                            (call-interactively
                                (setq this-command
                                      ,(if (eq cmd :default)
                                           'action-default-command
                                         `#',cmd)))))
       (setq inhibit-message t)
       (top-level))))

(defmacro define-action-map (name &rest bindings)
  `(progn
     ,@(mapcar (pcase-lambda (`(,_ ,cmd))
                 (define-action (intern (format "action-%s-%s" name cmd))  cmd))
               bindings)
     (defvar ,name
       (let ((map (make-sparse-keymap)))
         ,@(mapcar (pcase-lambda (`(,key ,cmd))
                     `(define-key map ,(kbd key) #',(intern (format "action-%s-%s" name cmd))))
                   bindings)
         map))
     (fset ',name ,name)))

(define-action-map buffer-actions
  ("RET" :default)
  ("o" switch-to-buffer-other-window)
  ("C-g" keyboard-quit))

(defun test ()
  (interactive)
  (define-key minibuffer-local-map [C-return] #'buffer-actions)
  (unwind-protect
      (call-interactively (setq action-default-command 'switch-to-buffer))
    (define-key minibuffer-local-map [C-return] nil)))

This somehow seems to work. The downside is that each command must be equipped with actions using such a unwind-protect-keymap dance. Furthermore I don't see how I can programmatically equip functions with actions, for example if I would want to hard-code that find-file gets the file-action-map etc. I don't think this is easily possible using the advice mechanism since completion can also happen in the interactive code, which is executed before the call. This seems to be one of the reasons why embark goes with the auto-detection? The other is probably that embark avoids a lot of manual work by auto-detecting. But I would not be too unhappy if I have to manually associate commands with keymaps. At least if it is possible to do with a oneliner e.g., (add-actions find-file file-actions). If it is not a oneliner, we are back to the counsel approach since we have to write manual wrappers for each and every function.

What do you think? Any ideas? Should I rather embrace embark? Keep actions out of this?