Cannot find `slime` function in `M-x`
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
- [X] I agree using a minimal configuration
ccQpein @.***> writes:
- ( ) text/plain (*) text/html
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.
I can't reproduce. I hardly see how helm-M-x would miss slime unless slime is not autoloaded properly. Are you sure all your packages are loaded properly?
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
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.**>
-- Thierry
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.
And I find both of them have 50 candidates(s), however, they are different at the ending:
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 b6e38286. 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.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
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
ccQpein @.***> writes:
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.
Great! Thanks to confirm.
Thanks
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
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.
ccQpein @.***> writes:
Hi @thierryvolpiatto I think I find the other issue maybe related to this issue.
What is the other issue?
I can find the slime command now but only when I finish the whole typing of slime.
I can't reproduce here.
Like when I type slim, the first result in list is slime-ping. I think it should be slime right?
Yes, it is what I have here.
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.
Not sure to understand what you mean here, but again I have nothing weird here when I type slim in M-x.
Be sure to not use Spacemacs or such emacs distribution, only Helm.
Thanks.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
@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!
ccQpein @.***> writes:
( ) text/plain (*) text/html
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^"
It should not be "$slime^" but "^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.
The only reason to use line numbers in helm is to use relative line numbers, for this use C-c l but not global-display-line-numbers-mode.
I would like you reproduce from a minimal emacs (emacs-helm.sh).I make and run emacs-helm.sh --load-packages async,slime.
async is already loaded by the script.
The problem is gone, it works totally fine. So it definitely some of my configuration problem.
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 :-(.
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.
Instead of this, start M-x, type C-h C-d, then type "slim" or whatever,
quit (C-g) and hit C-h C-d (outside of helm this time).
You can also enable debugging before starting M-x with (setq helm-debug t).
If I understand right, does it mean when I run helm-M-x, it also search the source somewhere else beyond this one
There is two sources, one for history and one for the commands.
The helm-buffer (what you see when doing M-x), is not searched, the
search occur in (helm-candidate-buffer), to see it use helm-buffers-list
or helm-mini, then hit C-c a.
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.
From M-x use C-h d, you will have perhaps useful infos.
Thank you!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
@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 :-)
teika @.***> writes:
- ( ) text/plain (*) text/html
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.
Which commit exactly?
(defalias 'ff 'fundamental-mode) (defun mew () (interactive))
I still can't reproduce.
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)
How did you install Helm, from source or from package? Did you compile Helm with the same Emacs you use?
Thanks ccqpein for reporting this, et je vous remercie, Thierry. (De nouveau :-)
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
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.
teika @.***> writes:
And reverting the suggested commit fixes it. Which commit exactly?b6e3828, i.e. (forward-line 1) in helm-mm-exact-search
Ok, I think something is wrong in your installation.
To be sure,
• I deleted all <helm-v3.9.5>/*elc, and • $ emacs -Q -l a.el , where a.el is: After evaluating:
(defun helm-mm-exact-search (pattern &rest _ignore) (and (search-forward (helm-mm-exact-get-pattern pattern) nil t) (forward-line -1)))
Normally this should not work with the actual Helm master because it search literally a regexp instead of a plain string, thus it move backward and repeat the same search forever, but if it works it means you have a older version of helm-mm-exact-get-pattern.
all above commands appear, as it should be.
Right if you have 3.9.5 installed but it seem a more recent version of helm-multi-match (or more exactly a definition of helm-mm-exact-search) is installed somewhere.
Try to delete all your helm files and reinstall from source, then your recipe should work properly (it does here).
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
teika @.***> writes:
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.
Ok, I see, you have 3.9.5 installed which indeed doesn't work for this, it is fixed two commits later in 3d6e5f14.
I will release a new 3.9.6 version, that should fix your problem.
Please always use the latest master version when you report a bug and also for you it is generally (much) better.
Thanks.
-- Thierry
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 !
teika @.***> writes:
Okay, the HEAD, or v3.9.6, resolves my problem.
Great! thanks to confirm.
Merci beaucoup. Vous êtes très gentil. Et que le monde soit meilleur en 2024 !
Merci, j'espére aussi!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
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-updatehelm--collect-matcheshelm-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.
Alexander Karbivnichiy @.***> writes:
- ( ) text/plain (*) text/html
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.
I am using 500 since years now, perhaps it's time to increase it?
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.
So welcome to Helm ;-)
[ For something like marginalia, you just have to enable
completions-detailed or helm-completions-detailed if the former is
not available in your Emacs version. ]
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.**>
-- Thierry
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?