Merging gptel branch and main branch

[ahmed-shariff]

This PR merges the separated gptel branch with the main branch. To support both llm and gptel, this also adds a customizable variable magit-gptcommit-backend which is expected to be either llm or gptel. It also removes the respective require calls, as this would expect the user to have one of the packages configured (see magit-gptcommit--ensure-backend-loaded). I have also updated the readme accordingly. Let me know what you think.

Note: to keep up with the main branch, I had been cherry-picking commits and applying them to a branch maintained in my fork. Hence why the merge history shows some of the commits already merged to master.

[ahmed-shariff]

I have tested this with gptel and it works as expected. I haven't configured llm, and I am not familiar with how it works. It'd be nice if someone could test that.

[ahmed-shariff]

Forced pushed with a cleaner history and minor cleanup

[LemonBreezes]

Before merging this one I would like for #28 to be reviewed since it's such a huge change that fixes critical bugs.

[jiacai2050]

Any luck on this?

[LemonBreezes]

Any luck on this?

It works perfectly for me and @douo hasn't followed up. Please check it out and post what you think. I may merge it if you don't encounter any issues.

[jiacai2050]

Thanks for you quick response, I will try this PR on my machine.

[LemonBreezes]

Thanks for you quick response, I will try this PR on my machine.

Oh my bad! I thought this was a comment for the other PR.

[jiacai2050]

Oh my bad! I thought this was a comment for the other PR.

Aha, no concerns, I'll proceed with this PR nonetheless.

[ahmed-shariff]

Before merging, can you guys check if this works as intended?

[jiacai2050]

(use-package magit-gptcommit
  :load-path "~/misc/magit-gptcommit/"
  :bind (:map git-commit-mode-map
         ("C-c C-g" . magit-gptcommit-commit-accept))
  :commands (magit-gptcommit-generate)
  :custom
  (magit-gptcommit-backend 'gptel)

  :hook (magit-status-mode . 'my/enable-gptcommit)
  :init
  (defun my/enable-gptcommit ()
    (interactive)
    (magit-gptcommit-mode 1)
    (magit-gptcommit-status-buffer-setup)))

This is config I tested, and this PR works totally fine for me!

[LemonBreezes]

Ok. So I want to know, what benefit do you get from depending on gptel instead of llm? LLM seems closer to what we need, just streaming from the model.

[ahmed-shariff]

I, for example, have only gptel setup and configured. Which was what led to this PR.

LLM seems closer to what we need, just streaming from the model.

I am not sure what you mean here? As far as I understand, the two packages (llm/gptel) do the same thing, just have different ways of going about it.

[LemonBreezes]

I, for example, have only gptel setup and configured. Which was what led to this PR.

LLM seems closer to what we need, just streaming from the model.

I am not sure what you mean here? As far as I understand, the two packages (llm/gptel) do the same thing, just have different ways of going about it.

Okay but the Emacs byte compiler optimizes better when it sees the definitions of the functions while it's compiling so if you extern the function calls rather than having a hard requirement, it produces worse code. So it's better to just stick to one. There is little harm in having LLM around.

Besides, honestly, there isn't really a canonical AI/LLM package for this. Most people just use Claude Code or another AI assistant like Pi. And local LLM sadly kind of sucks so we have to stream our AI from the cloud anyways.

[ahmed-shariff]

Fair comment about the byte compiler. I myself don't fully understand how that works, so I'll defer to others on the topic.

I have alot of other features I use that is built on top of gptel, which is why I have stuck with it. Then again I haven't tried llm in a long while, maybe it's time I try that a bit more. That being said, if there's no interest in merging this, I can understand. I don't mind using a fork for my personal use.

[LemonBreezes]

Fair comment about the byte compiler. I myself don't fully understand how that works, so I'll defer to others on the topic.

I have alot of other features I use that is built on top of gptel, which is why I have stuck with it. Then again I haven't tried llm in a long while, maybe it's time I try that a bit more. That being said, if there's no interest in merging this, I can understand. I don't mind using a fork for my personal use.

Well, the code is here for anyone that wishes to use it. Keep an eye out for any technical reasons to prefer gptel over llm.

[ahmed-shariff]

Will do. To clarify, for the purposes of this package, both llm (with llm-chat-streaming) and gptel (with gptel-request) do the same thing. That is all that is needed from either package; gptel comes with alot more functionality outside the API to communicate with LLMs. For someone who donesn't need the extra functionality, gptel is not necessary.