-
|
With latest melpa consult, I wanted to try out the code at https://github.com/minad/consult/wiki#pre-select-nearest-heading-for-consult-org-heading-and-consult-outline-using-vertico to pre-select the nearest heading, something that I could use multiple times daily. However, it currently yields: I don't know why my |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 4 replies
-
|
See https://github.com/minad/vertico#debugging-vertico which should help with debugging. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the docs re enabling debugging in the post-command hook. First part of backtrace looks like this: Which seems to indicate that in the following code: (lambda (cand point-pos) ; counts on candidate list being sorted
(> (cl-case current-minibuffer-command
(consult-outline
(car (consult--get-location cand)))
(consult-org-heading
(get-text-property 0 'consult--candidate cand)))
point-pos)))... the At that point, I've looked through the (removed an I've replaced the |
Beta Was this translation helpful? Give feedback.
-
|
Ok here's a nice new variation which maintains your selected heading even as you change the filter string. It's largely the same as what's on the wiki, plus the (defvar consult--previous-point nil
"Location of point before entering minibuffer.
Used to preselect nearest headings and imenu items.")
(defvar vertico--previous-input nil
"Previous vertico input so we can distinguish whether user is changing input string.")
(defun consult--set-previous-point (&rest _)
"Save location of point. Used before entering the minibuffer."
(setq vertico--previous-input nil)
(setq consult--previous-point (point)))
(advice-add #'consult-org-heading :before #'consult--set-previous-point)
(advice-add #'consult-outline :before #'consult--set-previous-point)
(advice-add #'vertico--update :after #'consult-vertico--update-choose)
(defun consult-vertico--update-choose (&rest _)
"Pick the nearest candidate rather than the first after updating candidates."
;; we only select the closest heading if the user is changing filter string
;; this happens at invocation, and as the user filters
;; as they filter, we want to keep on selecting (if possible) the heading they were closest to
(when (and (memq current-minibuffer-command
'(consult-org-heading consult-outline))
(not (equal vertico--input vertico--previous-input)))
(setq vertico--previous-input (copy-tree vertico--input))
(setq vertico--index
(max 0 ; if none above, choose the first below
(1- (or (seq-position
vertico--candidates
consult--previous-point
(lambda (cand point-pos) ; counts on candidate list being sorted
(> (cl-case current-minibuffer-command
(consult-outline
(car (consult--get-location cand)))
(consult-org-heading
;; cpbotha's work-around, see https://github.com/minad/consult/discussions/891
(get-text-property 0 'org-marker cand)))
point-pos)))
(length vertico--candidates))))))) |
Beta Was this translation helpful? Give feedback.
-
|
I was looking for this exact feature: I have an org file with a bunch of date-headings, and it's very confusing to be presented with headings far away from point. So, I'll probably try this, but using |
Beta Was this translation helpful? Give feedback.
-
|
This code works great. The one at the wiki is still buggy: |
Beta Was this translation helpful? Give feedback.
-
|
I got this error on |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much @NightMachinery -- I see that I fixed this in my own config, but forgot to update here as well: ;; another small cpbotha fix: consult-outline :before advice passes nil
;; argument, so we need optional arg
(defun consult--set-previous-point (&optional arg)
"Save location of point. Used before entering the minibuffer."
(setq vertico--previous-input nil)
(setq consult--previous-point (point)))I've now updated the solution above to your |
Beta Was this translation helpful? Give feedback.
-
|
On 11/28/23 18:32, Stefan van der Walt wrote:
So, I'll probably try this, but using |advice| seems a bit scary; is it
truly the officially recommended route for modifying |consult|, and is
it future-proof? Is there a reason not to include this functionality in
|consult| itself?
This feature is not included in Consult since it is difficult to
implement in a general way for different completion UIs. Basically
completing-read lacks a way to request preselection of a candidate.
As the code snippet above shows, both Consult and Vertico code is
touched and the components are entangled more closely, which is
something I am trying to avoid.
If I find time I may look into this feature again. It has been requested
often for various commands (consult-line, consult-outline,
consult-imenu, ...).
|
Beta Was this translation helpful? Give feedback.
Ok here's a nice new variation which maintains your selected heading even as you change the filter string.
It's largely the same as what's on the wiki, plus the
org-markerfix, and it keeps track of the current input so that it can determine whether the user is filtering (changing the input string), in which case they want to stay close to their pre-selected heading, or moving around, in which case we want to let them.