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 14:16:58 +0200 Message-ID: <83h6vbntqd.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> 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="20762"; 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 13:18:43 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 1pVX2A-0005FV-AI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Feb 2023 13:18:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVX1Z-00028D-6k; Fri, 24 Feb 2023 07:18:05 -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 1pVX1W-00027S-Vb for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:18:03 -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 1pVX1W-0005Zd-NP for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:18:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pVX1W-0001cC-Ib for bug-gnu-emacs@gnu.org; Fri, 24 Feb 2023 07:18: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 12:18: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.16772410276142 (code B ref 61726); Fri, 24 Feb 2023 12:18:02 +0000 Original-Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:17:07 +0000 Original-Received: from localhost ([127.0.0.1]:36212 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVX0d-0001b0-0R for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:17:07 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:46770) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVX0b-0001aN-KH for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:17:05 -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 1pVX0W-0005SG-9r; Fri, 24 Feb 2023 07:17:00 -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=hAECaajAjkirSaVIeINIXMGYRivJh6ZiqWqmfFLrEp0=; b=K7EF8WvJUVnHfIsXZNwM BJJIRhoR1BqvrfbQ3rMMFC97LRRXdU+dOzvqZ7NIw9ag8sVl3xdYjHyJbaJpsxoI1tXKIgPRwZm93 zcRdnaAAOBtkthSO4GjKOj18yhtgif2WQVVmm/8Unhw8sLjv8QJBwkwLPxJ/9qEgeqTBnR5GdkJgM oVWyP7qX4LuHUk08tJtpWUK7m3yKGI4tzOjqG30qkL7cP+raUQkmzrtdYo6jH0lRScRYogsS5dUHv aJmF8j/JXZyQjWSyEO23lt+t1fqByo/Ik4hP+0oGwd/S4qOALccYksMv6bvYK0FxSFK+rmNQ76LJj Lgk3qjgO0HWDYg==; 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 1pVX0V-0003AL-FI; Fri, 24 Feb 2023 07:16:59 -0500 In-Reply-To: <87lekn9ss3.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 13:01:16 +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:256580 Archived-At: > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 13:01:16 +0100 > > On Fri, 24 Feb 2023 at 13:27, Eli Zaretskii wrote: > > >> > As discussed, position-bytes is incorrect. You should instead do > >> > something like > >> > > >> > (length (encode-coding-string > >> > (buffer-substring-no-properties (point) > >> > (line-beginning-position)) > >> > 'utf-8-unix t)) > >> > >> But it is incorrect only if the buffer contains characters outside of > >> the Unicode range, right? If that happens, we already lost, because a > >> few steps later we will serialize the buffer text as JSON to send it to > >> the server: > > > > Why should one part of the code depend on what another part does? In > > my book, each part should do its job, and do it right. > > Arguably both implementations are wrong, and the correct one should > produce an error if the buffer substring cannot be converted to valid > UTF-8. You assume that the characters that aren't encodable in UTF-8 somehow invalidate the results produced by the LSP? But that is not necessarily true, it depends on the context. IOW, this is not the problem eglot.el should solve, and I'm not sure that signaling an error is the correct reaction to this situation. It is basically the problem of the user and/or the major mode. Eglot should do its best to cope, and leave the rest to the user. > Between two “wrong” but perfectly functional implementations, I'd choose > the more efficient one, because efficiency actually matters in this > case. So which one is more efficient? I don't know, and I don't think efficiency is the main concern here. The main concern, from my POV, is exposing the internal representation of buffer text to the outer world. What if we decide to change the internal representation at some future date? It already happened, twice, in Emacs history; it can happen again, even though its unlikely.