embark-quit-after-action: preserve Consult narrowing

[chasecaleb]

trafficstars

Is it possible to preserve Consult's narrowing after an Embark action when the minibuffer is kept open?

For example, I have this bit of config to keep the minibuffer open so that I can kill a few buffers rapidly:

(setq embark-quit-after-action '((kill-buffer . nil)
                                 (describe-symbol . nil)
                                 (t . t)))

This works great for the most part. However, I have to re-narrow the consult buffer after every kill action which is inconvenient. In other words, currently I have to do this to kill a few buffers in a row:

1. M-x consult-buffer
2. Narrow: e.g. b to narrow to just buffers, p to narrow to project with consult-projectile, or whatever.
3. C-. k for kill-buffer
4. Consult buffer is still shown but no longer narrowed, so narrow again
5. Kill another buffer

---

You're a lot more familiar with Embark and Consult internals than me, but I'm willing to help implement this if you can point me in the right direction. I did come across a Consult wiki section on configuring initial narrowing, which isn't the same use case but it might give some ideas for how to restore the narrowing.

Thanks!

[oantolin]

We can think about maybe adding some sort of state restoration hooks, but as a first simple approach, trying this and see if you prefer that behavior:

(setf (alist-get 'kill-buffer embark-post-action-hooks) nil)

That way you won't loose the narrowing, but the killed buffers won't be removed from the view.

[minad]

I am not fond of adding special restoration. It is clear that the situation is not perfect, but if we start to add special restoration, it is unclear where to stop. I think it is okay to have breaking points between Embark and the other packages. For performing larger number of candidate manipulations embark-collect or embark-export is the way to go anyway. There we have almost full dired/ibuffer-like functionality, combined with consult-focus-lines/consult-keep-lines filtering. Furthermore we recently got the restarting functionality.

I think special completion UI restarting code will be a pain to maintain and is a better fit for the wiki. For example one could add restarting code which tries to restore the Vertico selection state (ala vertico-repeat). One top one could try to restore Consult-specific narrowing as proposed in this issue.

[oantolin]

I think special completion UI restarting code will be a pain to maintain and is a better fit for the wiki.

I fully agree @minad, I only meant we could add a hook to embark--restart to easily write this restoration wiki code. (An alternative, of course, would be to advise embark--restart instead.)

[minad]

I would just go with an advice. If it turns out that the wiki code would be significantly simplified by a hook we can still add it. And if then, it turns out that the wiki code is maintainable and concise enough we could still consider adding it to the Embark completion UI integration.

[chasecaleb]

Thanks! Alright, here's what I came up with. I've only used it for a little while but seems to work so far. Any insight into the minibuffer-setup-hook comment?

(advice-add #'embark--restart :before #'cc/embark--restore-narrowing)

(defun cc/embark--restore-narrowing (&rest _ignored)
  "Kludge to restore consult narrowing after a non-quitting embark action.

See https://github.com/oantolin/embark/issues/509"
  ;; `with-minibuffer-setup-hook doesn't work, so using `add-hook'. I think minibuffer isn't triggered
  ;; until after (outside of) the function being advised here? It looks like it should be, but
  ;; Embark is doing some clever things with repeating commands so I'm probably confused.
  (when-let ((narrow consult--narrow))
    (cl-labels ((my-fn ()
                       (unwind-protect
                           ;; 32 is ASCII space.
                           (setq unread-command-events
                                 (append unread-command-events (list narrow 32)))
                         (remove-hook 'minibuffer-setup-hook #'my-fn))))
      (add-hook 'minibuffer-setup-hook #'my-fn))))

[oantolin]

I'm a little confused: the comment says minibuffer-setup-hook "doesn't work" and then the function uses it anyway.

[chasecaleb]

Ugh, copy-pasta fail on my part. That was supposed to be: with-minibuffer-setup-hook doesn't work. Edited to reflect that.

[oantolin]

I think your code above @chasecaleb is an adequate solution to your problem, right? I'll close this issue in that belief, but feel free to continue the discussion or reopen if necessary.

[chasecaleb]

Yeah, I just double checked in my config and that's what I'm still using :+1: