Fix race conditions

[LemonBreezes]

This is a preview of what is to come. I removed the magit-inhibit-refresh call and fixing that underlying issue without locking the buffer somehow was EXTREMELY difficult. This code seems to be working at first glance but I will test it and possibly make some nit-picks.

Had to add comprehensive debugging output to handle this one.

EDIT: The code seems to be working. I've been using it for a few days, 0 problems.
Closes #16.

[LemonBreezes]

@douo Hey can you test this one out for a bit before merging. It's really complex.

[douo]

That’s a big PR—thanks a lot! I’ll try to test it soon.

[douo]

This PR includes significant refactoring and improvements. Since I’ve been away from the project for a while, I found it a bit difficult to fully understand all the changes — and to be honest, I’m still trying to catch up.

I’ve done some basic testing, and the core functionality seems to work well. However, I noticed a potential issue with the streaming output: the Waiting state lasts for quite a while, and the Typing state flashes briefly before it quickly jumps to DONE. @LemonBreezes Could you take a look when you get a chance?

[LemonBreezes]

This PR includes significant refactoring and improvements. Since I’ve been away from the project for a while, I found it a bit difficult to fully understand all the changes — and to be honest, I’m still trying to catch up.

I’ve done some basic testing, and the core functionality seems to work well. However, I noticed a potential issue with the streaming output: the Waiting state lasts for quite a while, and the Typing state flashes briefly before it quickly jumps to DONE. @LemonBreezes Could you take a look when you get a chance?

That sounds normal. That might be because you are using an LLM that takes a long time to respond. What LLM are you using? I don't notice it with Claude 3.7.

[LemonBreezes]

It's not really possible to do this in a small change either because we are removing the lock on the magic buffer so a lot of problems arise with the asynchronous LLM requests returning out of order and caching and the user modifying the buffer, etc.

[ahmed-shariff]

Since I don't have llm setup, I tried merging it with #29 and tried it with gptel. It works well. even after merging. When this PR goes through, I'll merge the changes in #29 as well.

I have one clarification: if I generate a message with G, accept (C) then quit the commit with C-c C-k, the generated message is erased (i.e., "GPT commit" magit section is removed). This is by design?

[LemonBreezes]

Since I don't have llm setup, I tried merging it with #29 and tried it with gptel. It works well. even after merging. When this PR goes through, I'll merge the changes in #29 as well.

I have one clarification: if I generate a message with G, accept (C) then quit the commit with C-c C-k, the generated message is erased (i.e., "GPT commit" magit section is removed). This is by design?

Yes. The message is removed when you accept it, we do not check if the message was aborted. The commit message is cached so if you regenerate it, that will not require calling the LLM.