Insert space/newline after tool call when gptel-include-tool-results is nil

[jdormit]

Please update gptel first -- errors are often fixed by the time they're reported.

• I have updated gptel to the latest commit and tested that the issue still exists

Bug Description

If tool results are not being included in a chat buffer, and the LLM makes a tool call then follows it up with a chat message, no space or newline gets inserted before the new message comes in. Here's an example where I asked the LLM to make a tool call then comment on the results:

### Try calling a tool then commenting about it so I can see how it outputs

I'll do a web search and then make a comment about the results.Based on the search results, I see that Emacs 29.4 is the latest version. This version is an emergency maintenance release.

This response has three messages: the first sentence, then the tool call, then the second sentence. Note that there is no space or newline between the two sentences: ...results.Based on....

I've been trying to fix this on my own for a bit but I'm not having much luck, gptel--insert-response is a bit too complicated for me to wrap my head around. I would appreciate it if you could point me in the right direction - happy to open a PR once I figure out what needs to change.

Backend

Anthropic, but I would expect this to happen for any backend.

Steps to Reproduce

1. Enable some tool (I used a web search tool) and set gptel-include-tool-results to nil (or auto, and make sure the tool doesn't have :include set)
2. Chat until the following sequence occurs: the LLM sends a chat message, then makes a tool call, then sends another chat message. I can consistently get Claude to do this by asking it to call a tool then comment on the results
3. Note that there is no space between the chat message before the tool call and the chat message after

Additional Context

Emacs version: 29.1
GPTel commit: 55355bd

Backtrace

Log Information

[jdormit]

Oh I guess I should specify, I'm using streaming responses.

[jdormit]

...and it turns out that was the key, streaming responses are inserted using a different function 🤦. Here's a fix: #770