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

[Eli Zaretskii <eliz@gnu.org>]

Ping! How can we make progress with this issue?

> From: Troy Brown <brownts@troybrown.dev>
> Date: Wed, 14 Aug 2024 07:41:36 -0400
> Cc: Felician Nemeth <felician.nemeth@gmail.com>, joaotavora@gmail.com, 72597@debbugs.gnu.org
> 
> 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.
>