Command wishlist

[minad]

todo/open for discussion

• [ ] transient menu for consult-ripgrep/grep/... (See #170 for a prototype, #238)
• [ ] consult-kill-lines and consult-copy-lines variants of kill/copy-matching-lines in the style of consult-focus-lines (see https://github.com/minad/consult/issues/6#issuecomment-1108368266)

done

• [x] consult-lsp, wip #263 by @gagbo, see also https://github.com/emacs-lsp/helm-lsp and https://github.com/emacs-lsp/lsp-ivy
• [x] ~consult-org-clock-in~, consult-org-heading, consult-org-agenda (See #276)
• [x] Add narrowing to consult-outline by using the outline-level function (#277)
• [x] consult-xref show function, see xref branch and #216 implemented
• [x] 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.
• [x] consult-focus-lines which uses overlays in contrast to consult-keep-lines implemented
• [x] consult-keep-lines with preview and filtering using the completion-style implemented
• [x] consult-kmacro implemented
• [x] consult-completion-at-point implemented
• [x] consult-flycheck (see #51, cycle through errors with preview) implemented
• [x] consult-imenu implemented
• [x] consult-flymake implemented
• [x] 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
• [x] consult-major-command list commands corresponding to current major mode, similar to amx-major-mode-commands implemented as consult-mode-command
• [x] 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

rejected

• 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 https://github.com/oantolin/embark/issues/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.
• 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-yasnippet with preview, should be maintained in a separate repository (see #173 for a draft)
• consult-eglot, similar to consult-lsp, should be maintained in a separate repository
• consult-info (see #128 for a draft) not needed, the command (defun goto-info () (interactive) (info) (call-interactively #'Info-goto-node)) is mostly sufficient
• 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
• consult-linux-app out of scope, see https://github.com/SebastienWae/app-launcher
• consult-match jump to matches in the buffer, needs dynamic recomputation of candidates, similar to swiper-isearch not needed, consult-line and consult-grep are enough
• consult-help interactive search through documentation, commands in M-x and other symbols (see https://github.com/raxod502/selectrum/issues/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 describe-bindings + consult-focus-lines/consult-keep-lines, there will be embark-bindings soon, see https://github.com/oantolin/embark/issues/186 (the command fits well into the Embark scope and reuses Embark internals)

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.

[tomfitzhenry]

There is already flimenu for that

Perfect, thanks.

[oantolin]

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.

I wrote this function, @tomfitzhenry:

(defun completing-read-in-region (start end collection &optional predicate)
  "Prompt for completion of region in the minibuffer if non-unique.
Use as a value for `completion-in-region-function'."
  (if (and (minibufferp) (not (string= (minibuffer-prompt) "Eval: ")))
      (completion--in-region start end collection predicate)
    (let* ((initial (buffer-substring-no-properties start end))
           (limit (car (completion-boundaries initial collection predicate "")))
           (all (completion-all-completions initial collection predicate
                                            (length initial)))
           (completion (cond
                        ((atom all) nil)
                        ((and (consp all) (atom (cdr all)))
                         (concat (substring initial 0 limit) (car all)))
                        (t (completing-read
                            "Completion: " collection predicate t initial)))))
      (if (null completion)
          (progn (message "No completion") nil)
        (delete-region start end)
        (insert completion)
        t))))

To use it you just (setq completion-in-region-function #'completing-read-in-region). I'll contribute it soon to consult: even if selectrum already does this, icomplete users would benefit.

[minad]

@oantolin Cool, please do!

[Luis-Henriquez-Perez]

This might be out of the scope of consult but here goes. I have also wanted a richer set of org refile functions. Right now org-refile is very limited in the sense that the files have to be in the org-refile-targets. Would be nice to have a function that could refile to any org buffer. Since it seems consult will contain generally useful commands, this might be a good addition.

[minad]

@Luis-Henriquez-Perez please describe a bit more precisely what these functions are supposed to do. It is nice to have a bit more context. There is a plethora of functionality in Emacs and not everyone is aware of everything.

[Luis-Henriquez-Perez]

The function would move subtrees to different places. They would be very similar to the function that doom has to address this same problem.

[oantolin]

I sometimes wish ispell used completing-read when prompting you for a spelling correction.

[okamsn]

I sometimes wish ispell used completing-read when prompting you for a spelling correction.

Have you tried the package flyspell-correct? It uses completing-read (or other UIs) to select corrections, and also allows jumping to the underlined Flyspell errors.

[oantolin]

Thanks, @okamsn! I'll be sure to check it out, it looks like there are a bunch of UIs to choose from (I bet I'll land on avy). By the way, I think I fixed your file dialog problem with embark.

[oantolin]

What about a function to open a file in the default application for it according to the operating system? It would use open on Windows and Mac OS, xdg-open on Linux and cygstart undey Cygwin. Counsel has something like this in counsel-locate-action-extern and Embark has it in embark-open-externally.

[minad]

@oantolin I think counsel-locate-action-extern or embark-open-externally fits better into an action library, like Embark, not here.

[oantolin]

I am completely fine with that, @minad. But for future reference, can you explain why you think it fits better into an action library? Here's the code from embark (suggestively renamed :P). As you can see it has no embark-specific details in it at all. It is a useful function, that uses completion to select a file and then opens it:

(defun consult-open-externally (file)
  "Open FILE using system's default application."
  (interactive "fOpen: ")
  (if (and (eq system-type 'windows-nt)
           (fboundp 'w32-shell-execute))
      (w32-shell-execute "open" target)
    (call-process (pcase system-type
                    ('darwin "open")
                    ('cygwin "cygstart")
                    (_ "xdg-open"))
                  nil 0 nil
                  (expand-file-name file))))

Is it because it relies on external commands that you think it shouldn't be in consult? (That would be a reasonable reason, but is it your reason?)

[minad]

Sorry, I misunderstood - I thought it is only used as an action, I should have looked more closely. What you propose selects a file, opens it externally, that's perfectly fine and I think it belongs here. Please make a PR. Why is the counsel function called like this with the "action" in the name?

EDIT: I just saw (defalias 'counsel-find-file-extern #'counsel-locate-action-extern)

[minad]

I think I should also add consult-doctor but I am not sure yet what it should do.

[manuel-uberti]

A consult-flymake next to consult-flycheck would be great as well.

[minad]

@manuel-uberti @doolio I implemented flycheck support for now, because this is what I am using. consult-flycheck works great. In particular using the preview and jumping back and forth between errors. Flymake support would also be nice to have, but I am not sure if we should do this as a separate command or at least share some code with the flycheck command. I don't know by how much flycheck and flymake differ.

[minad]

@tomfitzhenry I added consult-imenu in https://github.com/minad/consult/commit/e37fbf233ac1824ce413d765020eaab8ea854238. It also supports preview in contrast to flimenu

[tomfitzhenry]

@tomfitzhenry I added consult-imenu in e37fbf2. It also supports preview in contrast to flimenu

Daily improvements to consult.el is my advent calendar. Thanks! 🎅

[oantolin]

Poor flimenu, I booted it from my config immediately. It would be nice that if consult-imenu is called from an Emacs Lisp buffer, the candidates were of category symbol and you got docstring annotations. I guess this is another argument for candidate transformers.

[minad]

@oantolin Good idea regarding the category! Right, it will only work if you have the transformers :(

[hmelman]

A consult-descbinds that works like counsel-descbinds to replace describe-bindings. The candidates are a string with the keybinding and function name and the selected function is looked up with describe-function (or could be executed or looked up in info)

[minad]

@hmelman While I have also wished for a better interface to the keybindings, I am not sure what the right way is. I think it would probably be sufficient to just have a better keybinding buffer (with function description, colors etc - does something like this exist? In the style of helpful) instead of the default describe-bindings. Then inside that buffer you can use consult-line/isearch as a search. I am not sure if adding this to consult is actually worth it if the default action is then to call describe-function. More often I want to lookup things and I already know what the functions will do or the oneliner docstring is sufficient. This means if there would be consult-binding, I would probably search for the thing I am looking for and then press C-g.

[hmelman]

I haven't played with it yet but I assume embark could be used to give different actions on the result whatever the default action is. I think I'd appreciate a fast way to get to binding searching/filtering without having to use one command to open the bindings buffer and another to filter it. Personally I don't use descbind much myself, but I know others that do.

[minad]

@hmelman I see there are benefits, but I think they are rather marginal in contrast to the benefits provided by other commands , which bring something new to the table, where we have preview etc. My point was just that if one has a better buffer view+consult-line you are almost there - sure you don't have actions and cannot run the commands, but I am unsure if consult-bind should be used as command launcher. I have to think about this. I am not very happy with the describe-bindings and describe-personal-keybindings buffer and I would like something with more information.

[minad]

@doolio Since you proposed consult-linux-app, I want to let you know, that I think it is out of scope of this project for the following reasons/missed criteria:

1. The command is not Emacs-related, and too operation-system specific
2. I don't see advantages of maintaining it as part of this package, since it would not make use of the facilities offered by consult--read. It could be as well maintained as part of some other launcher.el package working directly with the completing-read API.
3. It seems to require relatively complex parsing of the desktop-files (bad benefit/cost ratio, given that it does not make use of the facilities offered here by consult)
4. More personally, I am not particularly interested in using such a command - I launch programs via the shell in contrast to desktop files

Alternatively we could consider adding such a command to a consult-linux-app.el package if for some reason we would find that it makes sense to maintain this command as part of consult. But so far, I don't see this (point 2).

[minad]

@veronikazaglotova You proposed originally in https://github.com/raxod502/selectrum/issues/241 a command to search through docstrings. I tried to implement a consult-help command which allows to search through all symbol documentation strings. The formatting of the documentation strings is provided by marginalia, see #67. Unfortunately the command is too slow to be useful, selectrum/icomplete seems to be unable to handle that many strings.

@clemera Ping, just in case you need a command to see if there are still potential improvements to the selectrum performance... ;)

[doolio]

You make all valid points. Thank you for giving my suggestion due consideration. I use EXWM and so the command was a better alternative to the EXWM method.

[minad]

@doolio I think the command itself makes sense - I only question if it makes sense within the context of this project. My suggestion would be to extract the corresponding code from counsel.el and rework it such that it is based on completing-read, and then maybe create a new package. Generally I think it makes sense to have smaller more focused packages and Consult is already problematic in that sense due to its kitchen-sink nature. But by adding a few restrictions as I argued above, I guess this package can stay focused.

[doolio]

Agreed. I will attempt to make the function generic and report here or on the selectrum wiki if successful. Thanks again for your time and this package.

[minad]

You could very well make this a freestanding package and submit it to MELPA. But before doing that please check if something similar or equivalent already exists.

[irigone]

The formatting of the documentation strings is provided by marginalia

Yeah that's why I installed marginalia in the first place, thank a bunch for the great package

Unfortunately the command is too slow to be useful, selectrum/icomplete seems to be unable to handle that many strings.

That's sad. I can still use consult-apropos + M-x though, so it's not that bad.

[minad]

@veronikazaglotova You can try the command from here https://github.com/minad/consult/tree/consult-help and see if you would use something like this. For me it is too slow. These are simply too many too long strings for selectrum to handle. Maybe selectrum could be optimized further or gcc-emacs helps, I don't know.

[clemera]

I think its mainly sorting and filtering that make consult-help slow, I quickly tested it and if you deactivate sort and set selectrum-refine-candidates-function to the default it is much more responsive for me.

[hmelman]

FYI, apropos-documentation does this (search docstrings), though not with interactive narrowing (probably because of the performance issues).

[minad]

@clemera Thank you for the info - maybe we can make this work!

[SebastienWae]

@doolio I'm using EXWM too and moving from Ivy to the Selectrum/Consult/Embark completion stack, so I extracted counsel-linux-app to make it work with Emacs native completion system. It's not on MELPA but you can get it here https://github.com/SebastienWae/app-launcher

[irigone]

@veronikazaglotova You can try the command from here https://github.com/minad/consult/tree/consult-help and see if you would use something like this. For me it is too slow. These are simply too many too long strings for selectrum to handle. Maybe selectrum could be optimized further or gcc-emacs helps, I don't know.

Tbh I don't know how to use straight to install packages from git. I installed consult with it and it works, but copy&pasting the code from consult doesn't really work on other packages. I don't want to install packages by hand. Perhaps we can shorten the string before passing it to selectrum? For example, org-mode has a very long docstring (I read it with C-h f). If we shorten it to just Outline-based notes management and organizer, alias "Carsten’s outline-mode for keeping track of everything."it will get faster? After this there's a lot about keybindings and stuff which the user probably won't know about. The second paragraph has "Org mode develops organizational tasks" and can be useful too, though. Most (if not all) interactive functions I've seen have a short explanation in the first 1-2 paragraphs.

[minad]

@veronikazaglotova Well, we are already using only the first line of the docstring.

[irigone]

Damn...

[irigone]

• consult-binding to browse keybindings

How is it different from which key?

[minad]

How is it different from which key?

I would say it is totally different :D

[hmelman]

@veronikazaglotova Yeah, totally different. Which-key (which is great) pops up help after typing a prefix key with the options you can type next. consult-binding (assuming it's like counsel-descbind) would give a completion list of all bindings that you could then narrow based on input matched against the key (or command name) of the binding. It's kinda the reverse of M-x with marginalia showing the keybindings.

[irigone]

I did a big dumb Should've read the thread

[hmelman]

A consult-emoji that inserts ARG number of the selected emoji into the buffer. It's similar to the built in insert-char but would be limited to just emoji, making it easier to scan the matching candidates. Also, since emojis are just one character, I would display them first followed by their name (unlike insert-char which shows the glyph at the end).

consult-mark currently just uses the local mark-ring. There's also a global-mark-ring and there could be another command to access it (or perhaps call consult-mark with an arg). evil-mode uses its own marks which are like markers stored in registers and there could be a command to access them.

[irigone]

IDK how to name it. Consult-mark already exists :/ In Vim, there's a thing called a mark. If you type ma, to Vim it means "mark current line in the register a". Vim will remember the line where the cursor is and write it down. After that, you can go to that mark from any place in the file if you type 'a. Neat, right? Unfortunately, it's a half-baked feature. It's nice, but you have to hold all the marks in your head and think about which place is on which mark. I want this feature! But I wish it also had a swiper-like menu so that I won't forget which mark is where. I also think it's a good idea to not limit to 1 character so that I could have a cool easy to remember name for the mark. Something like this

student    class Student: # this class has propert...
car        class Car: # cars have length, height...

On the left is the mark name, on the right is the line. Saving the file names and their marks somewhere (to make it save between sessions) is a good idea, too. https://github.com/jacktasia/dumb-jump does a similar thing but (from what I see in the readme) you can't make your own marks, just go to definitions. Vim also has global points, they are capital characters. If you open a file "test", go to third line, type mA, Vim will remember that. Then you restart Vim (without opening any files), type 'A and it opens the file "test" and moves the cursor to where it was. Would be great if you made it smart: for example, if I delete a line before a mark, mark should still be on the same line, although it's not an easy task.

[minad]

There is already consult-mark, consult-register and consult-bookmark. But I guess none of those options is perfectly satisfying for that use case? Can you try consult-bookmark and consult-register just to see if these are good enough?

[hmelman]

@veronikazaglotova So the feature already exists in emacs. In emacs, there are named registers that can hold positions (and other things) and you save them and return to them. There's also a consult-register already. 😄 There's also bookmarks which can have longer names and there's a consult-bookmark already.

Emacs also has a mark-ring that saves positions as you move around and that's what consult-mark uses. I mentioned evil, it's the vim-like emulator in emacs and it implements vim's marks. There's a counsel-evil-marks that accesses them and I was suggestion a consult version of it.

[minad]

We could add an option to consult-register such that if you select an unused register or type "SPC key" the register is overwritten with the current location.

[minad]

@hmelman what do you think about my suggestion regarding enhancing consult-register?

[hmelman]

@minad I think it already does that, doesn't it? 😄 Oh, or does it just write text and not location and you're suggesting an ability to save a location too. That would be great. I'd probably use an argument instead of a SPC key.

[minad]

@veronikazaglotova @hmelman No it does not. I will prototype something and ping you!

[hmelman]

@minad There are lots of -to-register commands that can save lots of things, numbers, window configs, text, location, rectangles. Maybe it would be better to have consult versions of all of them which use completing-read for the register name and could show existing registers (annotated with marginalia with their content) so that you see which having existing content and either choose one to overwrite or an unused one.

[irigone]

there is already consult-mark, consult-register and consult-bookmark. but i guess none of those options is perfectly satisfying for that use case? can you try consult-bookmark and consult-register just to see if these are good enough?

Both are indeed good enough and do just what i want, but i wish they could show the line as well, so that i knew where i'm going to end up.

[irigone]

Maybe it would be better to have consult versions

Why not one that rules them all?

[minad]

@veronikazaglotova @hmelman I also thought about having some all in one solution.

Type "r" to access register r "wr" to store window config in r, "pr" to store position etc. Furthermore we can use the consult narrowing to narrow to positions only etc. Would that make sense? But it is quite different from standard emacs interactions with registers I guess.

[hmelman]

Not the way emacs does it. These commands are bound under C-x r and the next key defines what is stored or accessed. In some cases the access works for multiple kinds of values. See insert-register and jump-to-register. I don't use them extensively but I think it works well. An all-in-one solution could work, but wouldn't it necessarily involve an additional keystroke?

[minad]

@hmelman I agree it would be quite different and the keysequence would be longer. I am also not using registers much probably because I don't find them very accessible.

@veronikazaglotova we could render positions in registers such that the line is shown.

[minad]

@veronikazaglotova @hmelman I think it is better to not reinvent such a thing. What we could do however is improving the consult-register view and maybe add preview support for locations for example. To store, simply use the standard register keys.

[hmelman]

Registers already have a fairly flexible way of displaying themselves (based on their type) which consult-register uses register-describe-oneline. I think that's good enough for now. I didn't realize but the various -to-register commands seem to read the register name via register-read-with-preview which does previewing after a delay. Emacs knows ;)

[minad]

@hmelman what's the purpose of viewing the register content when you want to write? In order to not overwrite something and find a free register? Or did I misunderstand you?

[irigone]

previewing after delay

Doesn't work on my Emacs. How?

[hmelman]

@minad You did not misunderstand, that's the reason I was thinking of.

[hmelman]

@veronikazaglotova I'm looking at Emacs 27 code. Put stuff in registers. I put a window config in a, text in b and a point in c. Then try to put stuff in another register, I did C-x r SPC to save a position, when it prompts for a register to use, wait a second (default is 1) and a temp window appears showing the values of registers a,b,c on three lines.

[irigone]

Oh yeah, now I see it!

[irigone]

Doesn't work with points in register sadly

[hmelman]

Does for me.

[irigone]

That's not what I want. I want something like this:

d,         line starting with "def func(arg" in file "somefile.py", position 424

[irigone]

Hi! Can I use your source code?

[minad]

@hmelman @oantolin @veronikazaglotova I added consult-global-mark to browse the global mark ring. Please test! :partying_face:

[hmelman]

Will do. I suspect there's some refactoring and code sharing that could happen with consult-mark-ring. :)

[minad]

@hmelman No, nothing significant, I decided to keep it separate from consult-mark since I think it is conceptually different and it displays the candidates differently. Furthermore it requires buffer switching in contrast to consult-mark. Not much code sharing is possible, except if I would over-generalize consult--mark-candidates. It is better like this.

[minad]

But I should add - I have quite a few more general purpose helper functions around which are used by both consult-mark and consult-global-mark and the other consult functions, so the situation is not bad. consult-global-mark does not add much to the code base, no huge complexity and not a huge number of lines of code.

[hmelman]

I'm not sure what your options are, but I had done my own counsel-global-marks and aligned the filename:line column on the : and liked how it looked.

[minad]

@hmelman Indeed, this looks indeed better. See https://github.com/minad/consult/commit/d29ee8d86d4ee5fe6e5851128d0adc0ff8ea7b48.

[hmelman]

and FWIW rather than M-g x I've bound it to M-g M-m to correspond with M-g m for consult-mark.

[minad]

@hmelman The current proposed keybinding is not good, I agree. But I am also not so sure about M-g M-m since I think consult-mark and consult-global-mark serve different purposes and are not just two sides of the same thing.

Therefore I also did not smash them together into one command - if I would have done that you would have to press M-g m l SPC and M-g m g SPC to narrow down to local and global marks only. What do you think? Better to have them separate?

EDIT: I changed the binding proposal to M-g k. I think this is good :)

[hmelman]

I agree they're better as separate commands. I'm not sure how much use these consult commands will get vs C-u C-SPC and C-x C-SPC but if they are to get use, they should be fast to get to. I do view them as related, particularly since the global mark is set by setting local marks. Many (even experienced) users don't know about these two rings, so two commands give them more visibility which is good.

emacs bindings usually have some (often strained) mnemonic meaning which I'm lost on for either M-g x or M-g k. Maybe M-g m and M-g M though I prefer keeping the same modifier key, hence M-g M-m for me.

[minad]

@hmelman

I do view them as related, particularly since the global mark is set by setting local marks. Many (even experienced) users don't know about these two rings, so two commands give them more visibility which is good.

Sure they are related, but I feel they fulfill different purposes, navigation between buffers vs inside the current one. And the global one is not just the sum of the local ones.

emacs bindings usually have some (often strained) mnemonic meaning which I'm lost on for either M-g x or M-g k.

I agree and I am also trying to propose mnemonic bindings here. And both M-g mark and M-g mark are pretty mnemonic to me :)

[hmelman]

Yes they're related and yes they do different things. :) I tend to use the global mark when I'm tracing a code path through several files and at some point need to move to another place along the code stack. xref might take over this usage, but a consult-global-mark can make random access to that list nice. It's still "move between these corresponding things I'm working on that just happen to be in different files" so they're more similar to me than different.

I agree and I am also trying to propose mnemonic bindings here. And both M-g mark and M-g mark are pretty mnemonic to me :)

Ah, I see the k is for marK I didn't get that at first. That is indeed an infrequently used way to find more keys, and it's definitely better than x. I'll stick with mine, it's why emacs is customizable, I just wanted to propose it so you considered it.

[minad]

Yes, the good thing here is that consult is not grabbing any keybindings by default. Choose what you like :)

[irigone]

@hmelman @oantolin @veronikazaglotova I added consult-global-mark to browse the global mark ring. Please test! partying_face

That's quiet nice. I need some way to have keybindings for these things. Any ideas? I already remapped the defaults a lot...

[velppa]

consult-find-file - similar to counsel-find-file. I tried to use combo find-file + consult, but Counsel's version works better:

• Pressing ~ changes path to ~
• Pressing Backspace removes directory by directory

[clemera]

@pavel-popov Note that by default you can type ~/ or // (see also this if you want to hide the previous path completely) and to to edit by dir levels you can use s-expression commands.

[minad]

@pavel-popov Thank you for the suggestion, but consult-find-file does not sound like a good fit for Consult. The improvements you have in mind cannot be solved on the level of Consult, but should be solved by the completion system, e.g., Selectrum or Icomplete, depending on what you are using. Furthermore I would like to avoid adding substitutes for existing commands which only provide marginal benefits over the original version.

EDIT I should expand a bit more - if you use Marginalia and Embark, the built-in find-file command is enhanced such that it provides the same features as counsel-find-file. The idea of the component-based approach is that a replacement of the original command is not necessary.

[manuel-uberti]

* Pressing Backspace removes directory by directory

You could bind backspace to something like backward-kill-sexp in minibuffer-local-map (or something similar) for that, I guess.

[okamsn]

@hmelman @oantolin @veronikazaglotova I added consult-global-mark to browse the global mark ring. Please test! partying_face

That's quiet nice. I need some way to have keybindings for these things. Any ideas? I already remapped the defaults a lot...

I like having a personal keymap bound to F2. I have consult-mark on F2 m, consult-imenu on F2 i, consult-kmacro on F2 k, etc.

[irigone]

I like having a personal keymap bound to F2. I have consult-mark on F2 m, consult-imenu on F2 i, consult-kmacro on F2 k, etc.

I'm stealing this but I'll use C-i instead (heil GUI!).

I would prefer consult-line to show lines without indentation. Is this possible?

[velppa]

@clemera, ~/ and // - it works, thank you for something new I learned today about Emacs. A bit not pleasant as in counsel-find-file, but file-name-shadow-mode should cover it.

@manuel-uberti, @minad thanks for quick response. I'm a bit confused with the scope of Consult vs Selectrum as it doesn't seem that a completion package (Selectrum) should know about current input context (like file path when dealing with find-file), and it's Counsel not Ivy containing keymaps for find-file.