From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#72597: 30.0.60; Eglot: MarkedString with embedded Carriage Return Date: Sat, 31 Aug 2024 10:55:44 +0300 Message-ID: <86wmjxcein.fsf@gnu.org> References: <86h6bohdsd.fsf@gnu.org> <87v804mfyz.fsf@betli.tmit.bme.hu> <86v803g1oy.fsf@gnu.org> <87le0zmyy7.fsf@betli.tmit.bme.hu> <86ikw3fw4k.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26722"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 72597@debbugs.gnu.org, felician.nemeth@gmail.com To: Troy Brown , joaotavora@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 31 09:56:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1skIy4-0006l9-OS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 31 Aug 2024 09:56:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1skIxr-0000De-6o; Sat, 31 Aug 2024 03:56:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1skIxo-0000Ch-AW for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 03:56:04 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1skIxo-000408-0p for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 03:56:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=YhuujxZ+MPcruK8N50IqygL9FNpIg8lq6M/WxYD3KF0=; b=d0Ephn8f405GGsYZboy1PYrtWC5kpe5BeT4x+B1n9zfB8Q2iJX/XKEUw/HzlJQOKUB5eDJ0H8kQ9/U0fT6e9yHv49MxOe3LQbgecWxZhQzFY0NuPs8fzCDh0Bhb9wFiyM8yJqSIeGa5WBlylwCjyeUcXiGDHyBFFJRUYDDYr3miAuYwWD9Xy6p9j5BfWEuEILU6A4XDbxib1qR80TNfmUB0Ls1zv83+9MlEzeQ0h2QSqUJrR5ZjE0DdrIXdQlglo69wYKOvz3r3VlRaQvprCAF6y7yJUc7PAbo48xQ+mU9OoQemdWAZR2gdvqY4nE/qRci+5gvlnagYB9wa7+eS8Cw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1skIyj-00063K-Oq for bug-gnu-emacs@gnu.org; Sat, 31 Aug 2024 03:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Aug 2024 07:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72597 X-GNU-PR-Package: emacs Original-Received: via spool by 72597-submit@debbugs.gnu.org id=B72597.172509101723255 (code B ref 72597); Sat, 31 Aug 2024 07:57:01 +0000 Original-Received: (at 72597) by debbugs.gnu.org; 31 Aug 2024 07:56:57 +0000 Original-Received: from localhost ([127.0.0.1]:53828 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skIyf-000630-5f for submit@debbugs.gnu.org; Sat, 31 Aug 2024 03:56:57 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1skIyd-00062l-C6 for 72597@debbugs.gnu.org; Sat, 31 Aug 2024 03:56:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1skIxa-0003tb-Vf; Sat, 31 Aug 2024 03:55:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YhuujxZ+MPcruK8N50IqygL9FNpIg8lq6M/WxYD3KF0=; b=hi8Xk6kQpKokp2xfaA+v 1VLsF+J9ULOVlj2iF6LGdGeoAqE7po9AVUVIX+N/dVC167IQFrvECE9iVOxyXblUXOVrVbPRwt/dN 6mlaPF/uKDdaPuNGenF3jh7equ7YdC3ix4PSugrh1cb5vhHB1GNQ0YKXyLl/qtkbq2ieZN18v/7Ch t/7jxv1hGoTenayq/y6pey1YmCtu1dGz3koef2UAKD+khmakKUqOUWODkiagvkQHeiI/mFkzG+qXQ +XsshKrbLpCSeZuqniV3d9An1unBx5ZMDQ+MRtykz8fdQjvkdMmczq6f596jxlamcMWALiy8IPw8B q81+ZM8pGNNyeA==; In-Reply-To: (message from Troy Brown on Wed, 14 Aug 2024 07:41:36 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:290976 Archived-At: Ping! How can we make progress with this issue? > From: Troy Brown > Date: Wed, 14 Aug 2024 07:41:36 -0400 > Cc: Felician Nemeth , joaotavora@gmail.com, 72597@debbugs.gnu.org > > On Wed, Aug 14, 2024 at 2:37 AM Eli Zaretskii wrote: > > > > > From: Felician Nemeth > > > Cc: Troy Brown , joaotavora@gmail.com, > > > 72597@debbugs.gnu.org > > > Date: Wed, 14 Aug 2024 07:54:24 +0200 > > > > > > Eli Zaretskii 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. >