gptel-transient: Improve directive/system message editing #616
Conversation
I find it quite useful. If you want to edit the existing prompt, all you need to do is press So on balance, activating the region works better.
Yes, this is a good idea. |
Yes I think you're right, and perhaps this is the most common use case. On the other hand, when picking a crowdsourced prompt, I don't think the user would want to delete everything to edit the prompt. Perhaps we could make setting the region optional depending on a parameter, and call it differently from |
* gptel-transient.el (gptel--read-crowdsourced-prompt): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (#616). The reasoning is that the user will almost certainly want to edit the chosen prompt, and not overwrite/clear it. Also set the crowdsourced prompt according to the current scope.
|
On the other hand, when picking a crowdsourced prompt, I don't think the user would want to delete everything to edit the prompt. Perhaps we could make setting the region optional depending on a parameter, and call it differently from `gptel--read-crowdsourced-prompt`?
Done.
I can merge the visual-line-mode part of this PR if you undo the changes to the mark status.
|
* gptel-transient.el (gptel--edit-directive): Enable visual-line-mode.
|
Cheers @pabl0! |
* gptel-transient.el (gptel--read-crowdsourced-prompt, gptel--edit-directive, gptel--suffix-system-message): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (karthink#616). This behaviour was introduced in commit cc53a81, but it did not actually work since `deactivate-mark' was called after returning from `gptel--read-crowdsourced-prompt', when it was too late.
* gptel-transient.el (gptel--read-crowdsourced-prompt, gptel--edit-directive, gptel--suffix-system-message): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (karthink#616). This behaviour was introduced in commit cc53a81, but it did not actually work since `deactivate-mark' was called after returning from `gptel--read-crowdsourced-prompt', when it was too late. * gptel-rewrite.el (gptel--suffix-rewrite-directive): Call `gptel--rewrite-directive' with mark activation enabled.
* gptel-transient.el (gptel--read-crowdsourced-prompt, gptel--edit-directive, gptel--suffix-system-message): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (#616). This behaviour was introduced in commit cc53a81, but it did not actually work since `deactivate-mark' was called after returning from `gptel--read-crowdsourced-prompt', when it was too late. * gptel-rewrite.el (gptel--suffix-rewrite-directive): Call `gptel--rewrite-directive' with mark activation enabled.
* gptel-transient.el (gptel--read-crowdsourced-prompt): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (karthink#616). The reasoning is that the user will almost certainly want to edit the chosen prompt, and not overwrite/clear it. Also set the crowdsourced prompt according to the current scope.
* gptel-transient.el (gptel--edit-directive): Enable visual-line-mode.
) * gptel-transient.el (gptel--read-crowdsourced-prompt, gptel--edit-directive, gptel--suffix-system-message): Deactivate the mark after entering the prompt-edit buffer for a crowdsourced prompt (karthink#616). This behaviour was introduced in commit cc53a81, but it did not actually work since `deactivate-mark' was called after returning from `gptel--read-crowdsourced-prompt', when it was too late. * gptel-rewrite.el (gptel--suffix-rewrite-directive): Call `gptel--rewrite-directive' with mark activation enabled.
I find no value in activating the directive in the edit buffer as region, and it can be quite annoying.
Additionally, since the directives and system messages are primarily regular text, enabling visual-line-mode (word wrapping) seems logical.