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

[Troy Brown <brownts@troybrown.dev>]

On Wed, Aug 14, 2024 at 2:37 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > 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.

Other than what Felician already quoted from the LSP specification,
there doesn't seem to be much else stated about EOL.  In this
particular case, I've seen it on both Linux and Windows, therefore the
use of the CR doesn't seem to be consistent with the platform or the
document format.  It's unclear to me why this particular EOL format
was chosen for the hover information, but I can't find anything in the
specification that says it is incorrect.