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
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.
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
- for helm-M-x, only ff is missing.
- 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.
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?