[Windows] Unsupported map type ‘symbol’: json-read-error (due to CR-LF issues)

[ssafar]

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

When parsing JSON responses, we get something like this:

Debugger entered--Lisp error: (error "Unsupported map type ‘symbol’: json-read-error")
  error("Unsupported map type `%S': %S" symbol json-read-error)
  map-elt(json-read-error :prompt_eval_count)
  (or (map-elt response :prompt_eval_count) 0)
  (+ (or (map-elt response :prompt_eval_count) 0) (or (map-elt response :eval_count) 0))
 (... left out some frames for conciseness)
  gptel-curl--parse-response((:token "bccdcda94429f3c6caee4658f8380f0c" :backend #s(gptel-ollama :name "Ollama" (... etc)

Upon looking at the *gptel-curl* buffer, we see a reasonable response; the cursor location in it is somewhere towards the beginning of the JSON response (but not quite at its start).

(PR coming soon)

Backend

None

Steps to Reproduce

1. open a chat window
2. try making any query

Additional Context

Emacs 28.1, Windows 10,

curl 7.79.1 (Windows) libcurl/7.79.1 Schannel
Release-Date: 2021-09-22
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
Features: AsynchDNS HSTS IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets

Backtrace

No response

Log Information

No response

[karthink]

This makes sense, thanks for reporting it. But now I'm confused about why no one has had this problem with gptel on Windows before!

[ssafar]

I'm guessing "streaming" vs. "not streaming" might make a difference & many people might just be using APIs with streaming on by default? (e.g. Anthropic APIs worked for me before, this only surfaced when trying to use an Ollama instance)

Thanks for merging btw!