search

sanel / monroe

Clojure nREPL client for Emacs
161 stars 21 forks source link

Async completion at point #42

Open bbuccianti opened 2 years ago

bbuccianti commented 2 years ago

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.

technomancy commented 2 years ago

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.

bbuccianti commented 2 years ago

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 https://github.com/sanel/monroe/issues/42#issuecomment-1274090953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYKOVHJB42PBYZ4YRYVZVTWCTYCXANCNFSM6AAAAAARB36VHY . You are receiving this because you authored the thread.Message ID: @.***>

sanel commented 2 years ago

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 :)

bbuccianti commented 2 years ago

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 https://github.com/sanel/monroe/issues/42#issuecomment-1274398892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEYKOVGB7IQ55QVJEIFZNXTWCUXL3ANCNFSM6AAAAAARB36VHY . You are receiving this because you authored the thread.Message ID: @.***>

technomancy commented 2 years ago

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.

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 completion-at-point works; you provide it with a function which can give you completion candidates, but only synchronously. If you give it an async function, the completion command will already have returned by the time the result is ready.

On the other hand, company can be provided with a completion-source function which works asynchronously. But it's not built-in to Emacs. So there's a trade-off.