GNU ELPA - embark-consult

You can think of embark-act as a keyboard-based version of a right-click contextual menu. The embark-act command (which you should bind to a convenient key), acts as a prefix for a keymap offering you relevant actions to use on a target determined by the context:

• In the minibuffer, the target is the current top completion candidate.
• In the *Completions* buffer the target is the completion at point.
• In a regular buffer, the target is the region if active, or else the file, symbol, URL, s-expression or defun at point.

Multiple targets can be present at the same location and you can cycle between them by repeating the embark-act key binding. The type of actions offered depend on the type of the target. Here is a sample of a few of the actions offered in the default configuration:

• For files you get offered actions like deleting, copying, renaming, visiting in another window, running a shell command on the file, etc.
• For buffers the actions include switching to or killing the buffer.
• For package names the actions include installing, removing or visiting the homepage.
• For Emacs Lisp symbols the actions include finding the definition, looking up documentation, evaluating (which for a variable immediately shows the value, but for a function lets you pass it some arguments first). There are some actions specific to variables, such as setting the value directly or though the customize system, and some actions specific to commands, such as binding it to a key.

By default when you use embark-act if you don't immediately select an action, after a short delay Embark will pop up a buffer showing a list of actions and their corresponding key bindings. If you are using embark-act outside the minibuffer, Embark will also highlight the current target. These behaviors are configurable via the variable embark-indicators. Instead of selecting an action via its key binding, you can select it by name with completion by typing C-h after embark-act.

Everything is easily configurable: determining the current target, classifying it, and deciding which actions are offered for each type in the classification. The above introduction just mentions part of the default configuration.

Configuring which actions are offered for a type is particularly easy and requires no programming: the variable embark-keymap-alist associates target types with variables containing keymaps, and those keymaps containing bindings for the actions. (To examine the available categories and their associated keymaps, you can use C-h v embark-keymap-alist or customize that variable.) For example, in the default configuration the type file is associated with the symbol embark-file-map. That symbol names a keymap with single-letter key bindings for common Emacs file commands, for instance c is bound to copy-file. This means that if you are in the minibuffer after running a command that prompts for a file, such as find-file or rename-file, you can copy a file by running embark-act and then pressing c.

These action keymaps are very convenient but not strictly necessary when using embark-act: you can use any command that reads from the minibuffer as an action and the target of the action will be inserted at the first minibuffer prompt. After running embark-act all of your key bindings and even execute-extended-command can be used to run a command. For example, if you want to replace all occurrences of the symbol at point, just use M-% as the action, there is no need to bind query-replace in one of Embark's keymaps. Also, those action keymaps are normal Emacs keymaps and you should feel free to bind in them whatever commands you find useful as actions and want to be available through convenient bindings.

The actions in embark-general-map are available no matter what type of completion you are in the middle of. By default this includes bindings to save the current candidate in the kill ring and to insert the current candidate in the previously selected buffer (the buffer that was current when you executed a command that opened up the minibuffer).

Emacs's minibuffer completion system includes metadata indicating the category of what is being completed. For example, find-file's metadata indicates a category of file and switch-to-buffer's metadata indicates a category of buffer. Embark has the related notion of the type of a target for actions, and by default when category metadata is present it is taken to be the type of minibuffer completion candidates when used as targets. Emacs commands often do not set useful category metadata so the Marginalia package, which supplies this missing metadata, is highly recommended for use with Embark.

Embark's default configuration has actions for the following target types: files, buffers, symbols, packages, URLs, bookmarks, and as a somewhat special case, actions for when the region is active. You can read about the default actions and their key bindings on the GitHub project wiki.

Embark has a notion of default action for a target:

• If the target is a minibuffer completion candidate, then the default action is whatever command opened the minibuffer in the first place. For example if you run kill-buffer, then the default action will be to kill buffers.
• If the target comes from a regular buffer (i.e., not a minibuffer), then the default action is whatever is bound to RET in the keymap of actions for that type of target. For example, in Embark's default configuration for a URL found at point the default action is browse-url, because RET is bound to browse-url in the embark-url-map keymap.

To run the default action you can press RET after running embark-act. Note that if there are several different targets at a given location, each has its own default action, so first cycle to the target you want and then press RET to run the corresponding default action.

There is also embark-dwim which runs the default action for the first target found. It's pretty handy in non-minibuffer buffers: with Embark's default configuration it will:

• Open the file at point.
• Open the URL at point in a web browser (using the browse-url command).
• Compose a new email to the email address at point.
• In an Emacs Lisp buffer, if point is on an opening parenthesis or right after a closing one, it will evaluate the corresponding expression.
• Go to the definition of an Emacs Lisp function, variable or macro at point.
• Find the file corresponding to an Emacs Lisp library at point.

Besides acting individually on targets, Embark lets you work collectively on a set of target candidates. For example, while you are in the minibuffer the candidates are simply the possible completions of your input. Embark provides three main commands to work on candidate sets:

• The embark-act-all command runs the same action on each of the current candidates. It is just like using embark-act on each candidate in turn. (Because you can easily act on many more candidates than you meant to, by default Embark asks you to confirm uses of embark-act-all; you can turn this off by setting the user option embark-confirm-act-all to nil.)

• The embark-collect command produces a buffer listing all the current candidates, for you to peruse and run actions on at your leisure. The candidates are displayed as a list showing additional annotations. If any of the candidates contain newlines, then horizontal lines are used to separate candidates.

  The Embark Collect buffer is somewhat "dired-like": you can select and deselect candidates through embark-select (available as an action in embark-act, bound to SPC; but you could also give it a global key binding). In an Embark Collect buffer embark-act is bound to a and embark-act-all is bound to A; embark-act-all will act on all currently marked candidates if there any, and will act on all candidates if none are marked. In particular, this means that a SPC will toggle whether the candidate at point is selected, and A SPC will select all candidates if none are selected, or deselect all selected candidates if there are some.

• The embark-export command tries to open a buffer in an appropriate major mode for the set of candidates. If the candidates are files export produces a Dired buffer; if they are buffers, you get an Ibuffer buffer; and if they are packages you get a buffer in package menu mode.

  If you use the grepping commands from the Consult package, consult-grep, consult-git-grep or consult-ripgrep, then you should install the embark-consult package, which adds support for exporting a list of grep results to an honest grep-mode buffer, on which you can even use wgrep if you wish.

When in doubt choosing between exporting and collecting, a good rule of thumb is to always prefer embark-export since when an exporter to a special major mode is available for a given type of target, it will be more featureful than an Embark collect buffer, and if no such exporter is configured the embark-export command falls back to the generic embark-collect.

These commands are always available as "actions" (although they do not act on just the current target but on all candidates) for embark-act and are bound to A, S (for "snapshot"), and E, respectively, in embark-general-map. This means that you do not have to bind your own key bindings for these (although you can, of course!), just a key binding for embark-act.

In Embark Collect or Embark Export buffers that were obtained by running embark-collect or embark-export from within a minibuffer completion session, g is bound to a command that restarts the completion session, that is, the command that opened the minibuffer is run again and the minibuffer contents restored. You can then interact normally with the command, perhaps editing the minibuffer contents, and, if you wish, you can rerun embark-collect or embark-export to get an updated buffer.

Embark also has the embark-become command which is useful for when you run a command, start typing at the minibuffer and realize you meant a different command. The most common case for me is that I run switch-to-buffer, start typing a buffer name and realize I haven't opened the file I had in mind yet! I'll use this situation as a running example to illustrate embark-become. When this happens I can, of course, press C-g and then run find-file and open the file, but this requires retyping the portion of the file name you already typed. This process can be streamlined with embark-become: while still in the switch-to-buffer you can run embark-become and effectively make the switch-to-buffer command become find-file for this run.

You can bind embark-become to a key in minibuffer-local-map, but it is also available as an action under the letter B (uppercase), so you don't need a binding if you already have one for embark-act. So, assuming I have embark-act bound to, say, C-., once I realize I haven't open the file I can type C-. B C-x C-f to have switch-to-buffer become find-file without losing what I have already typed in the minibuffer.

But for even more convenience, embark-become offers shorter key bindings for commands you are likely to want the current command to become. When you use embark-become it looks for the current command in all keymaps named in the list embark-become-keymaps and then activates all keymaps that contain it. For example, the default value of embark-become-keymaps contains a keymap embark-become-file+buffer-map with bindings for several commands related to files and buffers, in particular, it binds switch-to-buffer to b and find-file to f. So when I accidentally try to switch to a buffer for a file I haven't opened yet, embark-become finds that the command I ran, switch-to-buffer, is in the keymap embark-become-file+buffer-map, so it activates that keymap (and any others that also contain a binding for switch-to-buffer). The end result is that I can type C-. B f to switch to find-file.

By default, if you run embark-act and do not immediately select an action, after a short delay Embark will pop up a buffer called *Embark Actions* containing a list of available actions with their key bindings. You can scroll that buffer with the mouse of with the usual commands scroll-other-window and scroll-other-window-down (bound by default to C-M-v and C-M-S-v).

That functionality is provided by the embark-mixed-indicator, but Embark has other indicators that can provide information about the target and its type, what other targets you can cycle to, and which actions have key bindings in the action map for the current type of target. Any number of indicators can be active at once and the user option embark-indicators should be set to a list of the desired indicators.

Embark comes with the following indicators:

• embark-minimal-indicator: shows a messages in the echo area or minibuffer prompt showing the current target and the types of all targets starting with the current one.
• embark-highlight-indicator: highlights the target at point; on by default.
• embark-verbose-indicator: displays a table of actions and their key bindings in a buffer; this is not on by default, in favor of the mixed indicator described next.
• embark-mixed-indicator: starts out by behaving as the minimal indicator but after a short delay acts as the verbose indicator; this is on by default.
• embark-isearch-highlight-indicator: this only does something when the current target is the symbol at point, in which case it lazily highlights all occurrences of that symbol in the current buffer, like isearch; also on by default.

Users of the popular which-key package may prefer to use the embark-which-key-indicator from the Embark wiki. Just copy its definition from the wiki into your configuration and customize the embark-indicators user option to exclude the mixed and verbose indicators and to include embark-which-key-indicator.

If you use Vertico, there is an even easier way to get a which-key-like display that also lets you use completion to narrow down the list of alternatives, described at the end of the next section.

As an alternative to reading the list of actions in the verbose or mixed indicators (see the previous section for a description of these), you can press the embark-help-key, which is C-h by default (but you may prefer ? to free up C-h for use as a prefix) after running embark-act. Pressing the help key will prompt you for the name of an action with completion (but feel free to enter a command that is not among the offered candidates!), and will also remind you of the key bindings. You can press embark-keymap-prompter-key, which is @ by default, at the prompt and then one of the key bindings to enter the name of the corresponding action.

You may think that with the *Embark Actions* buffer popping up to remind you of the key bindings you'd never want to use completion to select an action by name, but personally I find that typing a small portion of the action name to narrow down the list of candidates feels significantly faster than visually scanning the entire list of actions.

If you find you prefer selecting actions that way, you can configure embark to always prompt you for actions by setting the variable embark-prompter to embark-completing-read-prompter.

On the other hand, you may wish to continue using key bindings for the actions you perform most often, and to use completion only to explore what further actions are available or when you've forgotten a key binding. In that case, you may prefer to use the minimal indicator, which does not pop-up an *Embark Actions* buffer at all, and to use the embark-help-key whenever you need help. This unobtrusive setup is achieved with the following configuration:

(setq embark-indicators
      '(embark-minimal-indicator  ; default is embark-mixed-indicator
	embark-highlight-indicator
	embark-isearch-highlight-indicator))

Vertico users may wish to configure a grid display for the actions and key-bindings, reminiscent of the popular package which-key, but, of course, enhanced by the use of completion to narrow the list of commands. In order to get the grid display, put the following in your Vertico configuration:

(add-to-list 'vertico-multiform-categories '(embark-keybinding grid))
(vertico-multiform-mode)

This will make the available keys be shown in a compact grid like in which-key. The vertico-multiform-mode also enables keys such as M-V, M-G, M-B, and M-U for manually switching between layouts in Vertico buffers.

By default, if you call embark-act from the minibuffer it quits the minibuffer after performing the action. You can change this by setting the user option embark-quit-after-action to nil. Having embark-act not quit the minibuffer can be useful to turn commands into little "thing managers". For example, you can use find-file as a little file manager or describe-package as a little package manager: you can run those commands, perform a series of actions, and then quit the command.

If you want to control the quitting behavior in a fine-grained manner depending on the action, you can set embark-quit-after-action to an alist, associating commands to either t for quitting or nil for not quitting. When using an alist, you can use the special key t to specify the default behavior. For example, to specify that by default actions should not quit the minibuffer but that using kill-buffer as an action should quit, you can use the following configuration:

(setq embark-quit-after-action '((kill-buffer . t) (t . nil)))

The variable embark-quit-after-action only specifies a default, that is, it only controls whether or not embark-act quits the minibuffer when you call it without a prefix argument, and you can select the opposite behavior to what the variable says by calling embark-act with C-u. Also note that both the variable embark-quit-after-action and C-u have no effect when you call embark-act outside the minibuffer.

If you find yourself using the quitting and non-quitting variants of embark-act about equally often, independently of the action, you may prefer to simply have separate commands for them instead of a single command that you call with C-u half the time. You could, for example, keep the default exiting behavior of embark-act and define a non-quitting version as follows:

(defun embark-act-noquit ()
  "Run action but don't quit the minibuffer afterwards."
  (interactive)
  (let ((embark-quit-after-action nil))
    (embark-act)))

You can customize what happens after the target is inserted at the minibuffer prompt of an action. There are embark-target-injection-hooks, that are run by default after injecting the target into the minibuffer. The variable embark-target-injection-hooks is an alist associating commands to their setup hooks. There are two special keys: if no setup hook is specified for a given action, the hook associated to t is run; and the hook associated to :always is run regardless of the action. (This variable used to have the less explicit name of embark-setup-action-hooks, so please update your configuration.)

For example, consider using shell-command as an action during file completion. It would be useful to insert a space before the target file name and to leave the point at the beginning, so you can immediately type the shell command to run on that file. That's why in Embark's default configuration there is an entry in embark-target-injection-hooks associating shell-command to a hook that includes embark--shell-prep, a simple helper function that quotes all the spaces in the file name, inserts an extra space at the beginning of the line and leaves point to the left of it.

Now, the preparation that embark--shell-prep does would be useless if Embark did what it normally does after it inserts the target of the action at the minibuffer prompt, which is to "press RET" for you, accepting the target as is; if Embark did that for shell-command you wouldn't get a chance to type in the command to execute! That is why in Embark's default configuration the entry for shell-command in embark-target-injection-hooks also contains the function embark--allow-edit.

Embark used to have a dedicated variable embark-allow-edit-actions to which you could add commands for which Embark should forgo pressing RET for you after inserting the target. Since its effect can also be achieved via the general embark-target-injection-hooks mechanism, that variable has been removed to simplify Embark. Be sure to update your configuration; if you had something like:

(add-to-list 'embark-allow-edit-actions 'my-command)

you should replace it with:

(push 'embark--allow-edit
      (alist-get 'my-command embark-target-injection-hooks))

Also note that while you could abuse embark--allow-edit so that you have to confirm "dangerous" actions such as delete-file, it is better to implement confirmation by adding the embark--confirm function to the appropriate entry of a different hook alist, namely, embark-pre-action-hooks.

Besides embark--allow-edit, Embark comes with another function that is of general utility in action setup hooks: embark--ignore-target. Use it for commands that do prompt you in the minibuffer but for which inserting the target would be inappropriate. This is not a common situation but does occasionally arise. For example it is used by default for shell-command-on-region: that command is used as an action for region targets, and it prompts you for a shell command; you typically do not want the target, that is the contents of the region, to be entered at that prompt!

Embark has three variables, embark-pre-action-hooks, embark-post-action-hooks and embark-around-action-hooks, which are alists associating commands to hooks that should run before or after or as around advice for the command when used as an action. As with embark-target-injection-hooks, there are two special keys for the alists: t designates the default hook to run when no specific hook is specified for a command; and the hook associated to :always runs regardless.

The default values of those variables are fairly extensive, adding creature comforts to make running actions a smooth experience. Embark comes with several functions intended to be added to these hooks, and used in the default values of embark-pre-action-hooks, embark-post-action-hooks and embark-around-action-hooks.

For pre-action hooks:

embark--confirm

Prompt the user for confirmation before executing the action. This is used be default for commands deemed "dangerous", or, more accurately, hard to undo, such as delete-file and kill-buffer.

embark--unmark-target

Unmark the active region. Use this for commands you want to act on the region contents but without the region being active. The default configuration uses this function as a pre-action hook for occur and query-replace, for example, so that you can use them as actions with region targets to search the whole buffer for the text contained in the region. Without this pre-action hook using occur as an action for a region target would be pointless: it would search for the the region contents in the region, (typically, due to the details of regexps) finding only one match!

embark--beginning-of-target

Move to the beginning of the target (for targets that report bounds). This is used by default for backward motion commands such as backward-sexp, so that they don't accidentally leave you on the current target.

embark--end-of-target

Move to the end of the target. This is used similarly to the previous function, but also for commands that act on the last s-expression like eval-last-sexp. This allow you to act on an s-expression from anywhere inside it and still use eval-last-sexp as an action.

embark--xref-push-markers

Push the current location on the xref marker stack. Use this for commands that take you somewhere and for which you'd like to be able to come back to where you were using xref-pop-marker-stack. This is used by default for find-library.

For post-action hooks:

embark--restart

Restart the command currently prompting in the minibuffer, so that the list of completion candidates is updated. This is useful as a post action hook for commands that delete or rename a completion candidate; for example the default value of embark-post-action-hooks uses it for delete-file, kill-buffer, rename-file, rename-buffer, etc.

For around-action hooks:

embark--mark-target

Save existing mark and point location, mark the target and run the action. Most targets at point outside the minibuffer report which region of the buffer they correspond to (this is the information used by embark-highlight-indicator to know what portion of the buffer to highlight); this function marks that region. It is useful as an around action hook for commands that expect a region to be marked, for example, it is used by default for indent-region so that it works on s-expression targets, or for fill-region so that it works on paragraph targets.

embark--cd

Run the action with default-directory set to the directory associated to the current target. The target should be of type file, buffer, bookmark or library, and the associated directory is what you'd expect in each case.

embark--narrow-to-target

Run the action with buffer narrowed to current target. Use this as an around hook to localize the effect of actions that don't already work on just the region. In the default configuration it is used for repunctuate-sentences.

embark--save-excursion

Run the action restoring point at the end. The current default configuration doesn't use this but it is available for users.

All internal keymaps are defined with the standard helper macro defvar-keymap. For example a simple version of the file action keymap could be defined as follows:

(defvar-keymap embark-file-map
  :doc "Example keymap with a few file actions"
  :parent embark-general-map
  "d" #'delete-file
  "r" #'rename-file
  "c" #'copy-file)

These action keymaps are perfectly normal Emacs keymaps. You may want to inherit from the embark-general-map if you want to access the default Embark actions. Note that embark-collect and embark-export are also made available via embark-general-map.

It is easy to configure Embark to provide actions for new types of targets, either in the minibuffer or outside it. I present below two very detailed examples of how to do this. At several points I'll explain more than one way to proceed, typically with the easiest option first. I include the alternative options since there will be similar situations where the easiest option is not available.

Alternatively, Embark does support one other type of action: a non-interactive function of a single argument. The target is passed as argument to the function. For example:

(defun example-action-function (target)
  (message "The target was `%s'." target))

(keymap-set embark-symbol-map "X 4" #'example-action-function)

Note that normally binding non-interactive functions in a keymap is useless, since when attempting to run them using the key binding you get an error message similar to "Wrong type argument: commandp, example-action-function". In general it is more flexible to write any new Embark actions as commands, that is, as interactive functions, because that way you can also run them directly, without Embark. But there are a couple of reasons to use non-interactive functions as actions:

1. You may already have the function lying around, and it is convenient to simply reuse it.
2. For command actions the targets can only be simple string, with no text properties. For certain advanced uses you may want the action to receive a string with some text properties, or even a non-string target.

Embark comes with actions for symbols (commands, functions, variables with actions such as finding the definition, looking up the documentation, evaluating, etc.) in the embark-symbol-map keymap, and for packages (actions like install, delete, browse url, etc.) in the embark-package-keymap.

Unfortunately Embark does not automatically offers you these keymaps when relevant, because many built-in Emacs commands don't report accurate category metadata. For example, a command like describe-package, which reads a package name from the minibuffer, does not have metadata indicating this fact.

In an earlier Embark version, there were functions to supply this missing metadata, but they have been moved to Marginalia, which augments many Emacs command to report accurate category metadata. Simply activating marginalia-mode allows Embark to offer you the package and symbol actions when appropriate again. Candidate annotations in the Embark collect buffer are also provided by the Marginalia package:

• If you install Marginalia and activate marginalia-mode, Embark Collect buffers will use the Marginalia annotations automatically.
• If you don't install Marginalia, you will see only the annotations that come with Emacs (such as key bindings in M-x, or the unicode characters in C-x 8 RET).

The excellent Consult package provides many commands that use minibuffer completion, via the completing-read function; plenty of its commands can be considered enhanced versions of built-in Emacs commands, and some are completely new functionality. One common enhancement provided in all commands for which it makes sense is preview functionality, for example consult-buffer will show you a quick preview of a buffer before you actually switch to it.

If you use both Consult and Embark you should install the embark-consult package which provides integration between the two. It provides exporters for several Consult commands and also tweaks the behavior of many Consult commands when used as actions with embark-act in subtle ways that you may not even notice, but make for a smoother experience. You need only install it to get these benefits: Embark will automatically load it after Consult if found.

The embark-consult package provides the following exporters:

• You can use embark-export from consult-line, consult-outline, or consult-mark to obtain an occur-mode buffer. As with the built-in occur command you use that buffer to jump to a match and after that, you can then use next-error and previous-error to navigate to other matches. You can also press e to activate occur-edit-mode and edit the matches in place!
• You can export from any of the Consult asynchronous search commands, consult-grep, consult-git-grep, or consult-ripgrep to get a grep-mode buffer. Here too you can use next-error and previous-error to navigate among matches, and, if you install the wgrep package, you can use it to edit the matches in place.

In both cases, pressing g will rerun the Consult command you had exported from and re-enter the input you had typed (which is similar to reverting but a little more flexible). You can then proceed to re-export if that's what you want, but you can also edit the input changing the search terms or simply cancel if you see you are done with that search.

The embark-consult also contains some candidates collectors that allow you to run embark-live to get a live-updating table of contents for your buffer:

• embark-consult-outline-candidates produces the outline headings of the current buffer, using consult-outline.
• embark-consult-imenu-candidates produces the imenu items of the current buffer, using consult-imenu.
• embark-consult-imenu-or-outline-candidates is a simple combination of the two previous functions: it produces imenu items in buffers deriving from prog-mode and otherwise outline headings.

The way to configure embark-live (or embark-collect and embark-export for that matter) to use one of these function is to add it at the end of the embark-candidate-collectors list. The embark-consult package by default adds the last one, which seems to be the most sensible default.

Besides those exporters and candidate collectors, the embark-consult package provides many subtle tweaks and small integrations between Embark and Consult. Some examples are:

• When used as actions, the asynchronous search commands will search only the files associated to the targets: if the targets are files, it searches those files; for buffers it will search either the associated file if there is one, else all files in the buffer's default-directory; for bookmarks it will search the file they point to, same for Emacs Lisp libraries. This is particularly powerful when using embark-act-all to act on multiple files at once, for example you can use consult-find to search among file names and then embark-act-all and consult-grep to search within the matching files.
  • For all other target types, those that do not have a sensible notion of associated file, a Consult search command (asynchronous or not) will search for the text of the target but leave the minibuffer open so you can interact with the Consult command.
• consult-imenu will search for the target and take you directly to the location if it matches a unique imenu entry, otherwise it will leave the minibuffer open so you can navigate among the matches.