GNU bug report logs - #72597
30.0.60; Eglot: MarkedString with embedded Carriage Return

Previous Next

Full log

Message #26 received at 72597 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 72597 <at> debbugs.gnu.org, brownts <at> troybrown.dev, joaotavora <at> gmail.com
Subject: Re: bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage
 Return
Date: Wed, 14 Aug 2024 09:37:15 +0300

> From: Felician Nemeth <felician.nemeth <at> gmail.com>
> Cc: Troy Brown <brownts <at> troybrown.dev>,  joaotavora <at> gmail.com,
>   72597 <at> debbugs.gnu.org
> Date: Wed, 14 Aug 2024 07:54:24 +0200
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.