Command wishlist

[minad]

todo/open for discussion

Seems feature complete? ;)

done

• consult-info dynamic info search based on consult--dynamic-collection. See Info manual commands needed #634 and Add a ‘consult-info’ command. #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 More efficient consult-line-multi #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 consult-org-heading, consult-org-agenda #276)
• Add narrowing to consult-outline by using the outline-level function (Add narrowing to consult-outline #277)
• consult-xref show function, see xref branch and Add consult-xref. #216 implemented
• consult-outline extension for shell prompts (originally consult-prompt which gives a list of all shell/terminal prompts), see consult-prompt UI #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 consult-flycheck #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 [WIP] Add first implementation of consult-search #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 Dirty hack to test transient popup with consult-grep #170 for a prototype, Command flag toggling support for consult--async-command #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 Command wishlist #6 (comment))
• consult-org-capture (See Add org capture function #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 Action, target finder, target collector and exporter wishlist 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 First draft: consult-hippie #175 for a draft) rejected, not robust, see First draft: consult-hippie #175 discussion for alternative ideas
• consult-fzf and async functions which keep the background process alive (see experiment experiment: async find #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 Search in functions and their descriptions 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 implement consult-help command which allows to search all documentation strings #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.

[doolio]

An equivalent to counsel-linux-app would be great.

[minad]

@doolio For now I am focused on the core commands, which are Emacs related and uncontroversial. But certainly some of the others like accessing linux apps could be added as well. Since I am not experienced with ivy, I would love some kind of usage statistics or experience reports regarding the most used commands. For example there is counsel-rythmbox which I doubt to be useful for many people. Then there are other commands which are already covered better by other packages I guess.

[Luis-Henriquez-Perez]

I would really like the selectrum-info command. Also, I'd like a command for selecting org capture templates akin to counsel-org-capture-string and something to select org tags like counsel-org-tag. I have implementations in my config for the last two if you want them.

[tomfitzhenry]

consult-comint-ring that read from (ring-elements comint-input-ring) would be useful. Users would bind that to C-r in shell-mode-map, to behave like fzf in bash.

[tomfitzhenry]

consult-imenu that browses imenu via completing-read.

[tomfitzhenry]

consult-completion-at-point that performs completion-at-point using completing-read. I use company-mode but sometimes there are so many results that I'd like to narrow them via completing-read.

Apologies for the multiple messages. I took inspiration from my current init file, and my todo list.

[doolio]

For now I am focused on the core commands, which are Emacs related and uncontroversial.

That makes sense.

[minad]

@Luis-Henriquez-Perez

I would really like the selectrum-info command. Also, I'd like a command for selecting org capture templates akin to counsel-org-capture-string and something to select org tags like counsel-org-tag. I have implementations in my config for the last two if you want them.

Yes, please open PRs! We can discuss over there then!

[minad]

@tomfitzhenry

consult-imenu that browses imenu via completing-read.

Is this needed? imenu already uses completing-read for me? Take a look at the function imenu-choose-buffer-index. What should be different?

consult-completion-at-point that performs completion-at-point using completing-read. I use company-mode but sometimes there are so many results that I'd like to narrow them via completing-read.

Same question here. I am not sure if this should be part of consult. I think selectrum alone can already do this by itself. What do you use for completion? Selectrum?

[tomfitzhenry]

Is this needed? imenu already uses completing-read for me? Take a look at the function imenu-choose-buffer-index. What should be different?

Ah yes, imenu uses completing-read (recursively) as it descends the imenu tree, setting the list of candidates to that node's children. i.e. multiple calls to completing-read are made. This interface feels awkward, since I typically know the leaf I want, but not the imenu tree structure.

I'm suggesting consult-imenu traverses the entire imenu tree and sets the list of candidates to all tree leafs. i.e. one call to completing-read is made.

This is what counsel-imenu does.

[tomfitzhenry]

Same question here. I am not sure if this should be part of consult. I think selectrum alone can already do this by itself. What do you use for completion? Selectrum?

I use icomplete. It sounds like Selectrum somehow manages to act as the Completion buffer. I'll look into it, thanks.

[minad]

@tomfitzhenry

Ah yes, imenu uses completing-read (recursively) as it descends the imenu tree, setting the list of candidates to that node's children. i.e. multiple calls to completing-read are made. This interface feels awkward, since I typically know the leaf I want, but not the imenu tree structure.

Thank you I got it. It is flattening the imenu. There is already flimenu for that but I look into if I can do anything about that here. flimenu also looks like a pretty simple package which does nearly nothing. The confusion thing is that the imenu on my Emacs already looks flat, I don't know what is causing this. But my overall feeling is that consult is not the right place to add something like this if it can be easily solved on another level.