Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

helm-source-in-buffer drops last entry when first pattern is negated #2650

Closed
1 task done
dankessler opened this issue Mar 21, 2024 · 3 comments
Closed
1 task done
Labels

Comments

@dankessler
Copy link

dankessler commented Mar 21, 2024

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
@dankessler dankessler added the bug label Mar 21, 2024
@dankessler
Copy link
Author

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))```

@thierryvolpiatto
Copy link
Member

thierryvolpiatto commented Mar 22, 2024 via email

@dankessler
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants