consult--read able to initiate already narrowed down

[0x462e41]

I think it would be useful to be able to evoke this function with the sources already narrowed. By doing this, it would be possible, for example, to call consult-buffer already restricted to the buffer subset and, only if desired, remove the narrowing or even change it.

Sorry if it's already possible, I haven't read the code base entirely yet.

[minad]

This is not possible out of the box, but you can easily achieve this behavior as follows:

;; Configure initial narrowing per command
(defvar consult-initial-narrow-config
  '((consult-buffer . ?b)))

;; Add initial narrowing hook
(defun consult-initial-narrow ()
  (when-let (key (alist-get this-command consult-initial-narrow-config))
    (setq unread-command-events (append unread-command-events (list key 32)))))
(add-hook 'minibuffer-setup-hook #'consult-initial-narrow)

[minad]

Added to the wiki, https://github.com/minad/consult/wiki#start-command-with-initial-narrowing. Please let me know if it works for you.

For now I think it is better to not add extra out-of-the-box support for this feature. Could you describe a bit better where it is useful? Then I can then judge better if it would make sense to add it to consult--read directly.

[0x462e41]

Yes, it works. Thanks!

I find it useful when we want to combine several sources in the same "completing read", but generally in our workflow, we usually narrow it to a subset. For me, an example might be what I described: when I call consult-buffer, I usually instantly narrow to the buffer subset, although I sometimes want to select a recent file. So, just using "f SPC" on these occasions is easier than almost always use "b SPC". I do this because my job involves opening several files, sometimes with a similar name, and dealing with them. In these cases, mixing buffers and recent files is confusing, making it difficult to discern which files I am currently dealing with and which files I have already dealt with.

Another example is to narrow consult-imenu programmatically to show functions or variables, depending on the context (point position, for example), but also being able to change the narrowing if needed.

Anyhow, the solution you included on the wiki is good enough, considering that not all users would benefit from it, I think.

[minad]

I just type the name of the buffer or the file and orderless gives me the candidates I want to see :) But maybe if you have many similar candidates as in your case it becomes useful to use narrowing to unhide. For now I think it is better to not included the prenarrowing by default since it will probably be used very rarely.

But note that there exists the buffer filtering feature for hidden buffers which are not shown by default, provided by the source with the 32 narrow key (space). This behaves a bit like initial narrowing and it is a tiny bit of special casing that is needed in order to align consult-buffer with the familiar switch-to-buffer behavior. Maybe this is a feature which could actually be generalized and would also fit your use case?

Basically every source would get a :hidden field, which would hide the source candidates if it is set and only exposes them when narrowing to this specific source. This would allow multiple hidden sources and would get rid of the 32 special casing. You could mark files as hidden by default. Would that be helpful? I think I like this idea.

[0x462e41]

I also use orderless (by far the best completion-style out there), but the files I have to work with have large names, with lots of recurring bits. It would not be so fluid to always have to think twice what would make the name different before typing in my case, unfortunately.

Good idea, it would definitely be useful! In doing so, the user could choose which sources to hide, and also choose a specific key for this hidden subset. By default, consult could continue to have the "^ \\*.*" buffers hidden under 32 narrow key, so nothing would break for anyone.

I think it is always a good idea to generalize functions, especially when we are talking about the Emacs' hacker spirit :-)

[minad]

I added the :hidden field, it is a nice and cheap generalization/addition. Please give it a test!

[0x462e41]

It is working flawlessly! Exactly what I needed! I hope others will make good use of it, as I am already doing. Thank you!

[minad]

Thank you for testing and for the initial suggestion 👍

[0x462e41]

Um, I am getting some duplicate candidates now that I opened more buffers... I hid everything except the buffer source doing this:

  (nconc consult--source-bookmark (list :hidden t))
  (nconc consult--source-file (list :hidden t))
  (nconc consult--source-project-file (list :hidden t))

What could be the problem?

PS.: I am using icomplete-vertical

[minad]

I also had that issue before. Please take a look at the consult-buffer-sources list if for some reason the mutation introduced duplicate sources. This happend for me when reevaluting some code, e.g. reloading the package. Maybe using mutation with nconc is not the best idea and I should remove it from the README 🙈.

EDIT: I don't think the nconc here is the problem. But please check that consult-buffer-sources does not have duplicates. I have seen that before, but I don't know what the exact reason was.

[0x462e41]

I was doing some tests and set up everything manually. Here is an example (I did the same for the consult--source-file) :

  (setq consult--source-bookmark
        `(:name     "Bookmark"
                    :narrow   ?m
                    :hidden t
                    :category bookmark
                    :face     consult-bookmark
                    :history  bookmark-history
                    :items    ,#'bookmark-all-names
                    :action   ,#'consult--bookmark-action))

But I am still seeing duplicate candidates. And no, there is nothing strange with consult-buffer-sources, follow its value:

(consult--source-hidden-buffer consult--source-buffer consult--source-file consult--source-bookmark consult--source-project-buffer consult--source-project-file)

I am sorry, but I won't be able to do more tests for several hours. I will keep trying to narrow the bug when I have more time.