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.

[minad]

Do you only see it for bookmarks? I will keep an eye on this and if it appears in my setup I will do some debugging.

[0x462e41]

No, I see it for open buffers. I paste that form just as an example to show that I have now defined it using setq instead of nconc.

[minad]

I am not seeing any issues. Do you confuse the duplicates of "Project Buffer" and "Buffer"? Please try a minimal config for "emacs -Q" as described in https://github.com/minad/consult#bug-reports which includes icomplete-vertical and the buffer source modifications you are doing. If the problem is reproducible there I can quickly reproduce it.

[0x462e41]

Do you confuse the duplicates of "Project Buffer" and "Buffer"?

That was precisely what was happening, ops. Sorry for the waste of your time and thanks for helping me find out what was wrong. The "hidden" flag works great now, and it is already been an improvement in my workflow! I am pasting the configuration I am currently using to accomplish what I was describing at the beginning of this issue, maybe someone will one day find this thread wanting to accomplish the same behavior:

;; Hides everything, except the buffer source
(dolist (source '(consult--source-bookmark
                  consult--source-file
                  consult--source-project-file
                  consult--source-project-buffer))
  (setq source (plist-put (eval source) :hidden t)))

Note that I ended up choosing not to use the nconc function. Using plist-put adds a little more verbosity, but I think it is more reliable and also allows the end user to easily replace some property. I am, for example, using this method to change the "items" property of consult--source-buffer, so that it can hide the current buffer from the buffer source. By doing this, the command works as expected for someone who is used to the command switch-to-buffer. The snippet is as follows:

;; Hides the current buffer from buffer list
(setq consult--source-buffer
      (plist-put consult--source-buffer
                 :items
                 (lambda ()
                   (let ((filter (consult--regexp-filter consult-buffer-filter)))
                     (seq-remove (lambda (x) (or (string-match-p filter x)
                                                 (string= (buffer-name) x)))
                                 (consult--cached-buffer-names))))))

[minad]

Sorry for the waste of your time and thanks for helping me find out what was wrong.

No worries, this was a productive discussion and we even got this :hidden improvement out of the discussion! Could you please do me a favor and paste your first example to the wiki? I think this could be useful for more people. Maybe with a link to this issue and a short description.

so that it can hide the current buffer from the buffer source. By doing this, the command works as expected for someone who is used to the command switch-to-buffer.

Yes, I originally had this but in the end I went with the deviation from the default behavior, just putting the current buffer to the end. This came out of some discussion with @clemera and I think the current behavior is good. I don't think it is very unexpected or problematic to have it like this. But sure, the point of the whole design is that you can change it and tweak it to your liking!

[0x462e41]

Could you please do me a favor and paste your first example to the wiki? I think this could be useful for more people. Maybe with a link to this issue and a short description.

All done :-)

[minad]

Thanks! I applied a small correction, see https://github.com/minad/consult/wiki#hide-all-buffer-sources-except-normal-buffers-in-consult-buffer-by-default. Please check that it makes sense.

[0x462e41]

There was a small parenthesis problem in the code, I have already fixed it. I also changed the title a little bit, because the code does more than "Hide all buffer sources" (also hides the recent file source, for example).

[minad]

Thanks. I wrote "Hide all buffer sources", since these are buffer sources used by consult-buffer, you could have different sources for your own consult--multi commands. But this is probably too much of a detail and it is easier to understand as you have it now.