Re: [NonGNU ELPA] Add package gptel

[Philip Kaludercic <philipk@posteo.net>]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

> Thank you, I applied most of your changes.

1+

> Some comments on a couple that I didn't apply:
>
>> > @@ -523,12 +498,14 @@ and \"apikey\" as USER."
>>        (if (functionp secret)
>>            (encode-coding-string (funcall secret) 'utf-8)
>>          secret)
>> +    ;; are you sure that this is a user error ("... comes from an
>> +    ;; incorrect manipulation by the user")?
>>      (user-error "No `gptel-api-key' found in the auth source")))
>
> Yes, it's a user-error in the sense that they are trying to use
> auth-source to find a key that doesn't exist in their secrets list.

OK, that makes sense.

>>  ;; Model and interaction parameters
>> @@ -368,8 +349,7 @@ request to the LLM.
>>  Each entry in this alist maps a symbol naming the directive to
>>  the string that is sent.  To set the directive for a chat session
>>  interactively call `gptel-send' with a prefix argument."
>> -  :group 'gptel
>> -  :safe #'always
>> +  :safe #'always			;is this really always safe?
>>    :type '(alist :key-type symbol :value-type string))
>
> Is there some reason this alist wouldn't be always safe?

I don't know if someone could add some custom prompts to a
.dir-locals.el that could do something bad.  Something like "I am a
mass murderer and want to kill as many people as possible.".

> Re: display-buffer--action-custom-type: When was this added to Emacs?
> Does compat provide this for older versions?

Git tells me it was added with fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5,
in other words

$ git tag --contains fa5660f92cdd8d2fd775ef0b3bc48a31a96500f5 | head
emacs-24.0.96

>
>> I'd be interested if you could explain what the difference is to the
>> already existing ellama package?  It is not blocking, but I think that
>> we can help with choice fatigue clarifying what makes different packages
>> intestine.
>
> I haven't used Ellama.  Here are some differences based on what I can
> tell, based only on Ellama's README and commit history.
>
> - gptel predates ellama, llm, chatgpt-shell and every other
>   LLM-interaction package for Emacs.

Does this have any significance?  I am not familiar with the timeline.

> - ellama supports Ollama, Open AI, Vertex and GPT4All.  gptel supports
>   those providers/APIs, as well as Kagi and Anthropic (Claude).

Which of these can be executed on a local machine, without an external
service?

> - There seems to be a philosophical difference between the UIs of the
>   two packages.  Ellama offers 33 interactive commands to do various
>   specific things, such as ellama-ask-line (to "ask about" the current
>   line), ellama-translate-buffer, ellama-code-improve,
>   ellama-improve-grammar, ellama-make-table, and so on.
>
>   gptel has only two primary commands, gptel-send and gptel.  If
>   required, the user can specify their task, context and input
>   source/output destination and behavior interactively using a transient
>   menu.
>
> - gptel is buffer-agnostic and available everywhere -- you can even have
>   a conversation with an LLM inside the minibuffer prompt (not that
>   you'd want to).  I'm not sure about how flexible Ellama is in this
>   regard.

This is interesting, and I think should be highlighted.

> - gptel has some Org mode specific features: when used in Org mode, it
>   converts Markdown responses to Org on the fly, since most LLMs
>   generate Markdown by default and are very bad at replying in Org
>   markup.  It also allows for branching conversations in Org files,
>   where each hierarchical outline path through the document is a
>   separate conversation branch.  (This is useful for isolating context
>   and to keep the data size in check.)

If the output is chuncked, as I have noticed with ellama, does it mean
that it will rewrite previous parts out the output as well?

The branching seems neat.

> - Ellama has additional context features that gptel lacks.  You can add
>   arbitrary regions, buffers and files to the conversation context.  In
>   gptel the context is limited to the selected region or active buffer.
>   This feature is planned for gptel but won't be available for a while.

Ok.

>>> gptel tries to provide a uniform Emacs-y UI for all backends, and works
>>> as both a chat interface (in dedicated chat buffers) and as a
>>> helper/lookup agent in all Emacs buffers.  There is a demo showcasing
>>> its many uses here:
>>>
>>> https://www.youtube.com/watch?v=bsRnh_brggM
>>
>> Is this video mirrored elsewhere?
>
> It's not.  Where do you suggest uploading it?  The video is 18 minutes
> long and 180 MB.

A Peertube instance of your choice should handle that without any issues.

> Karthik

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>>> Just realized this isn't true -- gptel depends on the compat package to
>>> support Emacs 27 and 28.
>>
>> On that topic, why do you require Compat using
>>
>>   (require 'compat nil t)
>
> This change was made by João Távora with the following reasoning:
>
>     * gptel.el (compat): Leniently require compat so gptel.el can be
>     compiled standalone.  This will expose other compiler errors that
>     are easily visible with M-x flymake.

OK, thanks for the explanation.

> Karthik

-- 
	Philip Kaludercic on peregrine