Incompatibility with gptel Package When Using Non-Streaming APIs and Specific `default-process-coding-system`

[WeissP]

IF your feature request is related to a problem
When using the gptel package with gptel-stream set to nil or calling an API without stream support, if default-process-coding-system is set to '(utf-8 . utf-8), the response is never shown. This issue is particularly hard to pinpoint because it functions correctly with gpt-4o but not with o3-mini (which doesn’t support streaming). No error messages are displayed, even with the log level set to info, leaving the user with a "querying gpt..." message and no further results.

Describe the solution you'd like
I would like the README to include information about the importance of default-process-coding-system for non-streaming APIs. Additionally, it would be great if error messaging can indicate potential issues with default-process-coding-system when responses are not being displayed.

Additional context
The issue took me several hours to identify due to the lack of error messaging and documentation regarding default-process-coding-system related problems. I hope this change will prevent other users from encountering the same issue and wasting time trying to resolve it 😃 .

[karthink]

There were some recent changes where we set the buffer-file-coding-system in the process buffer for non-streaming requests explicitly to utf-8-unix. Could you check if your reported behavior still exists?

[WeissP]

There were some recent changes where we set the buffer-file-coding-system in the process buffer for non-streaming requests explicitly to utf-8-unix. Could you check if your reported behavior still exists?

The behavior no longer exists. Thanks for the fix!