Rename consult-line, consult-goto-line about consult HOT 21 CLOSED

I think I keep it as is since consult-goto-line is just a drop in replacement, so it is good to keep the name.

from consult.

I'll admit that in thinking about this and how the built-in commands are named I realized something about consult that I should have previously known. That most of these commands are just providing a list of candidates and it's the completion system's job to match input against it. So the fact that I can use regexps in consult-line (which I also just realized) is because I'm using selectrum (with its default configuratoin) and doesn't indicate that the command should be named consult-line-regexp or influence the contents of its prompt. Unfortunately I think that could have made some of the naming considerations easier, but so be it. :)

FWIW, Here is how some of the relevant built-ins do things:

• goto-line: "Goto line: "
• move-to-column: "Move to column: "
• occur: "List lines matching regexp: "
• how-many: "How many matches for regexp: "
• isearch-forward: "I-search: "
• isearch-forward-regexp: "Regexp I-search: "
• isearch-forward-word: "Word I-search: "
• search-forward: "Search: "
• grep: "Run grep (like this): "

So they don't mention "number" for either line or column numbers which I think would be better. They tend to leave out a term for a literal search and always mention "regexp" for a regexp search (which is good) but as stated above, isn't really relevant to consult.

I think if consult adds a command to replace an existing command, it would certainly be clear to name them the same as the built-ins (so consult-goto-line). And it would be fair to use the same prompt. I think the built-in using "Goto" is inconsistent with many other built-in commands that say "Go to" so I'd prefer "Go to" as you're using.

I prefer consult-goto-line-number with a prompt "Go to line number: " because everything is clear, particularly considering the existance of a consult-line command. I saw a recent reddit post discussing the documentation of the built-in goto-line and it's an interesting command. An experienced emacs user probably doesn't use it much since they'll use ways other than typing a line number to find things (xref, next-error, isearch, etc.), but it's a common operation that a newbie would look for. Given that, I think including "number" in the command name makes it more likely they'd find it using M-x or a help command.

As for consult-line I don't love it, but given my realization in the first paragraph I'm more content with it. I prefer it to ivy's closest equivalent, swiper because it means something. I think consult-line-search or consult-line-matching would be fine, but I don't like either enough to justify a name change.

When considering these in pairs, perhaps consult-line and consult-line-number are the best and shortest. I think consult-goto-line and consult-goto-line-number also work.

Maybe consult-occur would be a good option for consult-line. It matches with the existing consult-multi-occur and is named for the built-in command with the closest functionality. The prompt could be "Go to line matching: " It has the benefit of using the same name as an existing command and would therefore pair well with consult-goto-line for the line number flavor.

from consult.

Thank you for your thoughts. I agree mostly with what you write except about occur. consult-multi-occur is a drop in for the broken multi-occur, there is no relation to consult-line. Furthermore occur is too overloaded, given embark-occur, embark-occur, multi-occur and occur.

from consult.

Can I ask what's broken about multi-occur? Are you referring to the way buffers are selected, because I did just discover some problems with that when using selectrum.

Also, why do you think there's no relation between consult-line and occur? To me they both are basically grep over the current buffer. occur uses a compilation framework and enables next-error while occur-line is way more interactive. But I'd use both the same way -- to find lines matching a pattern -- particularly if I use previews with occur-line.

I agree that I don't love the names of either embark-occur or ivy-occur for the functionality they offer.

from consult.

Can I ask what's broken about multi-occur? Are you referring to the way buffers are selected, because I did just discover some problems with that when using selectrum.

Yes, it uses a half-baked way to choose buffers, while there is already the completing-read-multiple, but that's all.

Also, why do you think there's no relation between consult-line and occur? To me they both are basically grep over the current buffer. occur uses a compilation framework and enables next-error while occur-line is way more interactive. But I'd use both the same way -- to find lines matching a pattern -- particularly if I use previews with occur-line.

Okay, conceptually they are related. But technically they are not related. More precisely - consult-line is using the completing-read machinery while consult-multi-occur is just the fixed version of multi-occur with completing-read-multiple for the buffers - but besides that it is just standard multi-occur.

from consult.

I agree that I don't love the names of either embark-occur or ivy-occur for the functionality they offer.

Maybe it makes sense to suggest changing the name, at least in the case of embark. Maybe it is not too late. It could be that embark-occur/embark-live-occur will be refactored soon. I made a proposal in the embark issue tracker, but I didn't propose a renaming.

from consult.

I like the related command embark-export, its name is much more in line with the functionality and it's not confused with a replacement for occur. Maybe some variation of it is a better name for embark-occur.

from consult.

@hmelman I agree 100% regarding embark-export. Much better name :) But ideally Embark should be streamlined a bit, right now there is embark-occur, embark-live-occur and embark-export. Maybe they can be unified slightly more, such that they are only different configurations of the same "occur/export" functionality.

I think ivy-occur originated from swiper and then using ivy-occur to get an occur-like buffer. Could that be?

from consult.

I understand your distinction between the implementations of occur and consult-line. I'd suggest considering the name consult-occur for a few days and seeing if it grows on you. I'm not sure how I feel about it. Since what consult-line does is a different kind of search paradigm for emacs (seemingly halfway between isearch and occur), maybe it does deserve a different name (like swiper did). Though consult-line followed by embark-occur does do what occur does.

As far as I know swiper came first (originally for helm) and then ivy and then ivy-occur, but I'm no expert on the history of it.

FWIW I was never a swiper user, in spite of being an extensive ivy and counsel user. I prefer isearch for searching in a buffer and didn't need the extra display of lines I wasn't interested in, usually with too little context. And if previewing was the solution to that, I didn't see the benefit over isearch anyway. And I used occur occasionally, usually when I wanted to edit the list some way or see all occurrences of some tag like "TODO". I find my searching was enhanced much more from using symbol-overlay and magit-todos.

from consult.

I'd suggest considering the name consult-occur for a few days and seeing if it grows on you.

I think this won't happen 😁

FWIW I was never a swiper user, in spite of being an extensive ivy and counsel user. I prefer isearch for searching in a buffer and didn't need the extra display of lines I wasn't interested in, usually with too little context. And if previewing was the solution to that, I didn't see the benefit over isearch anyway. And I used occur occasionally, usually when I wanted to edit the list some way or see all occurrences of some tag like "TODO". I find my searching was enhanced much more from using symbol-overlay and magit-todos.

While I like consult-line more and more (and all the other consult commands), I am still using isearch from time to time when the different behavior makes sense. For consult-line I don't see the missing context as a big problem, since I see searching using consult-line as a two-step process. First narrow down and type the right keywords and then scroll through the results and maybe edit them on the go.

But while consult-line is useful, it is certainly not like the heart of the whole thing. It is just something which falls out naturally when you have completing-read+preview. And as such I just see it as something which is on the same level as the other commands, e.g., consult-imenu or consult-outline.

from consult.

As far as multi-occur being broken, have you reported this as an emacs bug? I found Emacs bug 41633 and it doesn't seem like they have a great solution. Maybe they'd use completing-read-multiple if suggested and obviate the need for consult-multi-occur.

from consult.

@hmelman Yes, probably it would make sense to report this or send the patch upstream. Then consult-multi-occur could go away. For now I didn't try to push things upstream since I usually get quickly tired by endless mailing list discussions. In most of the cases where I submitted bug reports to very popular projects, the reports just go ignored for years. For me it is more productive to just use a fixed version myself (like consult-multi-occur) - but this is certainly not the best approach if things should improve as a whole. If you feel like it you can submit this or report it, otherwise I may do this at some point.

from consult.

But while consult-line is useful, it is certainly not like the heart of the whole thing. It is just something which falls out naturally when you have completing-read+preview. And as such I just see it as something which is on the same level as the other commands, e.g., consult-imenu or consult-outline.

I agree with that. I'm not much of a preview user so far. I think I would like a binding to toggle previewing interactively rather than needing to preconfigure various consult- commands to use it. Is this under consideration?

from consult.

I agree with that. I'm not much of a preview user so far. I think I would like a binding to toggle previewing interactively rather than needing to preconfigure various consult- commands to use it. Is this under consideration?

Well, there is not much to consider here. consult-preview-mode is already a command like any other minor mode. You can bind this.

from consult.

I understand the exhaustion of dealing with emacs-devel. In this case, you know way more about this than I do and have a solution using a standard emacs function to a problem they didn't have a good solution to themselves. I'll add that Lars has been quite good lately at apply proposed solutions quickly.

Ah yes, I had forgotten I bound consult-preview-mode to a key, sorry for the noise. I just bound it globally, is there a better keymap to use, like selectrum-minibuffer-map?

from consult.

Ah yes, I had forgotten I bound consult-preview-mode to a key, sorry for the noise. I just bound it globally, is there a better keymap to use, like selectrum-minibuffer-map?

Hmm, maybe it makes sense to bind it to some embark map? The same applies to marginalia-cycle-annotators. I haven't done that myself. Unfortunately embark requires embark actions to somehow consume targets, but maybe we find a way to avoid this somehow.

I understand the exhaustion of dealing with emacs-devel. In this case, you know way more about this than I do and have a solution using a standard emacs function to a problem they didn't have a good solution to themselves. I'll add that Lars has been quite good lately at apply proposed solutions quickly.

Actually I also don't understand that much about it, consult-multi-occur is basically the version from the Selectrum wiki.

from consult.

@hmelman Just added the example to embark regarding marginalia-cycle-annotators, see minad/marginalia@40e2881

from consult.

I'm trying it with consult-buffer but it seems to exit the command.

from consult.

You have to use embark-act-noexit.

from consult.

Yes that works, though it seems I need to hit another key to see the change take effect.

from consult.

Yes, this is expected. In order for this to work you have to couple the completion system to marginalia-cycle. Otherwise the update is not performed automatically. Unfortunately this is not possible in a completion-system agnostic way. Therefore this is not yet implemented. See the marginalia-cycle code, there is a note.

from consult.