search

minad / consult

:mag: consult.el - Consulting completing-read
GNU General Public License v3.0
1.12k stars 98 forks source link

Command wishlist #6

Closed minad closed 8 months ago

minad commented 3 years ago

todo/open for discussion

Seems feature complete? ;)

done

rejected

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.

irigone commented 3 years ago

Damn...

irigone commented 3 years ago
  • consult-binding to browse keybindings

How is it different from which key?

minad commented 3 years ago

How is it different from which key?

I would say it is totally different :D

hmelman commented 3 years ago

@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 commented 3 years ago

I did a big dumb Should've read the thread

hmelman commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

hmelman commented 3 years ago

@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 commented 3 years ago

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

hmelman commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

Maybe it would be better to have consult versions

Why not one that rules them all?

minad commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

previewing after delay

Doesn't work on my Emacs. How?

hmelman commented 3 years ago

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

hmelman commented 3 years ago

@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 commented 3 years ago

Oh yeah, now I see it!

irigone commented 3 years ago

Doesn't work with points in register sadly

hmelman commented 3 years ago

Does for me.

Screen Shot 2020-12-15 at 5 33 46 PM
irigone commented 3 years ago

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 commented 3 years ago

Hi! Can I use your source code?

minad commented 3 years ago

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

hmelman commented 3 years ago

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

minad commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

hmelman commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 m**ark and M-g mark** are pretty mnemonic to me :)

hmelman commented 3 years ago

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 commented 3 years ago

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

irigone commented 3 years ago

@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 commented 3 years ago

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

clemera commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago 
* 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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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.