gptel asks user to select a buffer if many are open

[algal]

This commit modifies the behavior of the gptel function so that, in the case where the function is called interactively, and multiple gptel sessions already exist (as judged by there being multiple buffers with the minor mode gptel-mode enabled), then the function prompts the user to select one of those buffers.

This replaces the previous behavior in this case, which was just to switch to the buffer named backend-name if it already existed, or else to create a new buffer with that name.

So, after this comit, the gptel function behaves as follows:

• (NEW). When called interactively and multiple gptel-mode buffers exists, it prompts the user to choose a buffer to switch to.

• when called interactively and no gptel-mode buffers exist, it creates a buffer named backend-name

• when called interactively and 1 gptel-mode buffers exists, it switches to the buffer named backend-name or creates it if it does not exist.

• when called interactively with a prefix arg, it behaves as before, and prompts the user to acknowledge or input the name of a buffer to create.

• when called programmatically, it behaves as before.

[karthink]

@algal This looks good. After trying it for a bit, I think we can simplify the behavior of M-x gptel:

• M-x gptel always brings up a completing-read interface (without the REQUIRE-MATCH arg), with the default input being the backend-name, and the completion options being other gptel buffers.
• This means M-x gptel will always require an additional press of the RET key, but that annoyance might be worth it. I'm assuming that most people want to set a suitable buffer name for the chat (that isn't *backend-name*) anyway.
• Pressing RET with no input/selection returns backend-name.

You also don't need to use seq-filter to find the candidates then, and the completing-read will be replaced by

(read-buffer "Create or choose gptel buffer: "
             backend-name nil                         ; DEFAULT and REQUIRE-MATCH
             (lambda (b)                              ; PREDICATE
               (buffer-local-value 'gptel-mode
                                   (get-buffer (or (car-safe b) b)))))

The prefix-arg behavior will then be unnecessary, and we can use it to bring up a transient menu where the user can choose the gptel buffer name, backend, system message and other model parameters to use in the new session. This is a feature that's been asked for a couple of times, and I can add it after this PR.

What do you think?

[algal]

@karthink Yes, I think the behavior you describe is better than what I proposed in my original PR. My new commits above implement what you describe, based on your code snippet, and this feels like a better user experience. (Of course, please feel free to just to implement as you like if you want to keep your history clean.)

I also like the consistency of the second idea -- of using the prefix arg for gptel to bring up roughly the same transient menu which is now available when the user invokes gptel-send.

I think this would be especially handy for selecting a system directive early, since usually you know what kind of assistance you require at buffer-creation time, even if you might want to experiment with different models at query-submission time.

I suppose it would have to be only roughly the same transient menu, since it looks like some of the options there now would not make sense when creating a buffer.

[karthink]

Please revert this change, the version stays unchanged.

[algal]

@karthink Fixed with commit 3a748f5. Sorry, didn't mean to commit that originally. That's my hack to use package-install-file to ensure an installed dev branch supersedes the melpa branch.

[karthink]

Looks good! Will merge after you fix the version change.

I suppose it would have to be only roughly the same transient menu, since it looks like some of the options there now would not make sense when creating a buffer.

Yeah, I can't reuse the menu, I'll have to reuse some of the pieces to make a new one.

[karthink]

Looks good, merging. Thanks for the PR!