Closed tmalsburg closed 1 year ago
I would use this in other buffers not in the gptel buffer. For instance, to create an empty org mode table with 10 rows and 5 columns. The result of the request should then be inserted at point. So this is not a conversation scenario but for one-off requests.
For instance, to create an empty org mode table with 10 rows and 5 columns. The result of the request should then be inserted at point.
Can't you do this in the current buffer itself? Type in the prompt, select the line (or not depending on #19) and call gptel-send
-- this will insert the org-table/response at point.
Can't you do this in the current buffer itself?
I can but then I have to go back to the prompt and delete it. Too much friction.
The problem with GPT integration into Emacs workflows is that the API is pretty slow already and any additional slowdowns make using GPT less attractive.
another interesting idea with a prompt: Refactoring.
You select a region, M-x gptel-refactor, in a prompt you tell how to refactor/what to change and the region is replaced.
I like it! Could even be the same function for both use cases: If a region is active, refactor that region. If no region is active, just use the prompt. Perhaps it will also be possible to write the refactor feature such that it works with code and with text. (I use GPT mostly to refactor text, e.g., quick notes -> spelled out text).
It would be nice if there were a function like this:
(defun gptel-on-region (start end header &optional replace)
)
It is analogous to the built-in call-process-region
function, and the arguments are defined as follows:
start
and end
specifies the bound of the body which should be usually region-beginning
and region-end
.header
is a text prepended to the prompt passed to the API. It can be an instruction such as "refactor this code", "describe this function", "translate this text", etc.replace
is non-nil, the region will be replaced with the API response. Otherwise, the function will return the response, so the user of the function can use it to his/her liking.With this function, the user can define a custom command easily. The benefit of integrating with this package is that the user can configure API parameters using the transient interface. Transient allows the user to customize commands using transient-append-suffix
, etc., so it would be possible for the user to add custom commands to gptel-send-menu
and so on.
@tkfv The idea is great but I'm wary of adding a bunch of gptel-*
commands. Refactoring isn't a distinct action as far as ChatGPT is concerned, it's just a different prompt/system message. So what's needed is a more convenient way to select the message from the transient menu. I'll add the option to replace the selected region with the results to the menu as well.
On that note, do you have a working example of a prompt that makes ChatGPT return only the rewritten code? Every prompt I've tried results in markdown-formatted code + an explanation.
So what's needed is a more convenient way to select the message from the transient menu.
I would want to have a function suggested in https://github.com/karthink/gptel/issues/20#issuecomment-1489170520. This will let the user define a bunch of custom commands to fit one's own needs.
With this function, it is easy to define the command discussed in this thread:
(defun gtpel-send-region (replace)
(interactive "P")
(gptel-on-region (region-beginning) (region-end)
(completing-read "Select an action: " gptel-region-actions)
replace))
On that note, do you have a working example of a prompt that makes ChatGPT return only the rewritten code? Every prompt I've tried results in markdown-formatted code + an explanation.
Last time I tried something like this "Answer only with the code, no prose" and the prose was gone. I tried to also avoid the wrapping ```
s but it was hopeless. So it's probably better to let it do it and unwrap it automatically.
With this function, it is easy to define the command discussed in this thread:
gptel's intended behavior is simple:
i.e. just like the web UI.
But between this thread, #30 and others, I've had requests for all possibilities:
I can't support all of these (even with the transient menu), so I'll try to add something like gptel-send-region
, but more general where you can write some elisp to use whatever input and destination you want. The async requirement means it won't be as simple as calling a function, you'll have to supply both a caller (to read the prompt) and a callback (to insert the output).
more general where you can write some elisp to use whatever input and destination you want
It would be nice if there were a slightly lower API than gptel-send
that allows a custom payload and callback! A function like gptel-on-region
is nice to have, but what I wish is to reuse the API communication part of this package as much as possible. This package provides a nice streamlined experience as well as configurability with the transient interface, and nobody would want to re-implement most of it.
It would be nice if there were a slightly lower API than gptel-send that allows a custom payload and callback!
I'm almost there, I'll finish up the API when I next have time to work on it. The only problem with this arrangement so far has been getting the transient menu options to change dynamically.
@akirak I've added gptel-request
, an API for defining custom behavior. Please see the wiki.
Let me know if you have any feedback.
@karthink Great! The API looks nice. Thank you for making this great package.
@tmalsburg
Option 1
Added transient flags to choose whatever source and destination you need:
Option 2
For faster access, you can write your own wrapper around gptel-request
. Please see the wiki.
I'm closing this now, but if you have suggestions on further tweaks to the design for accepting prompts from the minibuffer please post them below. This transient menu is more of a first draft and the behavior could use more testing.
Sure, this is easy to add. But where would the output show up, and how would you continue the conversation?