helm-source-in-buffer drops last entry when first pattern is negated
dankessler opened this issue · 3 comments
What happened?
I noticed this issue when using completing-read from within org-roam. If the first token in my helm search pattern involved negation, I would get a bizarre blank entry.
I was able to isolate this behavior in a much simpler setting. In brief, it seems that when helm-source-in-buffer
is used, if the first pattern provided starts with negation, then the last element is dropped. See the MWE for more details.
I'm not quite sure why in my original case, rather than dropping the last entry it was replaced with a blank entry and moved to the top, but I assume it has the same root cause.
How to reproduce?
The problematic behavior can be observed using these two simple interactive functions:
(defun bugged-helm ()
(interactive)
(helm :sources (helm-build-in-buffer-source "buffer-test"
:data '("foo" "bar" "baz"))))
(defun good-helm ()
(interactive)
(helm :sources (helm-build-sync-source "test"
:candidates '("foo" "bar" "baz"))))
- Now do
M-x bugged-helm !xy
and observe thatbaz
has disappeared from the list. - Next, try
M-x bugged-helm baz !xy
and observe that we (correctly) selectbaz
- Last, do
M-x bugged-helm !xy baz
and observe that no candidates match
Repeat the above experiment but instead starting with M-x good-helm
and notice that things work correctly (i.e., baz
is always available).
Helm Version
Melpa or NonGnuElpa
Emacs Version
Emacs-29.1
OS
MacOSX
Relevant backtrace (if possible)
No response
Minimal configuration
- I agree using a minimal configuration
I think the issue has something to do with these lines inside of helm-mm-3-search-base
which appears to cause different behavior when the first part of the search pattern involves negation.
when (eq (caar pat) 'not) return
;; Pass the job to `helm-search-match-part'.
(prog1 (list (pos-bol) (pos-eol))
(forward-line 1))```
Thanks for the quick fix! I can confirm that it's no longer dropping the last entry in either my simple example nor in my use case with org-roam
.
However, I still get a weird empty candidate when the first pattern is negated, but I'll file a separate report once I isolate that to something non-specific to org-roam
and can produce a more abstracted reproducible example.