emacs-helm/helm

Cannot find `slime` function in `M-x`

ccqpein opened this issue · 31 comments

What happened?

When I run M-x slime, helm usually give the first choice slime function. But in master version (I use straight.el to build the master version) and v3.9.5, the slime function disappeared.

Then I checkout to v3.9.4, I can find the slime function as usual.

How to reproduce?

Using the master/v3.9.5 helm and try to start slime function.

Helm Version

Master branch

Emacs Version

Emacs-30+

OS

MacOSX

Relevant backtrace (if possible)

No response

Minimal configuration

  • I agree using a minimal configuration

The only thing I do is git checkout to v3.9.4 (497f479) in git repo folder ~/.emacs.d/straight/repos/helm.

The left one is v3.9.4, the right one is the master version.

Screenshot 2023-09-09 at 23 30 33

And I find both of them have 50 candidates(s), however, they are different at the ending:

Screenshot 2023-09-09 at 23 33 29

the master branch looks like figure out there are 50 candidate(s) but and give one step further.

I couldn't reproduce with slime but I could with "helm" in describe-function, I think the culprit is commit b6e3828. I just reverted it, let me know if it fixes it.

@thierryvolpiatto Yes! It fixes the issue, thanks for such a quick fix.

ccQpein @.***> writes:
@thierryvolpiatto Yes! It fixes the issue, thanks for such a quick fix.
I made another change in the same area (slightly more efficient) which should work as well, let me know if it is not working. Thanks.

I just test, it works fine.

Thanks

Hi @thierryvolpiatto I think I find the other issue maybe related to this issue. I can find the slime command now but only when I finish the whole typing of slime.

Like when I type slim, the first result in list is slime-ping. I think it should be slime right?

And the length of results list is 50 before and after I type the last e of slime. Looks like the search already find the slime before I finish my typing, just doesn't show it.

@thierryvolpiatto this is the screenshot of this issue.

Screenshot 2023-11-07 at 22 39 18

I study a bit and check the running logic of helm-M-x. When I call helm-M-x-read-extended-command at the ending of helm-M-x function, the collection argument doesn't have slime command inside. And I change the helm-mm-exact-search in helm-mutli-match.el a bit. I print out (re-search-forward (helm-mm-exact-get-pattern pattern) nil t) value every time it calls. And only return the value when I finish the slime ("$slime^" pattern).

Why do you have "$slime^"?
Also why do you have line numbers enabled and how did you enable it?
I would like you reproduce from a minimal emacs (emacs-helm.sh).
Thanks.

Why do you have "$slime^"?

I print the result of (re-search-forward (helm-mm-exact-get-pattern pattern) nil t) for testing, and it only returns number after I finish typing slime. And I call the (helm-mm-exact-get-pattern "slime"), it gives me the "$slime^"

Also why do you have line numbers enabled and how did you enable it?

I have (global-display-line-numbers-mode) in my init.el. If I delete it, line number gonna off.

I would like you reproduce from a minimal emacs (emacs-helm.sh).

I make and run emacs-helm.sh --load-packages async,slime. The problem is gone, it works totally fine. So it definitely some of my configuration problem. So I change some code in the emacs-helm.sh --load-packages async,slime mode.

I add the (print sources) before the last expression unwind-protect in function helm-M-x-read-extended-command. Then search the result, there is no slime inside.

If I understand right, does it mean when I run helm-M-x, it also search the source somewhere else beyond this one

(helm-make-source "Emacs Commands" 'helm-M-x-class
                       :data (lambda ()
                               (helm-comp-read-get-candidates
                                ;; [1] Same comment as above.
                                collection pred nil nil ""))
                       :fuzzy-match helm-M-x-fuzzy-match)

Can you give me some tips that which path is the source :data come from? I can keep studying on my side of this issue because it is my config issue.

Thank you!

@thierryvolpiatto thanks for your quick reply as always 👍 .

It is why I ask people in bug reports to say "yes I am using a minimal
config", but most people cheat saying yes while they don't :-(.

I was thinking the "minimal config" was "keep environment clean and don't change all custom var". Until you replied, I noticed there are ./emacs-helm.sh. Good to know and sorry about that.

Thanks for your info, I will keep debugging my environment. It is fun to study your fantastic work.

Best

For me, "emacs -Q" + (minimal helm v3.9.5), following "ff" and "mew" don't appear with helm-M-x or describe-func. And reverting the suggested commit fixes it.

(defalias 'ff 'fundamental-mode)
(defun mew ()
(interactive))

With my init.el, other two- or three-letter commands also have trouble.

My emacs is:
GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.35, cairo version 1.17.8)
(no gccjit)

Thanks ccqpein for reporting this, et je vous remercie, Thierry. (De nouveau :-)

And reverting the suggested commit fixes it.
Which commit exactly?

b6e3828, i.e. (forward-line 1) in helm-mm-exact-search

Did you compile Helm with the same Emacs you use?
Yes, after installing emacs-29.1, helm was compiled.

How did you install Helm, from source or from package?

My Liunx distro, Gentoo, provides its compitation framework, and each user compiles all.

To be sure,

  • I deleted all <helm-v3.9.5>/*elc, and
  • $ emacs -Q -l a.el , where a.el is:

(push "/usr/share/emacs/site-lisp/helm/" load-path)
(push "/usr/share/emacs/site-lisp/async/" load-path)
(push "/usr/share/emacs/site-lisp/popup/" load-path)
(require 'helm)
(require 'helm-mode)
(require 'helm-command)
(helm-mode 1)
(defalias 'ff 'fundamental-mode)
(defalias 'wc 'whitespace-cleanup)
(defalias 'dc 'describe-char)
(defalias 'ic 'insert-char)
(defalias 'gl 'goto-line)

Then

  1. for helm-M-x, only ff is missing.
  2. for describe-function, ff and ic are absent, but wc, dc and gl do appear correctly.
    (Sorry, I was not able to reproduce "mew" above either.)

After evaluating:
(defun helm-mm-exact-search (pattern &rest _ignore)
(and (search-forward (helm-mm-exact-get-pattern pattern) nil t)
(forward-line -1)))
all above commands appear, as it should be.
grab

Okay, the HEAD, or v3.9.6, resolves my problem. (I'm not the OP.)

Merci beaucoup. Vous êtes très gentil. Et que le monde soit meilleur en 2024 !

After experimenting several times, I've finally figured out what's going on: it's because my helm-candidate-number-limit is set to 50. So, unless I fully input 'slime', the command doesn't appear in the list. I changed the limit to 500, and now 'slime' is included in the commands list when I search.

I turned on debugging, and, if I'm not mistaken, the call stack is as follows:

  • helm-update
  • helm--collect-matches
  • helm-compute-matches

In helm-compute-matches, the function (helm--candidates-in-buffer-p source) returns me (search helm-mm-exact-search helm-mm-search helm-candidates-in-buffer-search-default-fn)

Then I print the call

(helm--initialize-one-by-one-candidates
            (helm-take (helm-get-cached-candidates source) limit)
            source)

it returns me the ("slime") when I type "slim".

then (helm-process-filtered-candidate-transformer '("slime) source)

It seems like helm-M-x-transformer-no-sort handles the final sorting of candidates. Is there a setting that can ensure the most relevant commands appear at the top of the candidates list?

helm-candidate-number-limit , for helm-M-x

I was looking for this var by "max" keyword, tried debugging internals. Default is 50 and it's not enough for customize command to appear in a list. Setting it to 128 shows main customize instantly.

Returned to Helm after using vertico, consult, orderless, embark, marginalia, corfu for some prolonged period.
Helm has better UI. TAB for actions in Helm is more ergonomic than embark. Some other quirks, can't remember.

I am using 500 since years now, perhaps it's time to increase it?

Yes, big number for this setting makes results always as expected, especially in cases like customize which is expected to appear at first line as early as possible.

Looks like change helm-candidate-number-limit to 500 fix this issue. I think we can close this issue now?