Modifying the history like this seems like a cursed solution, guaranteed to bite us in the back in the future when Transient updates. I'd like to make the value of the provider infix be a string (the backend name or backend-name:model-name), then the problem should disappear for good. Any idea if we can do that? I haven't looked at this code in a while.

I agree it feels like a hack, OTOH not sure how it could break even more, since I don't think the actual semantics completing-read would change in Emacs. Perhaps it would be good idea to store the provider as a string but it's bit complicated right now.

Transient closed magit/transient#172 without fixing transient.el.

Do you agree with the second fix? Now if the user does C-u M-x gptel-send RET -m RET, it causes the error "transient-setup: Wrong type argument: gptel-backend, nil" and there is no second chance to change the model using the transient menu. Not very likely scenario, but perhaps the user looks what available by hitting TAB and then decides that she is okay with the currently selected model after all, and assumes hitting RET to an empty prompt will just get her back to the menu without changing anything. That actually happened to me once, that's how I noticed this problem.

I fixed the main issue at the source just now. Please test. The commit message explains the fix.

Let's leave this PR open to fix the completing-read default value problem.

Okay this kinda works, but if you don't pass the history argument to completing-read, hitting the arrow down or M-n does not really go through the actual history elements but apparently all available completions? And if you do pass it, transient will store the history as strings instead of symbols. Somehow I get the feeling that transient don't like anything else than strings in the history.

but if you don't pass the history argument to completing-read, hitting the arrow down or M-n does not really go through the actual history elements but apparently all available completions?

Even if we did pass a history variable, I don't think it would work, would it? What's being stored is in the history file is not what we read from completing-read. To make it compatible the gptel-provider-variable class needs to be modified some more. Its value should be exactly the string that's read by completing-read, and it should have two four additional slots :backend, :backend-value, model and model-value for managing the actual backend structure and model.

I can merge this for now and add a TODO, but first could you verify that the correct buffer-local value of the backend and model are being set if you press RET without a selection? I remember having some trouble, with the values in the transient buffer being chosen instead of the values in the main buffer, i.e. transient--original-buffer.

Even if we did pass a history variable, I don't think it would work, would it? What's being stored is in the history file is not what we read from completing-read. To make it compatible the gptel-provider-variable class needs to be modified some more. Its value should be exactly the string that's read by completing-read, and it should have two four additional slots :backend, :backend-value, model and model-value for managing the actual backend structure and model.

Yeah, perhaps not worth the effort, at least as a v0.9.8 goal Though I can imagine history being somewhat useful when switching between couple of models.

I can merge this for now and add a TODO, but first could you verify that the correct buffer-local value of the backend and model are being set if you press RET without a selection? I remember having some trouble, with the values in the transient buffer being chosen instead of the values in the main buffer, i.e. transient--original-buffer.

Yes, if I understand this right, it restores the same model that is displayed in in the transient as the current model, even if I switch between buffers with different buffer-scope models.

I was thinking if it should reset it to the standard or customized value of gptel-model instead, but somehow it does not feel quite right -- at least it should be somehow indicated in the prompt I think to avoid surprises.

Anyway, I doubt this is a very common use case, it is just a way of making sure the user won't end up in a state where the transient no longer can be accessed without manually changing the variable or restarting Emacs.

Sounds good, I can circle back to improving the gptel-provider-variable class eventually.

I'm going to fix the send-region + gptel-org bug next and publish 0.9.8.