Manually edited :GPTEL_SYSTEM: gets overwritten upon save

[nordlow]

An edited value of the property :GPTEL_SYSTEM: in an org-mode buffer gets overwritten upon save.

For instance if I modify

version 1

You are a large language model and a careful programmer. Provide code and only code as output without any additional text, prompt or note.

to

version 2

You are a large language model and a careful programmer. Provide code and only code as output without any additional text, prompt or note. Write C using as modern constructs as possible.

it gets reverted to version 1 which is not what I want. A mode should never overwrite a users setting by default.

[karthink]

Are you setting the GPTEL_SYSTEM property (or others) manually? This is not supported. gptel saves the active model parameters to the buffer for persistence. The idea is that the current system message, max token count etc will be written to the file so you can resume the chat with these settings.

A mode should never overwrite a users setting by default.

GPTEL_* properties are not intended to be user settings, they're internal to gptel and used to rehydrate chat sessions.

[nordlow]

Are you setting the GPTEL_SYSTEM property (or others) manually? This is not supported. gptel saves the active model parameters to the buffer for persistence. The idea is that the current system message, max token count etc will be written to the file so you can resume the chat with these settings.

A mode should never overwrite a users setting by default.

GPTEL_* properties are not intended to be user settings, they're internal to gptel and used to rehydrate chat sessions.

Ok, thanks. So how do I adjust the

:GPTEL_SYSTEM: You are a large language model and a careful programmer. Provide code and only code as output without any additional text, prompt or note.

to include adjustments for an org-mode buffer in specific project? Such as a project containing C code I want to have be refactored in a certain manner.

[nordlow]

Are you setting the GPTEL_SYSTEM property (or others) manually?

Yes, I want to change it manually for every Org buffer so that I get a specific prompt for each buffer I'm currenly working in. Ideally I would like to be able to make the contextual-prompt-customization as fine-grained as possible even on the symbol-level.

[karthink]

So how do I adjust the GPTEL_SYSTEM ...

Set the system message for the Org buffer -- you can do it from the transient menu (C-u C-c RET in your setup):

You can set it per buffer by toggling the "per-buffer" switch:

Ideally I would like to be able to make the contextual-prompt-customization as fine-grained as possible even on the symbol-level.

I don't know what it means to set a system message at the symbol level. But you can set a different system message per Org heading by calling M-x gptel-org-set-properties. See the README for more information on using gptel in Org mode.

---

The active system message is written as the GPTEL_SYSTEM property to the Org heading/file so that it can be used the next time the file is opened. So the intended flow of information is "currently active system message" --> "Org file", not "Org file" --> "active system message".

[nordlow]

Ok, thanks. Where is the global system message persistently saved to disk?

I've pressed C-x C-s in the transient buffer but I don't get any changes under ~/.emacs.d/transient.

The only modification I get is the adding of the line

 (gptel-menu)

to ~/.emacs.d/transient/values.el.

Currently, I instead get the system message written to :GPTEL_SYSTEM: in the .org file I had opened when I pressed C-x C-s in the transient buffer.

[karthink]

Ok, thanks. Where is the global system message persistently saved to disk?

It's saved in the Org file, along with other model parameters.

If you would like to have a bunch of pre-written system messages available to quickly select, you should customize gptel-directives. (Please run M-x customize-group gptel and take a look at the available options)

---

I think there's some miscommunication about what you're trying to do and what I understand you want, because there should be no reason to look in the transient values file for anything.

[nordlow]

Ok, thanks. I still strongly believe that manual editings of the :GPTEL_SYSTEM: in buffer b should be respected upon save of b. This behaviour is analogous with how manual editing of calls to existing calls to custom-set-variables and custom-set-faces in .emacs.d/init.el are respected by Emacs' customization logic.

[karthink]

I still strongly believe that manual editings of the :GPTEL_SYSTEM: in buffer b should be respected upon save of b.

I don't see how this can work -- if GPTEL_SYSTEM was intended to be edited manually, how would gptel be able to save the active system message to it? It would become non-functional as a mechanism to save the chat state.

[nordlow]

how would gptel be able to save the active system message to it?
Can you elaborate on what you mean by active system message?

if GPTEL_SYSTEM was intended to be edited manually, how would gptel be able to save the active system message to it

It should both work ways analogously with how M-x customize-variable picks up the current state of currently the customized variables in the current Emacs session by parsing the call to (custom-set-variables in your emacs configuration file (such as .emacs or .emacs.d/init.el) and writes it back upon C-x C-s in the *Customize ... buffer.

This is a relatively unique feature of Emacs and may come as a surprise to some users that I (and likely many others) find very useful. You can in this case think of Emacs as a digital assistant that automates the manual work of updating the code and settings that controls the behavior.

[karthink]

gptel's request parameters aren't like the customize system, for an important reason. The values in the customize buffer are "dead" until they're saved, at which point they become active. gptel's parameters stored as Org properties are "live", always active.

I think I didn't explain the problem well. When you save the chat buffer to disk, there are two sources of truth for the request parameters:

1. The GPTEL_* Org properties
2. The currently chosen values for the parameters, for example via gptel-max-tokens, gptel-temperature etc.

When these are in conflict, there is a problem. Either source 1 has to override source 2, in which case saving the file does nothing.

Or 2 has to override 1, in which case editing the properties by hand will be overwritten.

gptel does 2 because it's the more consistent and automatic approach -- this way you can set whatever properties you want from the menu or via elisp, and just save the file to persist them to disk. In the other case, the only way to store the request parameters to file would be to edit the properties manually.