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#61726: [PATCH] Eglot: Support positionEncoding capability Date: Fri, 24 Feb 2023 17:19:20 +0200 Message-ID: <834jrbnlaf.fsf@gnu.org> References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <875ybsfvtj.fsf@gmail.com> <831qmgr17p.fsf@gnu.org> <87wn48ecdz.fsf@gmail.com> <83v8jspgnr.fsf@gnu.org> <87lekodxja.fsf@gmail.com> <83a614p4sh.fsf@gnu.org> <87cz60dus9.fsf@gmail.com> <835ybrpnqj.fsf@gnu.org> <87y1oncz09.fsf@gmail.com> <83r0ufo3uc.fsf@gnu.org> <87356vbf0b.fsf@gmail.com> <83pm9znw0i.fsf@gnu.org> <87lekn9ss3.fsf@gmail.com> <83h6vbntqd.fsf@gnu.org> <878rgn9r6u.fsf@gmail.com> <83edqfnq5u.fsf@gnu.org> <83bkljnpck.fsf@gnu.org> <874jrb9l6d.fsf@gmail.com> 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="14861"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Feb 24 16:20:17 2023 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 1pVZrs-0003gm-Tj for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Feb 2023 16:20:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVZrf-0004kS-Oi; Fri, 24 Feb 2023 10:20:03 -0500 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 1pVZre-0004jv-QX for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 10:20:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVZre-0003bW-Gj for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 10:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVZre-0000sr-D5 for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 10:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Feb 2023 15:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61726 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 61726-submit@debbugs.gnu.org id=B61726.16772519693340 (code B ref 61726); Fri, 24 Feb 2023 15:20:02 +0000 Original-Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 15:19:29 +0000 Original-Received: from localhost ([127.0.0.1]:37928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZr7-0000ro-8r for submit@debbugs.gnu.org; Fri, 24 Feb 2023 10:19:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZr6-0000rR-8Q for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 10:19:28 -0500 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 1pVZqy-0003SA-LN; Fri, 24 Feb 2023 10:19:22 -0500 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=M7HSms4U9F6pdCCvvWVrDS67LPB95KnSvhUiHPD3ve8=; b=XMHxMnLvDWuCpyVy7k1/ rw8THthQNqDNLMTv+qAEaxoxUE/SM67brO/gTpRUxylqwlT9QM2zKipo/Y7FB+C5XXHXsxX0A19mC v0VTWNrKOJraeAHwrylHEW+NpKWU0P72y+xTswK0vC7unCkui7LLF+2nHuepQHx62ax5RiljHfI4E A/1AJyTgu0Ly0vE1gTET1WjB4o6C+NOMq2mYp72AnFbudfLxhl8QVYf2P21dc7n0OInR6wE/Gh5CB r6UCc5wRP8F2GeBAX5frd2YuRx9kj+6+FaZlYPAzfvT82pTv/3MH+iACsK/BsvDF1S1ZtmQxvgHS4 qDdlH+sbmGhSdQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVZqy-0005Vp-5J; Fri, 24 Feb 2023 10:19:20 -0500 In-Reply-To: <874jrb9l6d.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 15:45:30 +0100) 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:256614 Archived-At: > From: Augusto Stoffel > Cc: João Távora , > 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 15:45:30 +0100 > > On Fri, 24 Feb 2023 at 15:51, Eli Zaretskii wrote: > > > This is a misunderstanding: I didn't mean to say that we should send > > invalid UTF-8 sequences. I meant something else. Quote from the rest > > of my message: > > > >> > and `json-serialize' rightfully emits an error. > >> > >> There's no "rightfully" here. It's our decision to signal an error in > >> this case. > > In fact, our decision was to follow the JSON specification, which says > UTF-8 is the only allowed exchange encoding: > https://www.rfc-editor.org/rfc/rfc8259#section-8.1 > > >> Substituting some innocent character for the unencodable > >> ones would be an entirely legitimate alternative. > > So actually the answer here is no. You can save arbitrary bytes in a > file in your laptop and call it data.json. But it you pass some data to > someone else and promise it's in JSON format, then it _must_ be UTF-8 > encoded. I'm bewildered by my apparent inability to explain what I mean. So let me try with an example. Suppose the buffer text in question is abcde\201xyz where \201 is a raw byte. I'm saying that, instead of signaling an error, we could send to the server the string abcde xyz where the \201 byte was replaced by the SPC character. The latter string is, of course, perfectly correct UTF-8 sequence, and so doesn't violate any specs. The SPC character as a replacement is, of course, just one example. We could instead use '?' or U+FFFD REPLACEMENT CHARACTER, or anything else, and all of those replacements can be encoded in UTF-8 without any problems. Did I make myself clear now?