Query can be restarted multiple times

[minad]

When pressing C-c RET on a headline multiple times, it seems possible to restart the query. This does not seem desired. It would be better if gptel prints an error message if a query is already running and hasn't completed yet.

[karthink]

Yes, this needs to be fixed. I think multiple queries from one buffer is fine -- for example if you are in a non-dedicated (i.e. regular) buffer and want to ask multiple unrelated queries:

How many satellites are in orbit around the earth?

What is speedrunning in videogames and when did this practice begin?

You can select each line and call gptel-send. However, we want to avoid sending the same request multiple times. I'll create a list of hashes (buffer-local) for currently active queries and check against that. If you have a better idea please let me know.

[minad]

I think it is okay to keep it simple and just allow a single requetat a time, since the API is not fast anyway.

[karthink]

My reason for enabling multiple parallel requests per buffer is because the API is not fast. That said one request per buffer is a simpler solution, I can implement it and see if it feels limiting in usage.

[minad]

Sure, but I usually start a query and then refine the prompt. Starting multiple independent queries seems only useful if you run multiple "conversations" in parallel. There is also the danger of hitting some rate limit. Maybe each gptel buffer could run independently.

[guibor]

@karthink perhaps it would be possible to configure a gptel-send-hook variable, and for anyone interested in avoiding multiple parallel queries it would be possible to add a gptel-abort to the hook?
It would be imperfect as it would not be buffer-specific but users could configure that, or even make the hook local to certain types of buffers (e.g if using the gptel conversational buffer it is more likely that this behavior would be desired)

[karthink]

@guibor here is a recipe for disallowing multiple requests from one buffer -- only works with Curl though:

(defun gptel-throttle-request (orig-fn &rest args)
  (require 'gptel-curl)
  (if (seq-some (lambda (request)
                  (eq (current-buffer)
                      (plist-get request :buffer)))
                (map-values gptel-curl--process-alist))
      (message "gptel request cancelled: there is an active request in buffer %s"
               (buffer-name (current-buffer)))
    (apply orig-fn args)))

(advice-add 'gptel-request :around #'gptel-throttle-request)

I can add it as an option to gptel but it needs more work to support url-retrieve.

[guibor]

Hi @karthink this is really awesome and seems to work really well.

I have one issue though: if I add the advice before my first query, I get the following error:
seq-some: Symbol’s value as variable is void: gptel-curl--process-alist

So I need to remove the advice, use gptel-send at least once, and only then add the advice back.
Does this make sense? Any reason why?

(Thanks again for all your amazing work!)

[karthink]

So I need to remove the advice, use gptel-send at least once, and only then add the advice back.

It's because gptel-curl.el is not loaded until required. Adding a (require 'gptel-curl) into the mix should fix it. (Updated above).

[karthink]

Closing this issue since, with the benefit of hindsight, there are many uses for gptel where it is desirable to have more than one request active in a buffer.