bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return

[Eli Zaretskii <eliz@gnu.org>]

> From: Felician Nemeth <felician.nemeth@gmail.com>
> Cc: Troy Brown <brownts@troybrown.dev>,  joaotavora@gmail.com,
>   72597@debbugs.gnu.org
> Date: Wed, 14 Aug 2024 07:54:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Can you please answer my question whether this is standard-complying
> > behavior according to LSP protocol?  IOW, what is the source of the
> > assumption that CR characters will be interpreted as newlines in these
> > cases?
> 
> It seems this is standard-complying, because the specification has this:
> "To ensure that both client and server split the string into the same
> line representation the protocol specifies the following end-of-line
> sequences: ‘\n’, ‘\r\n’ and ‘\r’."

This just caters to the 3 known EOL formats: the Unix, the
DOS/Windows, and the Mac one.  If this is the basis for the described
behavior, then Emacs should bind coding-system-for-read when reading
this stuff, or maybe manually decode the strings after detecting EOL
format.  But that would only work if the EOL format is used
consistently in the entire response of the server; if they just use
the above as a means to sneak in multiple-line responses, and
otherwise use some other EOL format, then we need to handle a lone \r
specially in Eglot's code, something I'm not sure we like to do.