emacs-helm/helm

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 that baz has disappeared from the list.
  • Next, try M-x bugged-helm baz !xy and observe that we (correctly) select baz
  • 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.