Ergonomic initial narrowing

[hpfr]

Hi Daniel, thanks for making Consult (and the rest of your excellent packages).

I guess the consult-project-buffer behavior makes sense for remapping project-switch-to-buffer, but in my case I am looking to make a DWIM consult-buffer wrapper that calls consult-buffer with preset project narrowing when inside a project, while still allowing me to DEL to return to the full consult-buffer-sources in case I realize I wasn’t looking for something in my current project.

As far as I can tell, there is no way to do this with consult--multi/consult--read (short of a keyboard macro calling C-x b p SPC). :narrow is used by consult--multi to define the full set of narrowing options, but I am looking for something like :initial-narrow. I guess it could take a character argument for the initial source to narrow?

A semi-related discussion is #894. But I don’t think :hidden is what I am after since it’s fixed when consult--multi is called and can’t be modified interactively like narrowing.

[minad]

What's wrong with C-x b p SPC as a macro?

[minad]

I just tested (keymap-global-set "s-x p" "C-x b p SPC") and it does not seem to work. Did this ever work? Maybe @oantolin knows? It seems keyboard macros quit the minibuffer.

The following works however:

(defun fake-macro ()
  (interactive)
  (setq unread-command-events (listify-key-sequence (key-parse "C-x b p SPC"))))

[hpfr]

Yeah that macro was a wild guess, I have little to no experience with using macros for anything other than ephemeral editing operations. What a spooky workaround, I’ve never seen unread-command-events before.

I guess it seemed to me that a programmatic way to narrow would be useful. Maybe for this specific example a macro is sufficient, but it won’t compose well with additional logic. It also couples the implementation to random keybindings, which isn’t a huge issue in practice I guess, but another reason I try to avoid binding macros in my permanent config. Thanks in any case!

[minad]

I've added :initial-narrow in a5ffca7.

[minad]

However thinking about it a bit more it should be possible to support multiple narrow keys per source with only a moderate extension, as you suggested.

[minad]

Added in 4f4d29d

[hpfr]

Works great. You even made it the default, very nice. The project root source is a good idea too.

You should be using Orderless filtering instead. Orderless filtering has the advantage that the filter is part of the input, which is not the case with narrowing. See orderless-kwd which can also filter by group.

Wow, this is great too. In my defense you created it this year and it’s not yet documented in the Info manual or README! I agree that this looks much better suited than group narrowing to complex filtering.

Thank you again! You have once again exceeded even my loftiest expectations 😅

[minad]

Wow, this is great too. In my defense you created it this year and it’s not yet documented in the Info manual or README! I agree that this looks much better suited than group narrowing to complex filtering.

Indeed, I forgot to add orderless-kwd to the README. Iirc I had planned to do this - so thanks for the reminder. ;)

The problem with orderless-kwd is that it is not so convenient. One has to write a rather long filter expression. On the other hand, the filter will be powerful and inline. As such can be more easily manipulated or stored. See for example the input history in vertico-repeat. Narrowing in contrast is like some side channel, an out of band filter. For these reasons I had doubts early on about narrowing in Consult.

Regarding the recent improvements it turned out that the functionality had already been almost there, it just wasn't exposed nicely for consult-customize. For example the :initial sub-keyword of :narrow. In contrast multiple narrowing keys would be over the top, e.g., showing both files and buffers via the keys bf. But via your proposal one can simply assign a new key to both sources combined and be done with it with a single key.

Thanks!

[hpfr]

Got to try orderless-kwd out today, what a great addition. Agreed that it fills a different role than narrowing, but if I was forced to pick one, it would be orderless-kwd for the reasons you describe. The boolean keywords and substring/regexp matching (e.g. :grp=buf) still keep things relatively concise. It’s great how it generalizes to many filtering methods. And the composability thanks to the in-band nature (vertico-repeat, as you mention, but also embark-rerun-collect-or-export!) just feels right. But certainly nice to have both at my disposal!