WIP: Add support for Sly.

[Ambrevar]

Addresses #8. Do not merge.

Left to do:

• See if "apropos" errors when typing too fast.
• Re-test over SLIME, possibly remove completion and history Helms.
• Decide of the name space: keep "slime" or move to "lisp".
• Update readme, commentary.
• Bump version.

[Ambrevar]

With helm-lisp-apropos, if I type too fast, I get an error message:

error in process filter: Reply to canceled synchronous eval request tag=sly-result-45 sexp=(slynk-apropos:apropos-list-for-emacs "fo" t nil nil) [2 times]

with "fo" being the letters I've typed so far.

Note that it does not stop Helm from proceeding, so it works in practice, but the message is annoying. Any idea how to fix this, @thierryvolpiatto ?

[Ambrevar]

I propose to remove the old completion code and let the user rely on helm-company instead. Is that OK?

[thierryvolpiatto]

Pierre Neidhardt notifications@github.com writes:

Assigned #9 to @thierryvolpiatto.

I will not work on this, slime is not installed here and I have not the time working on all helm packages + others.

Note: By adding support to Sly, be sure to not break the actual code for Slime. Slime is here since long time now and have proved it works fine, Sly is very new and last time I tested was quite buggy.

-- Thierry

Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Ambrevar]

Oh no worries, I was just asking for your opinion, mostly on the namespace and the package name.

I was planning to work on it (in fact the job is almost done). :)

I've kept most of the SLIME code as is, except for the completion which I have removed.

Sly is not so new, it's been around publicly at least since 2014 ;) I've played with it for a few days, it's been very stable (at least as stable as SLIME) and I believe it's superior to SLIME in a couple of ways.

[Ambrevar]

It's ready to be merged. I'll keep using it for a day or 2, see if I catch some last-minute bugs.

I'd like to rename the project to helm-lisp if that's alright.

Cheers!

[thierryvolpiatto]

Pierre Neidhardt notifications@github.com writes:

Oh no worries, I was just asking for your opinion, mostly on the namespace and the package name.

I was planning to work on it (in fact the job is almost done). :)

I've kept most of the SLIME code as is, except for the completion which I have removed.

The completion was working fine, see https://github.com/emacs-helm/helm/issues/2165 I don't fully agree on dynamic completion used in sly (more generally on the definition of completion). But well as I don't use this package... Use what you find the best.

Thanks.

-- Thierry

Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Ambrevar]

Cc @joaotavora

[Ambrevar]

@thierryvolpiatto: How do you get SLY completion to work with Helm? I could not figure it out from the discussion you've linked.

I read the aforementioned discussion and I understand you disagree with SLY completion, but when used together with helm-company, it seems to be doing the right thing that you want: a Helm buffer with all the matches, on which the users narrow down. There is no story of "prefix or no prefix", since the prefix does not appear in the Helm input when using helm-company.

So here is my rationale for removing the current completion code.

• I've actually never gotten Helm-SLIME completion to work with SLIME. Maybe I did something wrong.

• It does not work with SLY.

• It's quite a lot of (non-obvious) code which duplicates the functionality of company+helm-company, so why bother :p

Thoughts?

[joaotavora]

I don't fully agree on dynamic completion used in sly

You're of course free to hold that opinion, but let me tell you the completion in SLY is in that respect as close as you will get to a proper use of Emacs completion interfaces as you will find. They are absolutely not easy to use, but it's what we have. Soon I'll start dicussion to migrate that part of SLY into Emacs itself. If Helm starts "behaving" better then we will be able to mix and match between frontends (normal, ido, icomplete, company) and backends (sly, eglot, simple lists, etc...) and avoid these kinds of issues.

[joaotavora]

and avoid these kinds of issues

Also we should avoid the need for these helm-whatevers altogether (but nothing against this one, of course).

[Ambrevar]

To clarify, this front end brings the following to SLY:

• Completion on a listing of of the connections and related buffers, like slime-selector command (I don't think SLY has this).
• Completion in Xref buffers.
• Completion in Apropos.
• Completion over history (for SLY, that's actually handled by helm-comint).

I agree that there should be no need for a Helm-SLIME / Helm-SLY, so we would need to make all those parts use Emacs completion instead of dedicated buffers. Or at least have an option for both.

[Ambrevar]

@joaotavora: Interested in bringing completion to every part of SLY? Would be neat indeed! ;)

[thierryvolpiatto]

How do you get SLY completion to work with Helm? I could not figure it out from the discussion you've linked.

Turn off sly completion mode (don't remember the exact name).

I prefer you make another package helm-sly and keep helm-slime as it is.

[Ambrevar]

OK, thanks for confirming, I'll work on it.

[Ambrevar]

Oh! You are right, when I turn off sly-symbol-completion-mode, it works perfectly! It's actually better than with company, because it includes the prefix.

@joaotavora: You mentioned something that was not working right with Helm, but at this point everything seems to work perfectly (I see the percentage and the prefix).

[joaotavora]

You mentioned something that was not working right with Helm, but at this point everything seems to work perfectly (I see the percentage and the prefix).

I'm pretty sure you won't be able to correctly narrow down and widen the completions, and you won't get the correct flex completion behaviour. But if a tree falls in a forest and noone is around to complain about a bug ;-)

[Ambrevar]

I don't understand how to narrow down and widen with SLY's "flex" completion. Can we?

If not, what are you personally expecting to happen for a completion framework like Helm with SLY? Can you provide a precise recipe?

By the way, I found out another difference in behaviour between pure Helm and Helm-Company: pure Helm won't show anything on "quiloa", while Helm-Company will show "quickload" among other things.

[joaotavora]

I don't use Helm it's kind of heavyweight, funny faces and keybindings and many flashing things. I tried it briefly when I was convincing Thierry to properly support Emacs completion interfaces. I think the issue I started had a couple of examples down the road.

By the way, I found out another difference in behaviour between pure Helm and Helm-Company: pure Helm won't show anything on "quiloa", while Helm-Company will show "quickload" among other things.

There's your example (though there are probably more). That's probably because helm-company is using company as an intermediary, and company-capf (which is a part of company) does comply with Emacs completion interfaces. So, by travelling a long route, it somehow ends up doing the right thing in some cases, I guess.

So if it works for you, I suggest you use helm-company only.

Anyway, Emacs completion interfaces are really hard to program to, and Helm is already very complicated, so I don't blame Thierry for not wanting to do this. Perhaps one of the two will become easier to use in the future.

[joaotavora]

@Ambrevar, here's one of the comments where I try to explain exactly what happens with Helm and Sly that I think shouldn't happen:

https://github.com/emacs-helm/helm/issues/2165#issuecomment-506983203

To be clear, if you're not bothered by this at all, then don't worry and go on with your life :-)

[Ambrevar]

OK, thanks for confirming.

Off-topic: I recommend you try playing with Helm a little more, customizing the faces you don't like and the keybindings (it's Emacs after all, you can customize everything). If you don't enable helm-mode, Helm is fully non-intrusive. Helm empowers you in ways that no other Emacs component / package can, it's worth the shot I believe ;)

[joaotavora]

hehe, yes I know, it makes me feel i'm inthe matrix or a TV show or something like that. I use to like that stuff, too, but now I prefer the barest Emacs possible and a console. Things change ;-)

[Ambrevar]

OK, I think I'm starting to understand, still missing a piece of the puzzle though.

Using Sly's default completion, how do you

explore the whole domain, the whole set/space of completions, in the following way:

• Without exiting the completion interface, or whatever you want to call it.
• Without ever having to compute the whole set upfront.

?

If I press M- after "quiloa", I see the completion buffer for "quiloa". How do I "explore the whole domain" from there?

Sidenote: The "backspace on prefix" issue has been fixed.

[thierryvolpiatto]

Pierre Neidhardt notifications@github.com writes:

I don't understand how to narrow down and widen with SLY's "flex" completion. Can we?

If not, what are you personally expecting to happen for a completion framework like Helm with SLY? Can you provide a precise recipe?

By the way, I found out another difference in behaviour between pure Helm and Helm-Company: pure Helm won't show anything on "quiloa",

(setq helm-completion-in-region-fuzzy-match t)

while Helm-Company will show "quickload" among other things.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.*

-- Thierry

Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[Ambrevar]

(setq helm-completion-in-region-fuzzy-match t)

It works, awesome! ;)

[thierryvolpiatto]

Pierre Neidhardt notifications@github.com writes:

I don't understand how to narrow down and widen with SLY's "flex" completion. Can we?

If not, what are you personally expecting to happen for a completion framework like Helm with SLY? Can you provide a precise recipe?

He is expecting that Helm use a dynamic function that use the backend completion engine, we could use this (I have a branch doing this) at the cost of loosing helm match functions that are way more better than most backend completions, at least emacs one.

-- Thierry

Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

[joaotavora]

He is expecting that Helm use a dynamic function that use the backend completion engine, we could use this (I have a branch doing this) at the cost of loosing helm match functions that are way more better than most backend completions, at least emacs one.

I have no doubt that some of the Helm functions might be very sophisticated and useful. But they need to be able to fetch the whole set of possible completions to work correctly. When completing Emacs symbols (and in some other cases like file-names) this is doable directly, but in the general case, it's not, because the backend fetcher is constrained in some way of another (the case of LSP, for example).

And that's why Emacs has those scary and complicated all-completion, test-completion, etc interfaces and also that completion-styles and categories thing. It's not pretty, but it works and lets the frontend and backend work correctly. Time permitting, I think Stefan Monnier will help you if you ping him directly.

For example, I recently added "flex" completion to Emacs's 27 completion-styles-alist variable. This had, as a consequence, the reasonably wonderful benefit that normal completion, icomplete and company now support flex completion. You could add those matching functions to completion-styles-alist too (you don't have to do it in Emacs core lisp/minibuffer.el, they can still live in the Helm codebase).

[joaotavora]

If I press M- after "quiloa", I see the completion buffer for "quiloa". How do I "explore the whole domain" from there?

With M-<tab> which I suppose is the normal completion-at-point frontend you don't have this problem, and indeed the question does not apply, because that frontend doesn't "trap" you in its interface. But Helm and Company do that. Company starts expanding the domain when you backspace to qui, for example, and Helm doesn't.

[Ambrevar]

With M-<tab> which I suppose is the normal completion-at-point frontend you don't have this problem, and indeed the question does not apply, because that frontend doesn't "trap" you in its interface. But Helm and Company do that. Company starts expanding the domain when you backspace to qui, for example, and Helm doesn't.

Indeed. @thierryvolpiatto: Would it be possible to recompute the list of candidates when "backspacing" on the prefix? It could be made an option, since I understand it might not be something for everyone.

[joaotavora]

Would it be possible to recompute the list of candidates when "backspacing" on the prefix?

I'll let Thierry answer that, but IMO that wouldn't be a very good solution. It's not just the backspacing that may cause the domain to grow. If you are using some kind of regexp completion style, then adding something like .* also makes the domain grow. So you must be more criterious when you need to call the backend to recompute candidates.

[Ambrevar]

I've created a Helm-SLY repo: https://github.com/emacs-helm/helm-sly/. It seems to be working well.

I'll backport some fixes to this repo later. I'll create a MELPA request just now.

Thanks for your feedback @thierryvolpiatto @joaotavora.

[thierryvolpiatto]

João Távora notifications@github.com writes:

He is expecting that Helm use a dynamic function that use the backend
completion engine, we could use this (I have a branch doing this) at the
cost of loosing helm match functions that are way more better than most
backend completions, at least emacs one.

I have no doubt that some of the Helm functions might be very sophisticated and useful. But they need to be able to fetch the whole set of possible completions to work correctly.

No, not necessarily.

And that's why Emacs has those scary and complicated all-completion, test-completion, etc interfaces and also that completion-styles and categories thing. It's not pretty, but it works and lets the frontend and backend work correctly.

Correctly, no more. At least all-completions have a bug to let e.g. flex working properly, I had to force completion-table-dynamic to not use all-completions.

For example, I recently added "flex" completion to Emacs's 27 completion-styles-alist variable. This had, as a consequence, the reasonably wonderful benefit that normal completion, icomplete and company now support flex completion. You could add those matching functions to completion-styles-alist too (you don't have to do it in Emacs core lisp/minibuffer.el, they can still live in the Helm codebase).

I have a branch supporting flex and backend completion-styles, it works as well on the whole set of candidates (you can delete the prefix and write something else withut quitting). But, I have to say that e.g. flex is not usable yet as helm-fuzzy-matching is and the only benefit of this branch is allowing to complete the whole set of candidates as you asked. I will may be add a variable in helm (something like helm-completing-styles) which will allow two value, emacs and helm to allow using emacs completion with its styles or plain helm.

-- Thierry

Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997