You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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))```
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))```
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.*Message ID: ***@***.***>
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.
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:
M-x bugged-helm !xy
and observe thatbaz
has disappeared from the list.M-x bugged-helm baz !xy
and observe that we (correctly) selectbaz
M-x bugged-helm !xy baz
and observe that no candidates matchRepeat 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
The text was updated successfully, but these errors were encountered: