-
Notifications
You must be signed in to change notification settings - Fork 21
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
Async completion at point #42
Comments
Unfortunately as far as I can tell, async completion is only available in It's been a while since I looked into it tho; it's possible things have improved since then. |
Yeah! I feel the same. I don't know (yet).
What do you think about this. In the moment that we are trying to get those
candidates, maybe there is a way of saying, or better, passing the
information about which buffer we are placed. Could the nrepl protocol
allow this?
I mean, like saying sorry for my stupidity, please tell me in the future
where I need to do this. Then in the callback we can look for that buffer
name, and act directly on it by switching.
Does it makes sense to you?
…On Tue, Oct 11, 2022, 02:01 Phil Hagelberg ***@***.***> wrote:
Unfortunately as far as I can tell, async completion is only available in
company.el, that is, a 3rd-party library. I don't know of any way to do
this correctly without adding a dependency. =(
It's been a while since I looked into it tho; it's possible things have
improved since then.
—
Reply to this email directly, view it on GitHub
<#42 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEYKOVHJB42PBYZ4YRYVZVTWCTYCXANCNFSM6AAAAAARB36VHY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Hey Benjamín, thanks!
Benjamín Buccianti ***@***.***> writes:
Yeah! I feel the same. I don't know (yet).
What do you think about this. In the moment that we are trying to get those
candidates, maybe there is a way of saying, or better, passing the
information about which buffer we are placed. Could the nrepl protocol
allow this?
I mean, like saying sorry for my stupidity, please tell me in the future
where I need to do this. Then in the callback we can look for that buffer
name, and act directly on it by switching.
Does it makes sense to you?
I'm not sure I'm following you here :)
|
Oh it's really hard to explain what I'm trying to think. Please forgive me
and be patient :)
Every time we send a message to the nrepl server we are making a callback
function. This callback it's being called and processed only while on the
Monroe connection buffer or something like that.
I feel that we can send in the message on which buffer completion at point
it's getting called. And then, in the callback function, switch to that
buffer in order to show the candidates.
Does that make sense to you?
Please let me know.
…On Tue, Oct 11, 2022, 06:28 Sanel Z. ***@***.***> wrote:
Hey Benjamín, thanks!
Benjamín Buccianti ***@***.***> writes:
> Yeah! I feel the same. I don't know (yet).
>
> What do you think about this. In the moment that we are trying to get
those
> candidates, maybe there is a way of saying, or better, passing the
> information about which buffer we are placed. Could the nrepl protocol
> allow this?
>
> I mean, like saying sorry for my stupidity, please tell me in the future
> where I need to do this. Then in the callback we can look for that buffer
> name, and act directly on it by switching.
>
> Does it makes sense to you?
I'm not sure I'm following you here :)
—
Reply to this email directly, view it on GitHub
<#42 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEYKOVGB7IQ55QVJEIFZNXTWCUXL3ANCNFSM6AAAAAARB36VHY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
It makes sense, but in order to do this you have to basically reinvent your own completion command from scratch. It would be better to provide a source of completion data that can be used by an existing completion command. That's how On the other hand, |
First thank you @sanel for everything that you did with Monroe. Is the best package that I have installed on my emacs.
Regarding the completion, I feel like we can improve the last addition. Right now, I figured out that in order to use the nrepl protocol for getting the candidates words we needed to use a sync request. Because when the callback it's returning those candidates we are in the connection buffer.
I feel that there is a way to avoid this situation but I'm still thinking and can't find one. Cider does it too, but send to me that getting async would be better.
Can you help me to think about this issue?
@technomancy please I want to know what you think about it too.
Thank you very much.
The text was updated successfully, but these errors were encountered: