embark-consult: which consult commands should be bound in action and become maps?

[minad]

Idea by @astoff in https://github.com/minad/consult/pull/171/files#r560111176. The general-map is maybe too general?

[minad]

I think I'm a pessimist, maybe it should fallback to consult-imenu if consult-project-root-function is nil.

I will take a look at the code.

But also maybe consult-project-root-function should default to vc-root-dir or something in terms of project-root?

@astoff suggested that in https://github.com/minad/consult/issues/167. I usually don't have vc loaded.

[oantolin]

I think maybe everything is fine as it is, I was just surprised by what happened when I ran consult-project-imenu, but I like that even with nil project root function it does something different than consult-imenu, something more global. And I can understand not wanting to load vc. It's easy enough for users to set the variable to vc-root-dir.

[minad]

It is okay to pessimize it, I guess that makes more sense. Also if the project root function returns nil, which is allowed. There is also consult--imenu-all-items in case someone wants to use a custom buffer filter.

[oantolin]

I would only bind consult-project-imenu and not consult-imenu.

I was going to use p and i respectively. Do you really think it's better to bind only one of them?

[minad]

Maybe it is good to have consult-imenu at hand too if you want to get an Embark collect outline? If we have enough free keys let's just bind both.

[oantolin]

Maybe for the become maps its better to separate the async commands, because of the leading #, which you'd have to remove or add.

[oantolin]

OK, done with the search commands. I had to improve the support for prefix keys in the completing-read prompter first! 6bb4e5aef66c921ac722b6aa07745dc788ef5f6a

[oantolin]

Some other consult command should be added to some become keymaps. A bunch should go into the file+buffer map. I think maybe after adding those, this issue can be closed. Am I missing any other consult commands that need bindings in embark keymaps?

[minad]

I just wanted to check the consult submenu, but there is a problem - it does not update the which-key indicator. Do you have an idea on how to fix this? (EDIT: I made a separate issue to keep it in mind - https://github.com/oantolin/embark/issues/139).

Regarding the become commands, I have not thought about these yet and I am not using become often. Nevertheless it is a nice feature. Maybe @protesilaos has some ideas on what should be bound? Probably there are more useful (also non-consult) actions we could add? In particular if we are using submenus - we have the potential to offer many more actions in a nicely structured way.

[protesilaos]

Regarding the become commands, I have not thought about these yet and I am not using become often. Nevertheless it is a nice feature. Maybe @protesilaos has some ideas on what should be bound?

I have been using become to switch between grep+find, buffers+recentf. Same for switching between consult-{line,outline,imenu}. The implementation may still be refined though.

Probably there are more useful (also non-consult) actions we could add?

My plan is to extend this principle for project.el commands for files, buffers, subdirs (my extension), grep.

There are other niches, such as my custom "insert bongo playlist" command that can become back and forth an "insert directory/URL/etc.". I have not implemented those yet because I have been busy [further] refactoring my Emacs config (recently removed use-package and just extended diff-mode's font-lock).

EDIT: just to clarify that I have not read through this issue yet.

[oantolin]

I have been using become to switch between grep+find, buffers+recentf. Same for switching between consult-{line,outline,imenu}. The implementation may still be refined though.

The embark-consult package now adds consult-{line,outline,imenu} to the embark-become-match-map, under the prefix C, @protesilaos.

[minad]

@protesilaos

I have been using become to switch between grep+find, buffers+recentf.

Unrelated, but since you mention buffers+recentf - I know you are not using consult-buffer since you dislike having multiple different candidate sources thrown together. Maybe you dislike that consult-buffer has been very ad-hoc? Still, I want to let you know that consult now has support for a better mechanism to merge candidates from different completion categories in a clean and fully configurable way. See https://github.com/minad/consult/blob/794e82d0306dc24aaf1612f982f724f28a02e3f2/consult.el#L2924 for the updated consult-buffer implementation. For such multi completions the consult-multi category is reported which works with Embark and Marginalia by dispatching to the individual category of the candidate under consideration.

[protesilaos]

The embark-consult package now adds consult-{line,outline,imenu} to the embark-become-match-map, under the prefix C

Very well! I have not updated anything the last few days.

Unrelated, but since you mention buffers+recentf - I know you are not using consult-buffer since you dislike having multiple different candidate sources thrown together. Maybe you dislike that consult-buffer has been very ad-hoc? Still, I want to let you know that consult now has support for a better mechanism to merge candidates from different completion categories in a clean and fully configurable way.

I noticed the commits in my feeds but I have not checked anything in depth yet (I read the commit logs before updating). That granted, I have not been using consult-buffer thus far because it gives me too many false positives. For example, I have a buffer "modus-themes.el", a directory "modus-themes", a recentf "modus-themes.html", one with org extension, another with .info... Fundamentally, I need to make better use of the completion-category-overrides or something, though I have not looked into that for a long time---I should.

[minad]

@protesilaos Yes, having false positives is certainly the main problem with multi sources. If you figure something out I am eager to hear. But at least now it is possible to configure consult-buffer to the bits, remove sources add your own etc. And you can easily write your own commands based on consult--multi. I haven't done that yet - consult-buffer is the only multi command I am using. However I suspect it could be useful to write some project-specific menus where you throw together multiple common operations for quick access.

[protesilaos]

@protesilaos Yes, having false positives is certainly the main problem with multi sources. If you figure something out I am eager to hear. But at least now it is possible to configure consult-buffer to the bits, remove sources add your own etc. And you can easily write your own commands based on consult--multi. I haven't done that yet - consult-buffer is the only multi command I am using. However I suspect it could be useful to write some project-specific menus where you throw together multiple common operations for quick access.

Good to know! Will need to study it and give it a test.

[minad]

@oantolin I think this is finished. Only #139 is missing for accessibility.

[oantolin]

Yeah, I think you're right. I'll close this now.

By the way, I just reread the above exchange with @protesilaos and wanted to let you know that consult-buffer is growing on me, I think I might wind up using it as my main way to switch buffer and jump to bookmarks. It is less efficient than using switch-to-buffer and bookmark-jump for me, but only very slightly, and it's nice not to have to think about which command I need beforehand.

Also, I've turned on recentf-mode and whatever bad interaction it had with TRAMP years ago when I tried it for a couple of days seems to have been fixed. I do often try to switch to a buffer I recently killed, so it'll be nice to have the recent files too. I know lots of people have been using something like helm-mini for years, but I am very resistant to change for some things I have muscle-memory for, so I'm glad to see I might switch over this time.

I normally love automatic Consult previews, but I think for this particular case I might turn them off. In part it's that it's jarring that only buffers have a preview, though I understand and agree with the reasons for that.

[minad]

Note that you can overwrite the preview function 😆

I could even factor them out from consult-buffer and consult-bookmark. They are local lambdas now. This would be better for reuse. But you can also just write your own consult--multi based command in ten lines or so.

Another option would be to make :preview part of the buffer sources such that we could enable it for more without doing any harm for people who dislike it since the sources can be modified easily.

Right now I have a distinction of source fields read by consult--multi vs additional fields read by the source consumer, eg in the case of consult--buffer the :open field. The :open action is not read by consult--multi. So maybe this field should really be called :buffer-open since it also receives a buffer specific display argument. And then there could be a :buffer-preview field.

At this point sources are of limited reusability since their preview and their action are tied to the command which is supposed to use them. In particular preview worries me a bit. If one would combine different source types their preview functions could interfere in weird ways.

[astoff]

In part it's that it's jarring that only buffers have a preview

Please just don't add preview for unopened files! counsel-switch-buffer does that, and I think it's 1 of 2 unreasonable default settings in all of Ivy...

[minad]

Please just don't add preview for unopened files! counsel-switch-buffer does that, and I think it's 1 of 2 unreasonable default settings in all of Ivy...

I agree regarding the defaults. But in consult it is now configurable, see https://github.com/minad/consult#multiple-sources.

(nconc consult--source-bookmark (list :state #'consult--bookmark-preview))
(nconc consult--source-file (list :state #'consult--file-preview))
(nconc consult--source-project-file (list :state #'consult--file-preview))

[minad]

I am not entirely consistent however, consult-recent-file previews by default and consult-grep also previews by default. Regarding consult-recent-file I could change it, but I don't think that anyone is actually using this command, it is just provided as a minimal fallback to consult-buffer. consult-grep previews since in that case I actually care about the content, since I search content, so I think preview is justified.

[oantolin]

Please just don't add preview for unopened files! counsel-switch-buffer does that, and I think it's 1 of 2 unreasonable default settings in all of Ivy...

@astoff I meant more in the opposite direction: buffers shouldn't be previewed (at least not automatically) either. It's weird that they are the only type in consult-buffer with a preview by default.

[minad]

@oantolin Well, I like the automatic preview and right now I am activating the preview everywhere also in order to showcase the feature. I think many people like it, including me. For recent files in consult-buffer it is obviously not a good option, since opening files can be very costly when additional modes are loaded etc. This is the compromise.

[oantolin]

I love the previews and want them automatic in every other case. But I think I might configure a preview key for consult-buffer specifically (I haven't yet.)

[astoff]

I think the way things work now is pretty reasonable, in particular the rationale for consult-grep to preview unopened files. As to the preview in consult-buffer, I think it's only useful on rare occasions, but then it's already there when I need it. I wouldn't use if if I had to remember a different key.

[oantolin]

New question on this topic: I just added consult-buffer to the embark-become-file+buffer-map bound to C b; should I bind it to b instead, overwriting the binding for switch-to-buffer? The idea is that maybe most people using the embark-consult package will be using consult-buffer instead of switch-to-buffer.

[minad]

Yes, b would be better I guess!

[minad]

We could bind consult-keep/focus-lines in the match map, maybe replacing keep and flush-lines.

[oantolin]

We should bind them, but I'm a little unsure about replacing keep/flush-lines. Maybe C f and C k instead? (In fact maybe C b is fine for consult-buffer in the file+buffer map.) What if someone uses keep-lines by accident (maybe old muscle memory), and wants to switch to consult-keep-lines? That's inconvenient unless they both have (distinct) bindings in the become map.

[astoff]

Slightly on a tangent, since keep-lines doesn't have a global binding, but why is Consult's suggested config not done with remaps instead of replacing the mappings to their original versions? This may have some disadvantages, but it would make some of the things discussed in this issue just work out of the box.

[oantolin]

I was thinking even before your comment @astoff, that people that want to completely replace some built-in with a consult function will probably remap and then they get the non-C-prefixed binding anyway. So I don't have to worry about the remappers.

And binding the consult commands under the C prefix here actually helps the rest of the users, the ones that don't remap and maybe actually use both the built-in and a consult analogue: with separate bindings for the commands they can easily switch between them.

[minad]

@astoff I am not using remaps since I am not a fan of remaps, that's all. I am not using remaps in my config at all, I think. I like it better to be direct and more explicit. @oantolin's answer goes in the same direction. Users can always replace the bindings with remaps in case they prefer that style. And I should add - the consult configuration example is really just an example, people should bind things as they wish. For this reason there is no consult-mode which performs auto configuration. Counsel has such a mode afaik.