bug#72941: jsonrpc: Check if parameters are in line with the spec
>> Would it be possible to extend jsonrpc.el to check the params argument >> of jsonrpc-request, jsonrpc-notify, and jsonrpc-async-request whether it >> is a structured value? And if it is not, then guide the programmer to >> the above URL with a warning. The use case makes sense to me, but I would go with updating the docs rather then the API. The current wording could use some love as it's refereed to as JSON object or plist (at different functions). When it should be plist or vector, where we could throw in a link to the specification. I am not for signaling an error or similar as it's a breaking change in my book, which does not seam called for in this case. /Daniel Pettersson
bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return
João Távora writes: > On Mon, Sep 2, 2024 at 12:24 PM Eli Zaretskii wrote: >> Thanks, but isn't the above the same as setting the car of >> process-coding-system for the Eglot subprocesses to 'dos'? I would think that a better place for encoding the displayed string at the place where we are displaying the string rather then before parsing the json. > Anyway, if the solution is to be performed at this lower > level (which I think it should), then Daniel Petterson > jsonrpc.el maintainer should be added. I might be missing something, but jsonrpc should not in my mind convert/format/encode any json data. Any assumptions on line endings can only be made on header and content separators, not on the json payload itself. /Daniel Pettersson
bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return
Eli Zaretskii writes: > That depends on the reason why the CR character appeared there in the > first place. Are they required for the strings in questions, or are > they simply an artifact of how the server marshaled JSON data on the > wire? I am not convinced, in my mind if the marshaling operation converts \n to \r\n (or any other character combination) within a string literal, then the server's JSON conversion is broken. > In the latter case, the CR characters are the result of > Windows-style text writing, which adds a CR to each newline, and > therefore removing that CR should indeed happen where Emacs decodes > the EOLs of the incoming stuff. I fail to see how that is not due to an broken json marshaling and not intentionally chosen line endings by the server. Of course I might be overlooking something. /Daniel Pettersson
