From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 03:05:51 2023 Received: (at submit) by debbugs.gnu.org; 23 Feb 2023 08:05:51 +0000 Received: from localhost ([127.0.0.1]:32851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV6bv-0008Ey-7j for submit@debbugs.gnu.org; Thu, 23 Feb 2023 03:05:51 -0500 Received: from lists.gnu.org ([209.51.188.17]:60262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV6bs-0008Ep-Qy for submit@debbugs.gnu.org; Thu, 23 Feb 2023 03:05:49 -0500 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 1pV6bo-0002W6-4Z for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 03:05:46 -0500 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pV6bl-00066n-Qs for bug-gnu-emacs@gnu.org; Thu, 23 Feb 2023 03:05:43 -0500 Received: by mail-ed1-x52c.google.com with SMTP id b12so39244306edd.4 for ; Thu, 23 Feb 2023 00:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=XuhPDwjpmMDpWUYuubi333Pl15q/yvqjRidB+mJTjQM=; b=U7TFeyBCSOo3s3shoys4/XHcWy5N8WOMugP8CZMXDeBafYM9ESqGOQC3WpNbNpL1J2 GF5giPejhIPzpRrBJrtvWI6RccKMdHlf2p38T6U349lFd1hEQ40/ScEaluP3DTi2IZ2e repznMFdp6569UrslpkF/wLBmcgv+bk7N9b5EZMhnXnOGDTuawnOlpblWO2ZU1eiAXfN 4nJ4gDL/IfiFUe1tBIu/4om1ADsNxOvi0xhUlR2DekfJJLv5MfJTN3aPvZKSzXiQpTlq 8XyNUDWqKGY9WlQmX/Kws+8+i+q7nJIuRVEa4rxBSVKAAvZ2h0WtcEuoIWeLjdREqITe cOSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XuhPDwjpmMDpWUYuubi333Pl15q/yvqjRidB+mJTjQM=; b=0CzupM6mDgd0kpZQH2yXl86NdwQWVmUh0Vd3ActPSsf9itmIqu9Ipycwr7G80xu8eS uJkMv8km5wuqG9KL6s3Fqsscz8/lI4yYVVwcZ0pydXSLUSQkHopG84Uwo7lImPjCunMh 4VuBK5lmUu+hUOODKS+zr6y0tdB76Hn1p3KEn/evF1WOfLbYzYpDULnkVKxiA14O4/Ap gdnAsThCjv5av6S7Mc/10biErO5eGt8azeX171qnbdYjnIpTC5AEaB5h31+nBtbI3XRO +9SvG375nSHwPQ1jMmEAvZFKPuqO2fgtbVPZH3U9/JTOZWYc4hzd0+N98a7U2ACRFbrW qB0Q== X-Gm-Message-State: AO0yUKUGNYRyMqAxd7uJOheX1Gcgl6f1L5Y70NQS06nRn4uJRIsnJAJS owJz8YxT5IGfcgjnZcJKZKBtNp+fLoI= X-Google-Smtp-Source: AK7set84F0p4lu41m84cNjk1uslLNxdk2TnEgOp3wVWZx9gO6ncwX9JTKJKEkyQ35cDPwbctJ9nsZw== X-Received: by 2002:a17:907:ea2:b0:888:b764:54e5 with SMTP id ho34-20020a1709070ea200b00888b76454e5mr24190390ejc.71.1677139537549; Thu, 23 Feb 2023 00:05:37 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id w13-20020a1709064a0d00b008d1693c212csm5056512eju.8.2023.02.23.00.05.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 00:05:36 -0800 (PST) From: Augusto Stoffel To: bug-gnu-emacs@gnu.org Subject: [PATCH] Eglot: Support positionEncoding capability X-Debbugs-Cc: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 09:05:35 +0100 Message-ID: <87a614g628.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::52c; envelope-from=arstoffel@gmail.com; helo=mail-ed1-x52c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain Tags: patch There is a new LSP capability allowing the server and client to agree on a way to count character offsets. What do you think fo the attached patch? It expresses Eglot's preferences as counting character offsets, then byte offsets, then the UTF-16 nonsense, in that order. I would also suggest preparing the stage to eventually make `eglot-current-column-function' and `eglot-move-to-column-function' obsolete. For that, I suggest renaming - eglot-current-column -> eglot--current-column-utf-32 - eglot-lsp-abiding-column -> eglot--current-columns-utf-16 - eglot-move-to-column -> eglot--move-to-columns-utf-32 - eglot-move-to-lsp-abiding-column -> eglot--move-to-columns-utf-16 and then making the old names obsolete aliases of the new names. (I have tested the utf-32 case superficially, and not at all the utf-8. So this is a RFC.) --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0001-lisp-progmodes-eglot.el-Support-positionEncoding-cap.patch >From a86601f4e80dfbf21a84230433c431375e3012aa Mon Sep 17 00:00:00 2001 From: Augusto Stoffel Date: Thu, 23 Feb 2023 08:55:58 +0100 Subject: [PATCH] * lisp/progmodes/eglot.el: Support positionEncoding capability --- lisp/progmodes/eglot.el | 65 +++++++++++++++++++++++++++++------------ 1 file changed, 46 insertions(+), 19 deletions(-) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index b569c03e8c2..0268fbf63a5 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -816,6 +816,9 @@ eglot-client-capabilities `(:valueSet [,@(mapcar #'car eglot--tag-faces)]))) + :general + (list + :positionEncodings ["utf-32" "utf-8" "utf-16"]) :experimental eglot--{}))) (cl-defgeneric eglot-workspace-folders (server) @@ -1439,20 +1442,26 @@ eglot--warn (let ((warning-minimum-level :error)) (display-warning 'eglot (apply #'format format args) :warning))) -(defun eglot-current-column () (- (point) (line-beginning-position))) +(defun eglot-current-column () + "Calculate current column, counting Unicode codepoints." + (- (point) (line-beginning-position))) + +(defun eglot--current-column-utf-8 () + "Calculate current column, counting bytes." + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) -(defvar eglot-current-column-function #'eglot-lsp-abiding-column +(defvar eglot-current-column-function nil "Function to calculate the current column. This is the inverse operation of `eglot-move-to-column-function' (which see). It is a function of no arguments returning a column number. For buffers managed by -fully LSP-compliant servers, this should be set to -`eglot-lsp-abiding-column' (the default), and -`eglot-current-column' for all others.") +fully LSP-compliant servers, this should be nil. For others, it +can be set to `eglot-current-colum' or +`eglot--current-column-utf-8'.") (defun eglot-lsp-abiding-column (&optional lbp) - "Calculate current COLUMN as defined by the LSP spec. + "Calculate current column, counting UTF-16 code units as in the original LSP spec. LBP defaults to `line-beginning-position'." (/ (- (length (encode-coding-region (or lbp (line-beginning-position)) ;; Fix github#860 @@ -1462,13 +1471,19 @@ eglot-lsp-abiding-column (defun eglot--pos-to-lsp-position (&optional pos) "Convert point POS to LSP position." - (eglot--widening - ;; LSP line is zero-origin; emacs is one-origin. - (list :line (1- (line-number-at-pos pos t)) - :character (progn (when pos (goto-char pos)) - (funcall eglot-current-column-function))))) - -(defvar eglot-move-to-column-function #'eglot-move-to-lsp-abiding-column + (let ((columnfn (or eglot-current-column-function + (pcase (plist-get (eglot--capabilities (eglot-current-server)) + :positionEncoding) + ("utf-32" #'eglot-current-column) + ("utf-8" #'eglot--current-column-utf-8) + (_ #'eglot-lsp-abiding-column))))) + (eglot--widening + ;; LSP line is zero-origin; emacs is one-origin. + (list :line (1- (line-number-at-pos pos t)) + :character (progn (when pos (goto-char pos)) + (funcall columnfn)))))) + +(defvar eglot-move-to-column-function nil "Function to move to a column reported by the LSP server. According to the standard, LSP column/character offsets are based @@ -1478,11 +1493,11 @@ eglot-move-to-column-function `c'. However, many servers don't follow the spec this closely. For buffers managed by fully LSP-compliant servers, this should -be set to `eglot-move-to-lsp-abiding-column' (the default), and -`eglot-move-to-column' for all others.") +be letft nil. For others, it can be set to +`eglot-move-to-column' or `eglot--move-to-column-utf-8'.") (defun eglot-move-to-column (column) - "Move to COLUMN without closely following the LSP spec." + "Move to COLUMN, counting Unicode codepoints." ;; We cannot use `move-to-column' here, because it moves to *visual* ;; columns, which can be different from LSP columns in case of ;; `whitespace-mode', `prettify-symbols-mode', etc. (github#296, @@ -1490,8 +1505,14 @@ eglot-move-to-column (goto-char (min (+ (line-beginning-position) column) (line-end-position)))) +(defun eglot--move-to-column-utf-8 (column) + "Move to COLUMN, regarded as a byte offset." + (goto-char (min (byte-to-position + (+ (position-bytes (line-beginning-position)) column)) + (line-end-position)))) + (defun eglot-move-to-lsp-abiding-column (column) - "Move to COLUMN abiding by the LSP spec." + "Move to COLUMN, counting UTF-16 code units as in the original LSP spec." (save-restriction (cl-loop with lbp = (line-beginning-position) @@ -1515,14 +1536,20 @@ eglot--lsp-position-to-point (forward-line (min most-positive-fixnum (plist-get pos-plist :line))) (unless (eobp) ;; if line was excessive leave point at eob - (let ((tab-width 1) + (let ((movefn (or eglot-move-to-column-function + (pcase (plist-get (eglot--capabilities (eglot-current-server)) + :positionEncoding) + ("utf-32" #'eglot-move-to-column) + ("utf-8" #'eglot--move-to-column-utf-8) + (_ #'eglot-move-to-lsp-abiding-column)))) + (tab-width 1) (col (plist-get pos-plist :character))) (unless (wholenump col) (eglot--warn "Caution: LSP server sent invalid character position %s. Using 0 instead." col) (setq col 0)) - (funcall eglot-move-to-column-function col))) + (funcall movefn col))) (if marker (copy-marker (point-marker)) (point))))) (defconst eglot--uri-path-allowed-chars -- 2.39.2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable PS: Jo=C3=A3o, since you may have had trouble receiving some emails, did you notice bug#58141? --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 05:39:03 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 10:39:04 +0000 Received: from localhost ([127.0.0.1]:33092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV90B-0006NK-Go for submit@debbugs.gnu.org; Thu, 23 Feb 2023 05:39:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV909-0006Mn-9p for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 05:39:02 -0500 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 1pV902-0006x6-D9; Thu, 23 Feb 2023 05:38:54 -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=0MIbZ8Xy51kJNlbhHmIh4Rbqxighjr/BiiLK2eOkvWk=; b=cb/zVfjHNoTRoA527xJY v604q/BnDQlahdNxbct8OlNKGoh2rUQkPX3ZLZT5zdKUNVw1XTPj992ZYMq3HnSgETZ8i/lHc9jCa BgU8cdxV+mAdHQwrPyfk3LlJTY1SCKw0kBeD0M4rK6vWjr5PQgJjbOlic2S/9jykQ7JxGkmO4te2K Q5boEOKR23vGLO0a5CpAo/U6lPzXIbkaqNLLrh6JiX0LFvWssuLy935Izd2D6NO9uHeuXVoH/nEwc 53jt///Y/ZPfZAeddFx0RtYB7bwZQ5z4KfNb83S5GP27TTpjSksr+W2xnGOk74VrlmS/FgDrcf8bn XP9wm+pNRDnGuA==; 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 1pV901-0002FQ-Gk; Thu, 23 Feb 2023 05:38:53 -0500 Date: Thu, 23 Feb 2023 12:39:09 +0200 Message-Id: <83cz60r7hu.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87a614g628.fsf@gmail.com> (message from Augusto Stoffel on Thu, 23 Feb 2023 09:05:35 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: João Távora > From: Augusto Stoffel > Date: Thu, 23 Feb 2023 09:05:35 +0100 > > There is a new LSP capability allowing the server and client to agree on > a way to count character offsets. What do you think fo the attached > patch? > > It expresses Eglot's preferences as counting character offsets, then > byte offsets, then the UTF-16 nonsense, in that order. > > I would also suggest preparing the stage to eventually make > `eglot-current-column-function' and `eglot-move-to-column-function' > obsolete. For that, I suggest renaming > > - eglot-current-column -> eglot--current-column-utf-32 > - eglot-lsp-abiding-column -> eglot--current-columns-utf-16 > - eglot-move-to-column -> eglot--move-to-columns-utf-32 > - eglot-move-to-lsp-abiding-column -> eglot--move-to-columns-utf-16 > > and then making the old names obsolete aliases of the new names. Please tell more about this, as I don't think I have a clear enough idea of the issues and the implications for Emacs. > +(defun eglot--current-column-utf-8 () > + "Calculate current column, counting bytes." > + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) This is subtly incorrect: position-bytes doesn't cound UTF-8 bytes, it counts the bytes in the internal representation Emacs uses for buffer and string text. The differences are minor and subtle, but not negligible. > (defun eglot-move-to-column (column) > - "Move to COLUMN without closely following the LSP spec." > + "Move to COLUMN, counting Unicode codepoints." > ;; We cannot use `move-to-column' here, because it moves to *visual* > ;; columns, which can be different from LSP columns in case of > ;; `whitespace-mode', `prettify-symbols-mode', etc. (github#296, > @@ -1490,8 +1505,14 @@ eglot-move-to-column > (goto-char (min (+ (line-beginning-position) column) > (line-end-position)))) > > +(defun eglot--move-to-column-utf-8 (column) > + "Move to COLUMN, regarded as a byte offset." > + (goto-char (min (byte-to-position > + (+ (position-bytes (line-beginning-position)) column)) > + (line-end-position)))) > + > (defun eglot-move-to-lsp-abiding-column (column) > - "Move to COLUMN abiding by the LSP spec." > + "Move to COLUMN, counting UTF-16 code units as in the original LSP spec." > (save-restriction > (cl-loop > with lbp = (line-beginning-position) > @@ -1515,14 +1536,20 @@ eglot--lsp-position-to-point > (forward-line (min most-positive-fixnum > (plist-get pos-plist :line))) > (unless (eobp) ;; if line was excessive leave point at eob > - (let ((tab-width 1) > + (let ((movefn (or eglot-move-to-column-function > + (pcase (plist-get (eglot--capabilities (eglot-current-server)) > + :positionEncoding) > + ("utf-32" #'eglot-move-to-column) > + ("utf-8" #'eglot--move-to-column-utf-8) > + (_ #'eglot-move-to-lsp-abiding-column)))) > + (tab-width 1) > (col (plist-get pos-plist :character))) > (unless (wholenump col) > (eglot--warn > "Caution: LSP server sent invalid character position %s. Using 0 instead." > col) > (setq col 0)) > - (funcall eglot-move-to-column-function col))) > + (funcall movefn col))) > (if marker (copy-marker (point-marker)) (point))))) What does this stuff do with double-width or zero-width characters? Emacs takes character-width into consideration when it counts columns, but it is unclear to me what do LSP servers do in those cases. Likewise with characters that are composed on display. So I think this mess needs to be carefully and elaborately discussed before we decide how to implement it correctly. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 06:33:05 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 11:33:05 +0000 Received: from localhost ([127.0.0.1]:33191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV9qT-00080K-Fp for submit@debbugs.gnu.org; Thu, 23 Feb 2023 06:33:05 -0500 Received: from mail-oa1-f45.google.com ([209.85.160.45]:41900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV9qQ-0007zj-3Y for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 06:33:03 -0500 Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-172334d5c8aso11235362fac.8 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 03:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WExvRs4uGlzl01dc7hL3C0JRc0tIfEfE3ZAUzWMHbZQ=; b=ibUqXMxzKtJJx4xt4QulBnYzW8a3JIImz1Mt6qcabWPR0ZVwNtz8Hws9oFMmLFJDPP Mss3c05lqZOY5WQd3CkpbBhERpCUG0P1ldnLaw9aSYNF2FUYgnh0NCEYN+u6GEs32ys8 oEofjt34cUklBYkDRAl/UzxTQeicTMlyPNy80iNtPdmOOZUqIzQxv4ag2l7URjfN3qPr WJy2HhOUa/ehn42wwtYqCLJxHa9rDJw+rOrZgUHYNDhN6fVOyYS7+/E8JdHzxS8Vy9U8 LLswAUYlwvlI7b4bGSF7PBOeL9djVu/OZvHTfKdhc2rxzFVUJ1ijY4assuB4sW69pKcI aP3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WExvRs4uGlzl01dc7hL3C0JRc0tIfEfE3ZAUzWMHbZQ=; b=1N3N8iYW6wr0Gxuzzr3VAI1t01l3ThX9WWU0YzvlWGQyvb0evvk1QrRipwktM0i0yd RoVKSbhYcyk9Mbxajg3bo4DW6S57MnSSfT7I3lYD/c+jB5uPXEh+Bq7OOOp7hCv+NkM0 Mvt1nGH9azd5GgFgzGADAoQL4FuwBSs/W/WtXBsbziPww9SO2yStklCZn8R0lw4Byuae yBj4JYKa3the6PFbG7rudkAnYpzhCEJnnytm20t7LhI8rISRvfWxU7wFm1z51zwAMHia JJjOADPU7OEWJlOh63E734mziSMmd3b41pUc9lD0Inw1sraVJqUGiOemmV8PoWYYpTqV MXiA== X-Gm-Message-State: AO0yUKVb37DKbszkhDa2x2HcHTZeu/MvkysMRGac9jjzn05BxkgZ6579 v+dkj/wfvgF3BpfoGmOJ7a/yy1g7uZE4meao6n8= X-Google-Smtp-Source: AK7set+Ir1z01gUnTFirNrAAqLq9L1nag0fQKK2QT+MTw2GKUU6ayOo4KiYclrnEOW7V6iCtrMy1FYzMxazwMhkp6ig= X-Received: by 2002:a05:6870:41d0:b0:172:8adb:8e44 with SMTP id z16-20020a05687041d000b001728adb8e44mr173161oac.215.1677151976130; Thu, 23 Feb 2023 03:32:56 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> In-Reply-To: <83cz60r7hu.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 11:32:45 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 23, 2023 at 10:38 AM Eli Zaretskii wrote: > So I think this mess needs to be carefully and elaborately discussed > before we decide how to implement it correctly. I agree. Just thinking about encodings makes my head hurt, so I'll probably skip this one and leave Eli or some other expert to this. It was hard enough to implement the "lsp abiding" case a few years ago. But, at least, and as far as I know, most if not all servers correctly implement it now and so do we. So it's nice that this new capability popped up. But, as far as I understand, the only benefit of leveraging it is for better efficiency. Right? Or are we risking incompatibility with some servers until we implement support for it? Please confirm this, Augusto. Anyway, some kind of renaming like the one Augusto proposed could be a first step in re-understanding the problem. The name "lsp abiding" is very bad, as I don't remember what I meant by it anymore. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 06:37:49 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 11:37:49 +0000 Received: from localhost ([127.0.0.1]:33197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV9v3-000874-77 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 06:37:49 -0500 Received: from mail-oa1-f52.google.com ([209.85.160.52]:39709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pV9v1-00086r-7j for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 06:37:47 -0500 Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-1720887dfcdso14953331fac.6 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 03:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KVR1LY123SpdTtrqpYAwAKCT9cuYrgMe2/usRi2BV8c=; b=S0NnUQz34W+sE3B0mn44YxQJDN2rjOy9p5cEwOr91JiYthBYOS1+DYwE7YNQtypBvl zVIiI+92gkdbkt/9Tl5+a0BhN12gELXrl2aF/VwUUCwneJ7Bxgmbo0dKTYOGPSRL5xBa 1idK1GneKZ5JAoutWdFkEBZpM4vftH+A3SAGzSQ2Keg7BtD8iZgkywgGWTWc21SwfbQl eGVczA/yVh81/dxsVGC05YzzTHF7162FfxGcfFATWLF35pbDoZw+JKPyKqtjJkvP1iYn 8juVUDpguRaSXV835ERmJwc9PsisVXPAJZIf75LrCQkhwttYXhkeOP3xTc3JHGTOus1c HDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KVR1LY123SpdTtrqpYAwAKCT9cuYrgMe2/usRi2BV8c=; b=IyqD3JyT8S86/2APHlNn5SMbAtb9Zajp1XvKdMf5tqiwxoZ1/C0BYOFBum/B7smxqY T+cU6OA3lUv+cvs4kz9PLWrpZvMco8Su/dlDVVEzecZc99DF+Uk0nVVHCW11LELIBOeP gBynAAWJPkq9VTNDKvkI5+VVF5SLozVB2XGHrtpFl8l23v9fRXaEPmQYq+2TKqZh1c4P u+oZgh+Oe9vsuCCZ/rC6wlw7w2ETv2NfvKUb+wUwxbyf/xjtD7jDh0iH2D9rwrSYpNVH GteJoeM1MjlRGsh8PanVD8kaadOOrbEyz511hfgX8yQYrcK5W66QAtvAf0M6dMx5EXPp zwhw== X-Gm-Message-State: AO0yUKVMPya5PwWgC84FO+eh7rGYCwoLcDOPwRRUbTySlSj5TV3AarUM y8SX4GM1owYCBTErgXU69S60oWL7c3SKSdhLIZDCsMfC X-Google-Smtp-Source: AK7set+aRRobCHeNIt7/0lH9ShfpF/5Wm9a1+ftphIEeP5pEM6UzOXKN2iaIAFCnyVpVKsiIHjwdjGWGf7slM0vYgA4= X-Received: by 2002:a05:6870:41d0:b0:172:8adb:8e44 with SMTP id z16-20020a05687041d000b001728adb8e44mr174272oac.215.1677152261753; Thu, 23 Feb 2023 03:37:41 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> In-Reply-To: <87a614g628.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 11:37:31 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 23, 2023 at 8:06 AM Augusto Stoffel wrote= : > PS: Jo=C3=A3o, since you may have had trouble receiving some emails, did = you > notice bug#58141? I did, but it's face-related bug and I usually have not much interest in those, since anyone customize faces easily. I'll reply. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 06:46:59 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 11:46:59 +0000 Received: from localhost ([127.0.0.1]:33201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVA3v-0008Km-7L for submit@debbugs.gnu.org; Thu, 23 Feb 2023 06:46:59 -0500 Received: from mail-ed1-f52.google.com ([209.85.208.52]:41796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVA3s-0008KW-4j for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 06:46:58 -0500 Received: by mail-ed1-f52.google.com with SMTP id ec43so40534147edb.8 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 03:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=TfxwvgIcSYBP/sBPfxhYA9aMIGmtzFgpGFWF7JFHRJw=; b=PWcxpD468Y2Z3c3X/5n4gwGb/pHiJ5qQaya2Ecgc5KdYBX3tYaozBigUYVjdA8Ihaf W2EtVXo5Kf7+mjbLU+YAhuoaR1w3o/rhXk4PimUhJcNi/gB0uD1ZyolIemRNMeNK1dNM 48XVY1uevgFdjQOoMD8psduSrPUVrKzSjgME4s3lAA4HVPrEWZVVy5Tfvcy1mn0jUMN6 3OZ9peH9R85UZp67+bH3DzFsRiaA9znAr4xPoacEO3+emEfB1RJjp/dPAZzZLmUJP4fH VS0wPnTyVM2K/z6pCfyhGW8BpGMJtj1xLUwT5mAwV2jVd1pmhliLqKKdf2tBeNAYpTY2 QkEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TfxwvgIcSYBP/sBPfxhYA9aMIGmtzFgpGFWF7JFHRJw=; b=FrzHPzmjRUKDjN7YUEmVLfJ2TuaJ8IqLhhAY2aUlut7k/MOy0+uFWSuccTW3KIpjFo 1VkY2VKLQ83knwzgtm966iWfCtXKCgSQJOl6nB39xk+KbIt6A2TtPNecCItJ9ni+Uhv9 fvhzB4TAXOpch5eM9zMYRq6/a9Tu5JkOUYEy+0hRWtX9DDgsmu8INO8OgL+R6ct1wtKm PMDoD5lnmrDZ5O+5Q6nOJG3T4bJa4YcmP2PFhVsU2qoHxgkZ0wJAcMeV/CtfdPOTGG5R mm4tPbIIKHAhbuPvH7e9NpEW7OF6wTAPm7MrjsaN+v0Hv2ZbUfvpTf8J9vFdL0RuWl/6 eIsA== X-Gm-Message-State: AO0yUKUKCKWVonc3RoRndff9jk46K+cWRVQ/Fxy36lBOY1cC1dzwS476 79HsES89lppEqYcWSXkaMjE= X-Google-Smtp-Source: AK7set+ggJT1x7O4zQnlpcPsrTKpWxMOt+1NV4M88sW/98ArK3W0RDi/8yFgsSFDriypE0ucL94m0w== X-Received: by 2002:a17:906:895:b0:8b1:16b3:303e with SMTP id n21-20020a170906089500b008b116b3303emr18160307eje.65.1677152809935; Thu, 23 Feb 2023 03:46:49 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id fh4-20020a1709073a8400b008cf1b61a73esm5475182ejc.41.2023.02.23.03.46.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 03:46:49 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83cz60r7hu.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Feb 2023 12:39:09 +0200") References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> Date: Thu, 23 Feb 2023 12:46:48 +0100 Message-ID: <875ybsfvtj.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 12:39, Eli Zaretskii wrote: >> I would also suggest preparing the stage to eventually make >> `eglot-current-column-function' and `eglot-move-to-column-function' >> obsolete. For that, I suggest renaming > Please tell more about this, as I don't think I have a clear enough > idea of the issues and the implications for Emacs. These vars were meant to make nonconformant servers (regarding the way they count character offsets) work with Eglot. A new addition to the LSP spec allows the server can announce how it counts character offsets, so ther should be no reason for servers to be nonconformant hence no reasons for a workaround variable. >> +(defun eglot--current-column-utf-8 () >> + "Calculate current column, counting bytes." >> + (- (position-bytes (point)) (position-bytes (line-beginning-position)= ))) > > This is subtly incorrect: position-bytes doesn't cound UTF-8 bytes, it > counts the bytes in the internal representation Emacs uses for buffer > and string text. The differences are minor and subtle, but not > negligible. Right, if the buffer contains a char outside of the Unicode range, we lose. But just to confirm: position-bytes and byte-to-position are always with respect to Emacs's internal extended UTF-8 representation and have nothing to do with the buffer file enconding, right? > What does this stuff do with double-width or zero-width characters? > Emacs takes character-width into consideration when it counts columns, > but it is unclear to me what do LSP servers do in those cases. > Likewise with characters that are composed on display. `eglot-move-to-column' is supposed so count Unicode codepoints, so e.g. x, =E2=87=92 and =F0=9F=98=83 all contribute 1 unit. One the other ha= nd, the Emoji =F0=9F=A7=9B=E2=80=8D=E2=99=80=EF=B8=8F contributes 4 units. This is indepe= ndent of with screen display. By the way, I don't undertand your claim about column counting. If I move point over =F0=9F=A7=9B=E2=80=8D=E2=99=80=EF=B8=8F, the mode line colu= mn count increments by 3 units, which seems to make no sense: this Emoji is 4 codepoints longs and occupies 1 screen column. What's the logic here? > So I think this mess needs to be carefully and elaborately discussed > before we decide how to implement it correctly. Sure. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 07:05:07 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 12:05:07 +0000 Received: from localhost ([127.0.0.1]:33231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVALT-0000Qw-J3 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 07:05:07 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:38469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVALR-0000QK-Hd for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 07:05:05 -0500 Received: by mail-ed1-f53.google.com with SMTP id cy6so35759028edb.5 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 04:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=fhwl4AW8gog6RNRDXUwHdmrEgyRgC5zuPfEicAavfsg=; b=WiZAkoIwG2o+JO5C56WQrramkNK6Bfkh9youq2K787GNdHBLe4ofIXte6F2gRT2dG7 8mIjUfv2xwKGBX59uyqaklriDNfSh7zkjU1UDarD3D/uxmCr3vr3iW00kDLwHkw7HcFv fOvQzcS8re8nF/NA6W73+CB3f/vEJtLzq+2+YD6yfNjn+SMBbBhHDngUbzbycEkdBnmL ZPywHStT4gNKOPkgjLa/jWoPVE38Ux4VDFvhevMF0NqPAm8CfO3vFb+NbJD7hPMPOqNs 2LAnDFwdyDUfPrJbKhjvrDVY1NrNXOQuKwDnocvfEsvuNphVI67h50lGaXmwTXJuwUkC EXqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fhwl4AW8gog6RNRDXUwHdmrEgyRgC5zuPfEicAavfsg=; b=gxZJMIKbkzdBMoaa9sjlsQeAAwSS/DvHi5trv3zFDT4F62DJB4xIIDjffu2GMk8qRq b4ylz4pHF0i2UyIjyqkDiq13pipu4Olbt1QAEGac4epeDxFdwb++i82cE2gso1hklE2T C6QH731MsP+MOuHF5DDIsgFek/hMpq6CnGioMPQ3DxBvFzDNMkn3LS9cQF4f0pKu07NS 7L7GQN3lqf+pY03JueaNA1b0epx0uM7ia92GYQDKLcnqhWTZaZ14aeRycwvWSFgJC9hh j/rElx25LhO7LgozG/iSaTy2EXBCEskYws17delb5x3w972OpLDJmwUtQXnQvVVubMWk AdUA== X-Gm-Message-State: AO0yUKXTiydvoD9bVLhz155RGOVS84zFmyzJU+BB6clU5oX9W+mawNxT qyfUKaiAdT4U4aywtNIPzlEnP/6ntv8= X-Google-Smtp-Source: AK7set9vMhHEkjeVPuOoew/56tCXcwbDAFXKei7zVVMFTw6s2ViqseNdlqUbbgyL2QBgD/wpIuCDzQ== X-Received: by 2002:a17:906:8056:b0:88b:a30:25f0 with SMTP id x22-20020a170906805600b0088b0a3025f0mr17792799ejw.32.1677153899450; Thu, 23 Feb 2023 04:04:59 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id y4-20020a50bb04000000b004ac54d4da22sm3261900ede.71.2023.02.23.04.04.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 04:04:59 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Thu, 23 Feb 2023 11:32:45 +0000") References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> Date: Thu, 23 Feb 2023 13:04:58 +0100 Message-ID: <871qmgfuz9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 11:32, Jo=C3=A3o T=C3=A1vora wrote: > So it's nice that this new capability popped up. But, as far as I > understand, the only benefit of leveraging it is for better > efficiency. Right? Or are we risking incompatibility with some > servers until we implement support for it? Please confirm this, > Augusto. There is no real risk in not implementing this. I don't know how many servers out there are nonconforming, because, in practice, the problem is very rare and basically will only appear if the user is operating on a line containing Emoji or uncommon math characters. So there may well be a lot of nonconforming server out there but we don't see the consequence of that very often. Digestif (which is not very important) is nonconforming because I didn't want to implement such a dumb spec. IIUC correctly, clangd was the group that pushed for this new LSP spec, but being a such a big project they surely support the official way of counting. Anyway, more than efficiency, this to me is an aesthetic question. The UTF-16 way of counting of the original LSP spec is a totally misguided idea and should be avoided. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 07:22:46 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 12:22:46 +0000 Received: from localhost ([127.0.0.1]:33251 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVAcX-0000us-Nx for submit@debbugs.gnu.org; Thu, 23 Feb 2023 07:22:45 -0500 Received: from mail-oa1-f42.google.com ([209.85.160.42]:45747) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVAcV-0000ue-9e for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 07:22:43 -0500 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-172663f1956so5980967fac.12 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 04:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=VnyVNj6XBMFn5wJ+p8zU2L4fm9vWYeghINKObGBbJEY=; b=J1mTYiouyHWTux67rcGTnlMI8lxHwDmWn4L3pIZSdk5ROxepeRibYaKaaG6KtZGJA8 q1kgfbnFTWmKZCCjK/vRQ21q9XqPYY3Sd/qSsJtoeou+Aq/8PvhNlNy8m7itzYowgVfL 8hbwiBw/hkw5GqWNAgTg7L3CheuVGfKGmz3Xh5FwWhncpAzI/FrKCfSd6CeXgQpmP4Pc GsSzbvmiQ83KcCEPnYFSLsyrbc2mRXrE9UrbVM21npeM1kVJBKaOA4a/5q9RYk8aM2rV LOplyBWT3HsmFFP2EB4f124Ai5MaT3MvBg2VbR79ogH9A+bRGKnwiFEDW8uYLGsaXgS1 u4mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VnyVNj6XBMFn5wJ+p8zU2L4fm9vWYeghINKObGBbJEY=; b=BDBZc/9eXCn2JEn596qkMvKez79tJIadv7nx9oQ6JGhP7HB9PUlStpWSlytDVAT9TW seSXsaO2vRIncZP+Q01pOd7hBMaiG1zGoDOjp6iQ0wQFJ1Qed765hDLfFtpWsuX9nT4Y o1Kbsjy6i9E1nDu/bGeMUhV2466CpIAtcqGLX32Ekeaw1e+ubaMXmL+P/gG6DhUB24tG /Leuj6fJJW/mEZ/43eNeJ7MReU8PnKqER4/u1SDNwOuBn5aJ0CYRi4nzVmB5H5D4+qkX 6chwiLe+Li8DlSHxRBuNtJCE74X5mWE44id9cCnK8Zey8AGF27LHTusi6HtZLhhpY+kq 0f2w== X-Gm-Message-State: AO0yUKUipc8EPfvHUgKSpIHSowyChZoNNlmcSfGI73YvZUPXrgeogL4v DNDgG9Emy0Z0Dn09oeKWZaesXcpHP9DLZylZw9g= X-Google-Smtp-Source: AK7set8d3s5RIU92v1Go4THk2zP7XBvivyS8rCVRAjhHmpjLABOm+/FxsfU/cAwYYhJOH3NG+MWo3+sUSHRBTdxrkLQ= X-Received: by 2002:a05:6870:41d0:b0:172:8adb:8e44 with SMTP id z16-20020a05687041d000b001728adb8e44mr184857oac.215.1677154957650; Thu, 23 Feb 2023 04:22:37 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <871qmgfuz9.fsf@gmail.com> In-Reply-To: <871qmgfuz9.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 12:24:19 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 23, 2023 at 12:04 PM Augusto Stoffel wrot= e: > > On Thu, 23 Feb 2023 at 11:32, Jo=C3=A3o T=C3=A1vora wrote: > IIUC correctly, clangd was the group that pushed for this new LSP spec, > but being a such a big project they surely support the official way of > counting. Yep, they do. This was a bug report from our end and they fixed it some time ago, IIRC. > Anyway, more than efficiency, this to me is an aesthetic question. The > UTF-16 way of counting of the original LSP spec is a totally misguided > idea and should be avoided. I agree that it is poor design. But if it works and isn't particularly slow, then I don't think it's a priority to change things in Eglot, mostly because that adds complexity for relatively little value. That it isn't "priority" doesn't mean I would oppose it if you work things out with an encoding expert like Eli and give it suitable testing. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 07:55:02 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 12:55:02 +0000 Received: from localhost ([127.0.0.1]:33315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVB7m-00049i-6G for submit@debbugs.gnu.org; Thu, 23 Feb 2023 07:55:02 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVB7j-00049B-O3 for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 07:55:00 -0500 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 1pVB7e-00081q-Eg; Thu, 23 Feb 2023 07:54:54 -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=SJNm4eMP1bWtPDn98xJxSS1JTsa4mYVlkpJpG4blvMM=; b=iu38bOJxh+6r5SWmVupB yaY27bXaDDcEkeUsE9iddH9qGU89coyvWUEkUwE8S/S6h/RVGdwh9zVLy5r5M/WdWBUl1qttsFlra Kepfw00+VeCygPYSEEhUjRZbXA42fWOf5RmtCkq9PNWPH0R+j3weovN9hTLf4oP6D8WHnxrydggwV 5v5uwoOBgZ3c3uLo4M1LbmkDFFt78Jy9rA5RU3AkMTg4QKPLgt9zoIJjBtHmRwfKEaXfX/HvgUbD/ wgv8pRJNsKyfy0AkEnGDUZisdrQMn1/xE2CCVbRVXSXTwCP0TXD1rt5wzDcYLyP6EnvkNU/a6CRIe oBzWjdE5KWY4bQ==; 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 1pVB7d-00073T-UA; Thu, 23 Feb 2023 07:54:54 -0500 Date: Thu, 23 Feb 2023 14:54:50 +0200 Message-Id: <831qmgr17p.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <875ybsfvtj.fsf@gmail.com> (message from Augusto Stoffel on Thu, 23 Feb 2023 12:46:48 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <875ybsfvtj.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com > Date: Thu, 23 Feb 2023 12:46:48 +0100 > > >> +(defun eglot--current-column-utf-8 () > >> + "Calculate current column, counting bytes." > >> + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) > > > > This is subtly incorrect: position-bytes doesn't cound UTF-8 bytes, it > > counts the bytes in the internal representation Emacs uses for buffer > > and string text. The differences are minor and subtle, but not > > negligible. > > Right, if the buffer contains a char outside of the Unicode range, we > lose. > > But just to confirm: position-bytes and byte-to-position are always with > respect to Emacs's internal extended UTF-8 representation and have > nothing to do with the buffer file enconding, right? Yes. See bufferpos-to-filepos to get an idea of what hoops we need to jump through to get it right, even just with UTF-8. > > What does this stuff do with double-width or zero-width characters? > > Emacs takes character-width into consideration when it counts columns, > > but it is unclear to me what do LSP servers do in those cases. > > Likewise with characters that are composed on display. > > `eglot-move-to-column' is supposed so count Unicode codepoints, so > e.g. x, ⇒ and 😃 all contribute 1 unit. But if the resulting column is then used in move-to-column etc., it might go to the wrong column, because in Emacs each column is not necessarily a single codepoint. The simplest example is a TAB character, but there are more examples, some of which are quite complicated (see below). > One the other hand, the Emoji > 🧛‍♀️ contributes 4 units. This is independent of with screen display. Not in Emacs. > By the way, I don't undertand your claim about column counting. If I > move point over 🧛‍♀️, the mode line column count increments by 3 units, > which seems to make no sense: this Emoji is 4 codepoints longs and > occupies 1 screen column. What's the logic here? If that is what you see, it could be a bug. Does current-column agree with what you see in the mode line? In general, characters (codepoints) that are composed on display into a single glyph or "grapheme cluster" are supposed to be counted as a single column. Try typing this in "emacs -Q" a C-x 8 RET COMBINING ACUTE ACCENT RET If your default font is capable enough, you will see a single glyph of 'a' with acute accent (á), and it will count as 1 column, although there are 2 codepoints in the buffer. And "M-: (move-to-column 1) RET" will move past both codepoints. Now imagine that we get such sequences from the LSP server -- what will Eglot do in terms of column counting? From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 08:32:03 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 13:32:03 +0000 Received: from localhost ([127.0.0.1]:33403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVBhb-00058f-7M for submit@debbugs.gnu.org; Thu, 23 Feb 2023 08:32:03 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:33492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVBhZ-00058B-6X for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 08:32:02 -0500 Received: by mail-ed1-f50.google.com with SMTP id ck15so43370341edb.0 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 05:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=unK1SdoItVX91UiCICB5TzwFBKcA3xXglCBFw7t9foM=; b=abF5Co2lrtu23si2Fw5nHFz8wmqTK4NTp37pASUCAcQkoBLRGHLNGc7cz73ZTT8Nqn jyDps0lPEyEBiHGk1zIOHbjK2O90HrWUqPHkPxFqfv59UiDbM9Q38NTemsH5Ec4x86kM pIszLHkZ+SdGK16rUXxiX2EE6vnXuG56PMYvFsKH5FTSNNRQp734AsprdvjkDRqZS4qz b6raionfg1bHPpkRHu9r/pmGXjchbBFKqAQqRW5uDJa39q673sRJhzKyPvFLz9wH5O6r pDbcwHyOig90y5j8ewVF4Lb5h+BId3Xvw8tjIfUKVjyeZ/ilr+pXiy4VZSo/A0uNFHfb UN0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=unK1SdoItVX91UiCICB5TzwFBKcA3xXglCBFw7t9foM=; b=ClbJO6BS78mTnNtJqD5Wh4EZCIjGyunhDzDDVt+QO3aQQpHKhDtdN761TSrZI23H7w pzMiFYiw5JELM9jVlSZm0w3VADaA9LF8KzATYFp3UzO/vpi6+f92KmC9FxElEslR+8p9 vQVatcfJx1NUuLrk3bPRDxjx3PdSwdRLGeVUcKV4QYHOLbZbODs2Lj++XrmtyBtLCW2b tqULbxS/maGIDOpwkDtnbWtu4kfSYHKKAQIKeIBpwzisjNPORALn/oEt1WZjWN0iGXcd LyLJVsYazFk1BkU0KlJPNXSUqzsdEWwi47aK19NsrYQBAgdMlFcSeeezmFJdD42MDnZr DMvQ== X-Gm-Message-State: AO0yUKV5vqrk1JgmZ1vbKNbbclNYqz+P97arUhh/xpho3NEKz+Ccyhno EtBi79mtuci8RV0CFeYDvaY= X-Google-Smtp-Source: AK7set+ofis14Prn/XgYT6q+hDc1H7TKYkq87cfQkRJSpL4UmwnlEs7e5aYF3MGIwPHj8pB3wTk44A== X-Received: by 2002:a17:907:888b:b0:878:6519:c740 with SMTP id rp11-20020a170907888b00b008786519c740mr24931811ejc.44.1677159114868; Thu, 23 Feb 2023 05:31:54 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id h4-20020a50c384000000b004af62273b66sm1998834edf.18.2023.02.23.05.31.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 05:31:54 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <831qmgr17p.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Feb 2023 14:54:50 +0200") References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <875ybsfvtj.fsf@gmail.com> <831qmgr17p.fsf@gnu.org> Date: Thu, 23 Feb 2023 14:31:52 +0100 Message-ID: <87wn48ecdz.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 14:54, Eli Zaretskii wrote: >> But just to confirm: position-bytes and byte-to-position are always with >> respect to Emacs's internal extended UTF-8 representation and have >> nothing to do with the buffer file enconding, right? > > Yes. See bufferpos-to-filepos to get an idea of what hoops we need to > jump through to get it right, even just with UTF-8. Okay, then we're on the same page. Just to emphasize, the buffer file is totally irrelevant for Eglot's purposes. The only thing that matters is the representation of the buffer text when it's serialized as an UTF-8-encoded string inside a JSON object. >> > What does this stuff do with double-width or zero-width characters? >> > Emacs takes character-width into consideration when it counts columns, >> > but it is unclear to me what do LSP servers do in those cases. >> > Likewise with characters that are composed on display. >>=20 >> `eglot-move-to-column' is supposed so count Unicode codepoints, so >> e.g. x, =E2=87=92 and =F0=9F=98=83 all contribute 1 unit. > > But if the resulting column is then used in move-to-column etc., it > might go to the wrong column, because in Emacs each column is not > necessarily a single codepoint. The simplest example is a TAB > character, but there are more examples, some of which are quite > complicated (see below). There's only one function that uses `move-to-column'. It's very old and I didn't touch it. >> One the other hand, the Emoji >> =F0=9F=A7=9B=E2=80=8D=E2=99=80=EF=B8=8F contributes 4 units. This is ind= ependent of with screen display. > > Not in Emacs. Sorry, I don't understand what you mean. Emas has no say as to how Emoji are represented as sequences of codepoints. The female vampire Emoji is 4 codepoints, if I'm counting it right. Of course I undestand taht the Emoji occupies 1 column in my screen. >> By the way, I don't undertand your claim about column counting. If I >> move point over =F0=9F=A7=9B=E2=80=8D=E2=99=80=EF=B8=8F, the mode line c= olumn count increments by 3 units, >> which seems to make no sense: this Emoji is 4 codepoints longs and >> occupies 1 screen column. What's the logic here? > > If that is what you see, it could be a bug. Does current-column agree > with what you see in the mode line? Yes. > In general, characters (codepoints) that are composed on display into > a single glyph or "grapheme cluster" are supposed to be counted as a > single column. Try typing this in "emacs -Q" > > a C-x 8 RET COMBINING ACUTE ACCENT RET > > If your default font is capable enough, you will see a single glyph of > 'a' with acute accent (=C3=A1), and it will count as 1 column, although > there are 2 codepoints in the buffer. And "M-: (move-to-column 1) RET" > will move past both codepoints. Now imagine that we get such sequences > from the LSP server -- what will Eglot do in terms of column counting? Right, I undestand the Unicode business (thanks for the pointers in any case). If you look carefully at the Eglot code, you will see that `move-to-column' only appears in the code pertaining the =E2=80=9CUTF-16 wa= y of counting offsets=E2=80=9D, which 1. is old and I didn't touch in this patch, 2. seems to work correctly, despite looking suspicious, and 3. will not be used anymore when both Eglot and the LSP server supports the positionEncodings capabitily. I hope this motivates you to add this feature =F0=9F=99=82. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 10:04:25 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 15:04:25 +0000 Received: from localhost ([127.0.0.1]:34929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVD8y-0007xP-N1 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 10:04:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVD8w-0007wy-8f for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 10:04:22 -0500 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 1pVD8q-0001nX-VS; Thu, 23 Feb 2023 10:04:16 -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=JIjj/zs6iaqEXhtS8W6GRu/p9BFhJAz5T1bYWkdoPJg=; b=R1Ijhue8rkPwAOdvHFe9 te6ICIS+FIX0+CXm/DBiUxWmAMZZWEXWH8eipIyvOVD2hJmO3EXhoH1JlA7SUJCEy5oRzV4PvB5RV RpgIrAtV5prV+g9ngQBan5LI7yi1LVone9tUxsSJneZKyB60lWqYDasYaGbpNBsQ8wqOySG2nEmlD xB/w1rat0qPZT2mlroL8IMX89HgLQ7r4MTTvxnoCZ0Fqo+rgP0aOhL3tdhonLkWW7SfV+RlseGY2b n0dTm1zbLM+t8ijzPawM2/wmah2Z414Sx48GOaSU6MktccnCf25MLxs/6ZNMmJUw7HQOD6mmd0Sg3 Q/pSF92OhwUC9Q==; 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 1pVD8l-0006uB-J7; Thu, 23 Feb 2023 10:04:12 -0500 Date: Thu, 23 Feb 2023 17:04:08 +0200 Message-Id: <83v8jspgnr.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87wn48ecdz.fsf@gmail.com> (message from Augusto Stoffel on Thu, 23 Feb 2023 14:31:52 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <83cz60r7hu.fsf@gnu.org> <875ybsfvtj.fsf@gmail.com> <831qmgr17p.fsf@gnu.org> <87wn48ecdz.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com > Date: Thu, 23 Feb 2023 14:31:52 +0100 > > On Thu, 23 Feb 2023 at 14:54, Eli Zaretskii wrote: > > >> But just to confirm: position-bytes and byte-to-position are always with > >> respect to Emacs's internal extended UTF-8 representation and have > >> nothing to do with the buffer file enconding, right? > > > > Yes. See bufferpos-to-filepos to get an idea of what hoops we need to > > jump through to get it right, even just with UTF-8. > > Okay, then we're on the same page. Just to emphasize, the buffer file > is totally irrelevant for Eglot's purposes. The only thing that matters > is the representation of the buffer text when it's serialized as an > UTF-8-encoded string inside a JSON object. The buffer's file is not important for the issue at hand, only its encoding is. And in the case of Eglot, the encoding is still there, even though there's no file involved. So the code in bufferpos-to-filepos is still very relevant, as it shows what has to be done for such conversions. > >> `eglot-move-to-column' is supposed so count Unicode codepoints, so > >> e.g. x, ⇒ and 😃 all contribute 1 unit. > > > > But if the resulting column is then used in move-to-column etc., it > > might go to the wrong column, because in Emacs each column is not > > necessarily a single codepoint. The simplest example is a TAB > > character, but there are more examples, some of which are quite > > complicated (see below). > > There's only one function that uses `move-to-column'. It's very old and > I didn't touch it. Then why does Eglot want to know the column at all? > >> One the other hand, the Emoji > >> 🧛‍♀️ contributes 4 units. This is independent of with screen display. > > > > Not in Emacs. > > Sorry, I don't understand what you mean. Emas has no say as to how > Emoji are represented as sequences of codepoints. The female vampire > Emoji is 4 codepoints, if I'm counting it right. What I meant is that the number of columns a given sequence of codepoints will take on display is not equal to the number of codepoints in the sequence. This is so for Emoji sequences as well. > > If that is what you see, it could be a bug. Does current-column agree > > with what you see in the mode line? > > Yes. Then at least it's not a grave bug. current-column and friends doesn't support all the quirks of our display code which can change how many columns some sequence of codepoints can take on display. It does support quite a few of them, though. > If you look carefully at the Eglot code, you will see that > `move-to-column' only appears in the code pertaining the “UTF-16 way of > counting offsets”, which > > 1. is old and I didn't touch in this patch, > 2. seems to work correctly, despite looking suspicious, and > 3. will not be used anymore when both Eglot and the LSP server supports > the positionEncodings capabitily. Positions do not necessarily transform to columns easily. So, depending on how Eglot uses this information, we may or may not have problems. In general, reporting coordinates in columns between programs is problematic. We see this in many cases, starting with spellers. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 12:01:44 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 17:01:44 +0000 Received: from localhost ([127.0.0.1]:35167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEyW-0002iM-Ca for submit@debbugs.gnu.org; Thu, 23 Feb 2023 12:01:44 -0500 Received: from mail-wr1-f47.google.com ([209.85.221.47]:35663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVEyU-0002i9-Vk for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 12:01:43 -0500 Received: by mail-wr1-f47.google.com with SMTP id q16so863319wrw.2 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 09:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=WoRKa7gZGJNJRRJfLQ8q2TNy7gtCK+uu3rzvgkdCImo=; b=bRhYgVBJxyr9/tSMM5zWyRqAvYyX76nhspL1m3Mi/PgPNyjjhiP+BuWyGLvlQXgdzU 7gQ6hWRgVhgDj6bXov/XAK1Q5cQj/sDN8N84W00VQIUYfsLsR2rcKtt21M4FAY3giy2j ABu0WYpayWTtH54NuN0VnRwm1ymLhb04h93wGAQ0mM2FzrKQM15sil1wfn8A6ruxvzN9 jPLsOHMZo5ps0YDSAovxs6w6Pm5YOisUH5eOA/cJyl7ZO21oxWB0ng/eH6sLAlss4/Eq PqZJsV4IM0seyW2wkziZGBJR6xaXXL8Eu1LMxqJIgYBLhz1PJu0Pccs7OyeH1OzyUE05 YxUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WoRKa7gZGJNJRRJfLQ8q2TNy7gtCK+uu3rzvgkdCImo=; b=AxL2EqAMUKIGs7IEhprYsQEUkhBDic4GN28sLcXOv4TOOu4nTOCAtrYj0WY4/2kir3 WQiGaqh6iBrK0Et9mMbL5oTUjGtXNZ3FZEK2nQ1qjnoQKXZxOiy0SQ2+0269S+6XBgc1 22wrHxGSF+847x3GF4strnT+moTFzAnKr+Q3EPE0dys6Bu1CcAWoeydx9/DG04wMLtrU qYuGqKaEfMWNS5QpW55N/jUKzstS5Dko3I/ELnuKMB+JrG/8GJn/ccRWJoigNNZ3Adlh g0DSA5SUd5WzZEDuxB2iBEf+r1cp0sKPHM5unRtWqo7GnfGewXRy/r/nDzekYuOjHkI/ V8sg== X-Gm-Message-State: AO0yUKXxo4uht7pTT+PO+PPmKNaQeggwhB/a6sgYQWEsYWcwuFxHCRbT MAEVzP/M1QZM4xUlUVeeHt4= X-Google-Smtp-Source: AK7set8r9aIPf8Lo7/SjdhIVMMVQFzwbxEx+McImRaWwAyGjmc3/rC9eb+QfWldrqCkRBTgeCQJ+Vw== X-Received: by 2002:a5d:558d:0:b0:2c7:103f:7122 with SMTP id i13-20020a5d558d000000b002c7103f7122mr2439894wrv.28.1677171696940; Thu, 23 Feb 2023 09:01:36 -0800 (PST) Received: from betli.gmail.com (catv-86-101-66-128.catv.fixed.vodafone.hu. [86.101.66.128]) by smtp.gmail.com with ESMTPSA id s14-20020a5d510e000000b002c569acab1esm11069721wrt.73.2023.02.23.09.01.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 09:01:36 -0800 (PST) From: Felician Nemeth To: 61726@debbugs.gnu.org Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> Date: Thu, 23 Feb 2023 18:01:35 +0100 In-Reply-To: <87a614g628.fsf@gmail.com> (Augusto Stoffel's message of "Thu, 23 Feb 2023 09:05:35 +0100") Message-ID: <87y1oofh8w.fsf@betli.tmit.bme.hu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUMBwgHAgMFAAGPjY7/ //80MDHq6eqJt3pKAAABr0lEQVQ4jX2UzZKDIAzHqR177q7TPbtx2HMr6guQcrbY9txZ0fd/hA0f onXazcEJ/CD8E4Js8/HS9mwjXtqeMRxHXJkakTEm4b4GPVQW8PU8ov4fQCqeThlF60MBWdo1IXzd 2nEEZE7CEAZLwI0N/gJAhTj7ESQAX4gPgO8lyI+cvgViSVPlNomAj2M9gW40eg7VWY3cATjUcyiO Z+i03cFruGLYoUR7VyU3HihdmCEVhoDN65FXkpbSxkomOzsTQN/gySaodGb9Gdi1oSRXP46gdBWh LcUKJNdeGCWac74GKakmne0aHCFvyqJPYLsCFAVlhRTvGdzMdLHqtgRyUulyXIAH7CYQ3AB0Nody JQhAkq/qtOnbjhxdzYDkXPxlH5y4WdUAeUcX1NVJ6GR7UQEYPGWoAnA36OQNn5lRRp38vHTAp9Br LoTmvlPPDoRCKzpjG1SXT89AaT5l456BamJuMcs+NIOMzJ/s5dI6yUVcrARlruwOebfdv6gunTn4 ww3+QjGBEn5suVyLHoSGvAqREuDLN+iqZ+VcFg+HBbsJUU9+FZthbez9T+bdb+kPv2Ls6ct3hTkA AAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: Augusto Stoffel , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Augusto Stoffel writes: > Tags: patch > > There is a new LSP capability allowing the server and client to agree on > a way to count character offsets. What do you think fo the attached > patch? It closes https://github.com/joaotavora/eglot/pull/916, hooray! I think the patch has a small bug. With it, Eglot always negotiate the encoding with the server, but when the user sets eglot-current-column-function or eglot-move-to-column-function, the result of the negotiation is ignored, which might confuse the server. (In the long run, it might make sense to let the list of the offered encodings configurable.) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 12:11:50 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 17:11:50 +0000 Received: from localhost ([127.0.0.1]:35184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVF8I-0002zx-Il for submit@debbugs.gnu.org; Thu, 23 Feb 2023 12:11:50 -0500 Received: from mail-oa1-f50.google.com ([209.85.160.50]:43676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVF8G-0002zg-Mj for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 12:11:48 -0500 Received: by mail-oa1-f50.google.com with SMTP id 586e51a60fabf-172094e10e3so16235539fac.10 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 09:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Lu0AIW1i9MkQgsbQOwGbNlg0RLLYpy5qwMwDa59nyNs=; b=UbO9OfA9wLsRq/Cmt/RJPUR1PMSj/3fI9bzvLMZXmCzseIiAHcKFQQmYbxb/efzKt0 r1h7fSK6n4aJg0/x5CHsO+qHlqvLozJ9kdD06GgH2wzMDbErko2mi1Nzx8Ri0Q9DLMDv lzSomqfTOGphR/xlxiCWtRuqmtScaTGySbCOL6a72dkt4/qh/zW8xFsTFKesmWmGK4mS egy+xL5hdfq3FdyM5V3+E5yV08ETSKUKDisOhdISZYHmd2Vm4sreer+T1gN0tzqd44Ka q/aQgk4EahW2jhHNJnvk8pQ3mmu96unOPDjLqtkBzT4hsTN5S5e6QjqNi9lfwx2JNMqc /3Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Lu0AIW1i9MkQgsbQOwGbNlg0RLLYpy5qwMwDa59nyNs=; b=2puObjmbTT8WBRp8wAD9utdpPOMsUIXbeFxVqdeyp1FLAhHRXoIv4VBV95QttdKKsn k2tzgYBPh7TVq9yjd8mBEO6KDrC2q3aT4/foD9mj1FxdFqmD0p4F6Nz+Su0CGfO4D+vd NeSFH5E/1kXZlajYjaGlB6XdverYJzIuvCSWzrPKF+mVapxmmSHakQ18ftgKbYYasAc+ cO7+F3AeW7D0XrAKNpE0GZuOWSOtcinBaBz26PWBSZvlwEchJq4lA4X5XHVd0DbqUZLT 1doggXhqy4kVOjbab8+ZNNPY5pjZRARBGlGDKoM4o+JFAqXGJjh9IJFlCZmCACup2plu RzAw== X-Gm-Message-State: AO0yUKUPsASRfuxt2wkZxFaKdurQ2dM7KMYTjyAFAYO8RlZ4/QXQ4q23 rHHw3bxfiPkPdXaqjRnjhCZkq4tY+C9rmtg/4VQ= X-Google-Smtp-Source: AK7set+StJwpDSP6z9xYJ06yPz00tWsWZP6dtwM7XssAEKzZNALSheUZQgb7EOWlvECzut8P227saJ4rGTI0cH5QhrI= X-Received: by 2002:a05:6870:41d0:b0:172:8adb:8e44 with SMTP id z16-20020a05687041d000b001728adb8e44mr255512oac.215.1677172303043; Thu, 23 Feb 2023 09:11:43 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> <87y1oofh8w.fsf@betli.tmit.bme.hu> In-Reply-To: <87y1oofh8w.fsf@betli.tmit.bme.hu> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 17:11:32 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Felician Nemeth Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 23, 2023 at 5:01 PM Felician Nemeth wrote: > > Augusto Stoffel writes: > > > Tags: patch > > > > There is a new LSP capability allowing the server and client to agree o= n > > a way to count character offsets. What do you think fo the attached > > patch? > > It closes https://github.com/joaotavora/eglot/pull/916, hooray! I had completely forgotten about your patch! Sorry! Well, re-reading it, it doesn't seem as complex as Augusto's. Is it also as functional? Do you want to abandon it in favor of Augusto's? And can we get a simple performance measurement before&after, maybe for both patches? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 13:42:39 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 18:42:39 +0000 Received: from localhost ([127.0.0.1]:35295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGYA-0007xc-N1 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 13:42:39 -0500 Received: from mail-ed1-f44.google.com ([209.85.208.44]:43784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGY9-0007xN-6g for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 13:42:37 -0500 Received: by mail-ed1-f44.google.com with SMTP id h16so45831813edz.10 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 10:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=8nH0wk3jn6g4DdEaZhgkUP2UugxWdhMf3zVh2NN+1i4=; b=SfKW/eyJnr14rz7sQWFzOxy6FvDXx0y3qyWf9IHilwLG9wolB/JkmdD4r13zB6nbHP k6n8TaTM/ig4YzOBQEjTahKi7Dav19IkAtXO9QIq4OjmLom+OAzworQhSb/qbvBMnoPy cIfjWFJ8UNBA/+4eOzS21+Jvm7el1vUMR9aEujAFhXHTpbXCF/X/JeSNephcv57plN3e SZO/YC6voa3DUF28QxgEApoPRONIsuMNDlq7erYq8sFCSOy7B5iEJAAHTxi8mZS8ZEQz mutz8AR850/ehQrZLuuXoE+D204ufDleUGoNFPc7XNTAn8xSwF5zhQEVk+pEi5g0WKFe KbNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8nH0wk3jn6g4DdEaZhgkUP2UugxWdhMf3zVh2NN+1i4=; b=MGllUzdWdGMTW5AFqoiSybFa5SniowkCWAy2SNwlkHlQ0xMQ4qNoRvJotF0rO1txkH LO5QMR4uN5uccHAr1Km1oVQTAfh8/WU7/ffRcwkI/CCK4KW2CjpdEIf0QBukddEDMpVx 4H6oJMrVwxDpylJuGfWSDGP1IMVXg6k8VllweZKqT6tTh1KUQsB3fzPfJhmPYdLzh/43 D0uAdCzpnOXVT6VkSMrcRd1R5Lr3xraiv+7BrjXvhhvdTQ/drMRS5v5ufABUCAcpuw7R 8nSThWjFWhOd39uQkMpLEGdCoC/MVj+4Pvlz6hBGJiQoQcR1ika6kDwtbNlZJS/EXeKZ R86w== X-Gm-Message-State: AO0yUKV24ZE3yFxm1Wj8XsyCL6bResBBv5oCuW+Ykb4p3HoBvI1swHEr AyBQSmJFn/f3LXSntMymDrA= X-Google-Smtp-Source: AK7set/lTKM2bJtyRbBb2xjL1NSM16rDLjxijqfawSSTBXoRTKPU5DlDkeqcGtWOkDv/xJ4tU6clsw== X-Received: by 2002:a17:907:62a6:b0:8ed:5a7e:5e44 with SMTP id nd38-20020a17090762a600b008ed5a7e5e44mr3514671ejc.34.1677177751140; Thu, 23 Feb 2023 10:42:31 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id fx11-20020a170906b74b00b008bc8ad41646sm7464120ejb.157.2023.02.23.10.42.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 10:42:30 -0800 (PST) From: Augusto Stoffel To: Felician Nemeth Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <87y1oofh8w.fsf@betli.tmit.bme.hu> (Felician Nemeth's message of "Thu, 23 Feb 2023 18:01:35 +0100") References: <87a614g628.fsf@gmail.com> <87y1oofh8w.fsf@betli.tmit.bme.hu> Date: Thu, 23 Feb 2023 19:42:29 +0100 Message-ID: <87pma0dy0a.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii , =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 18:01, Felician Nemeth wrote: > Augusto Stoffel writes: > >> Tags: patch >> >> There is a new LSP capability allowing the server and client to agree on >> a way to count character offsets. What do you think fo the attached >> patch? > > It closes https://github.com/joaotavora/eglot/pull/916, hooray! > > I think the patch has a small bug. With it, Eglot always negotiate the > encoding with the server, but when the user sets > eglot-current-column-function or eglot-move-to-column-function, the > result of the negotiation is ignored, which might confuse the server. This is intentional, so let's see if you agree with my rationale. Currently, the point of eglot-{current-,move-to-}column-function is to override the behavior of nonconforming servers. There's no reason to touch it if your server conforms 100% to the spec. (Note that if you update your nonconforming server and it now became conforming, then all of a sudden you setup is guaranteed to be broken; you need to unset those variables!) With my patch, the purpose of these vars continues to be to override the wrong behavior of a defective server. So of course it should ignore the result of the negotiation. Moreover, I would like to mark eglot-{current-,move-to-}column-function obsolete (preferably right now), so it can be removed entirely in a few years. By then, there should be no excuse for nonconforming servers, since they can use the positionEncoding protocol to stay away of the UTF-16 nonsense. Of course, if that proves a wrong assumption, we'll just keep those vars around for longer. What do you think? > (In the long run, it might make sense to let the list of the offered > encodings configurable.) I don't think I understand why. We would already be offering all 3 positionEncoding options. The server can pick whatever they like and we'll deal with it. Everything should "just work", no need for configuration. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 13:52:52 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 18:52:52 +0000 Received: from localhost ([127.0.0.1]:35304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGi3-0008Hm-Rl for submit@debbugs.gnu.org; Thu, 23 Feb 2023 13:52:52 -0500 Received: from mail-ed1-f47.google.com ([209.85.208.47]:46841) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVGi2-0008Hc-Sw for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 13:52:51 -0500 Received: by mail-ed1-f47.google.com with SMTP id x10so44974263edd.13 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 10:52:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=xaj8Jz8+U++pdmDlbhsicx3uhZr6UxTchjKeGqDIWKk=; b=RLSxqCFN/LNdT7gl9cxI+yQYCWgvsuPZw1iUU1i75kj3CBVt3j9CECcupvq/YnMAM7 Eisc7W8j1XcPxoG+cC2M1r/89UvgJZqMFEJt2oSlX4+F0GSiTHHR4C6PMmQ9WQbgN0OW 8uNuf2jUIKeUsOm3i4bjGK5iSu02G8NeEAkJawonSDZAuiGtaEBIG5DiG31AhYhM/PFz jzHAWkkOkI+thUvjhMMJzjEWKKXQZ5Mhyl7n2pz9ro5hL1ahXEqmKJbLSMc1Xt7OGkea WZST9Dfcr3rYz6HY9VT5n3X0wkqvgbDZxHkirxqWk5WehKUJc4/46IN2jC9ZjjMGM8oR W3jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xaj8Jz8+U++pdmDlbhsicx3uhZr6UxTchjKeGqDIWKk=; b=50dkyghx5y05KbP1BdB4QoVOBAee4Z1nXJyjGRLFnvaF7Ik/o0ixtMA0lKAxoRGkRj dYNoVoNrTE/BJ22WqDJI4gvtOvWt5Z1IgfreY223AhcccN2YJkQkgyV/IYOiYyHBXUqU Zu5gSn3wwFhbmg1PD9eRmCF934GOklO1g5sFidhNLECnmCab7/oNl2gDntbaziNKKOZb T4XM+VWz32b3BYsGgssTbZCPEr4fPAkKrIZCZR6XRNwrxdUC3Ur5eXPcSwKiYU5bSbjg BTVmImdRFwq07aqB+/IVjxAa8DTRvI8hstlYeLPs7wc1D6UZe02jCGWJj4hN2fdPl5tq qkVw== X-Gm-Message-State: AO0yUKW+IacOM1m7Ls7fGFmFITRMm1UywlLcOMeSIemlrvWU4LtI5/MP /YfFKbvBMnjr0Q+bCE8R8p8= X-Google-Smtp-Source: AK7set+beu2j1z2WN5IXDd1yWbpoNlwLWGt9WzEPFc2fqNj+JfkQPeWg8a1UzWwuXt05kC+ekK5DAQ== X-Received: by 2002:a17:907:7295:b0:8af:3930:c390 with SMTP id dt21-20020a170907729500b008af3930c390mr32149759ejc.62.1677178363615; Thu, 23 Feb 2023 10:52:43 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id gs23-20020a170906f19700b008ba326ebaffsm7719074ejb.191.2023.02.23.10.52.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 10:52:43 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83v8jspgnr.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Feb 2023 17:04:08 +0200") 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> Date: Thu, 23 Feb 2023 19:52:41 +0100 Message-ID: <87lekodxja.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 17:04, Eli Zaretskii wrote: > Then why does Eglot want to know the column at all? In the Eglot context, "column" simply means "offset since the beginning of the line", where "offset" can be counted in one of three diferent ways: codepoints, bytes of the UTF-8 representation, or bytes of the UTF-16 representation divided by two (a.k.a. code units). (Number of cells occupied in the terminal is _not_ one of the ways to count "offset", thankfully!) I don't think "column" is a particularly confusing name here, but if you want to rename this, now might be a good opportunity. >> If you look carefully at the Eglot code, you will see that >> `move-to-column' only appears in the code pertaining the =E2=80=9CUTF-16= way of >> counting offsets=E2=80=9D, which >>=20 >> 1. is old and I didn't touch in this patch, >> 2. seems to work correctly, despite looking suspicious, and >> 3. will not be used anymore when both Eglot and the LSP server supports >> the positionEncodings capabitily. > > Positions do not necessarily transform to columns easily. So, > depending on how Eglot uses this information, we may or may not have > problems. > > In general, reporting coordinates in columns between programs is > problematic. We see this in many cases, starting with spellers. Yes, I agree this is problematic -- as soon as you leave the wonderful world of UTF-8. The point of this patch is to stay in that wonderful world as long as the server agrees to it, which I hope will become commonplace. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 14:20:45 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 19:20:45 +0000 Received: from localhost ([127.0.0.1]:35378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVH93-0000dV-D0 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 14:20:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVH90-0000dI-SV for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 14:20:43 -0500 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 1pVH8u-0001xt-5N; Thu, 23 Feb 2023 14:20:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=HEDf4lZrTqZqrNwMFRx9275cwSbfkGLPCIgu3W2Yd/Q=; b=nm6hvvPD39dZ qkXzYR007L+0pxnbWaO7ecBKXvrc3go+6aKCUR5qAxJsMsZdTXA16fCpv1VBHS7NsYk44EJW9pol9 IvWc4XuaetHbeHgssr6uCt+3mjZc5v+m9CW5pUgU4WeJvcuKKQftFbSZpRFJwtlKtZhot66VVufqc qQwvHN/+pNpoJQGbspF4n0uBwyWd/z283Qty48ltFk3cQNJrAeS+RyjJpTEOPEef0kHjF8t5X+6Dp dApM0EOjq5kkh43o+2eM+YEvWKuLALRPjnZmTiTRl5vCJWlPu8yopiCZ8b71trYvPcGdKioiLf/NX Utx/tpRdkNiD6YAX1xJNdg==; 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 1pVH8r-00087G-WA; Thu, 23 Feb 2023 14:20:35 -0500 Date: Thu, 23 Feb 2023 21:20:30 +0200 Message-Id: <83a614p4sh.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87lekodxja.fsf@gmail.com> (message from Augusto Stoffel on Thu, 23 Feb 2023 19:52:41 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com > Date: Thu, 23 Feb 2023 19:52:41 +0100 > > > In general, reporting coordinates in columns between programs is > > problematic. We see this in many cases, starting with spellers. > > Yes, I agree this is problematic -- as soon as you leave the wonderful > world of UTF-8. The point of this patch is to stay in that wonderful > world as long as the server agrees to it, which I hope will become > commonplace. Actually, the really "wonderful" world would be if the offsets were reported in character codepoints, because buffer positions are both the easiest for us to count and are unequivocally defined. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 14:29:10 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 19:29:10 +0000 Received: from localhost ([127.0.0.1]:35392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHHC-0000rQ-10 for submit@debbugs.gnu.org; Thu, 23 Feb 2023 14:29:10 -0500 Received: from mail-oi1-f179.google.com ([209.85.167.179]:44720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHHA-0000r8-2R for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 14:29:08 -0500 Received: by mail-oi1-f179.google.com with SMTP id q15so5743536oiw.11 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 11:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677180542; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bakPuTRRxXUd+SEBHlvZ7vjC3Buj2hXLkCmF50q7YAg=; b=CxuX2Q15Q3GyPk6ikt9r7ZEpZOP9qOYeb2bsefs4VM/NbgMnSXe/tDJwmSaefS1Gpf yH0IfZxY+h2YXkm/1rj9H+RZUn25JXpZQBazuoRcsqQZHLBwMAdmGyGk0sV+fWq066n7 sqHBU8Bd6M/YJ7iNdtyl4fx+DTfPUX20X2N3U+nXj1KlQ31wc6zZtLu1JHaGmdUUc8+1 6M/4f8EM3M60RnL1apxN2xxJjsM7WMEl86BYJP31e+Cgy+6DQ8RZka2+++PszbpWbb9I 6ktSFqMBBGpKCnK8afDHerBIL+7Cpe5FWAALQlBXguSvgVliZLzVgUu+OolL5MUZX9Ds pspA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677180542; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bakPuTRRxXUd+SEBHlvZ7vjC3Buj2hXLkCmF50q7YAg=; b=oRahrtNB9/K9np/pvxiY2sAZON80iKkNWoLET3Yjze883V+i0nUuw1qGfc7c5V4VBH yvs1a052+Hpbj0k+CRyp8ZizWkXFweFkFn/j5JskxLaAyQcgcEZgJ645rrUfQHOyKdG3 IHUv3QAe/KgiMlumyLYlbmH5K1kjlebgvArqRXgKQX0evgeSd7XxttjcT25rMyiSyKhL YYh/LsMiTKLeXIGUG5cWSrkwgGP0SfL77Jbsod8sPrN8v/jYUwyzb0TgVbtWWsXA5Brt v9Mdd87kiQnn2Syn2zLrIX0CSTZgq44eodrTwDevkzLlTxVYsD769aC08D/+y/757ZCR Mmnw== X-Gm-Message-State: AO0yUKUSkm+ehNYHybN564tI02YbA3ckWqVVIj8CwzoH0nSyHSTSaVD3 AcGAQ2NBRjlQSI9Muf1s8S43nL1AcD5XYcQq3I0= X-Google-Smtp-Source: AK7set8VRDDJ3FT7rKkSfi5jjG7grLAP+zgEdnXR2KJDIhK4MLbXMhKVV9RMxGI7m5+pwMbUJozqJxPlu4aYZ4RTrcg= X-Received: by 2002:aca:1b04:0:b0:383:d3ae:2ef4 with SMTP id b4-20020aca1b04000000b00383d3ae2ef4mr297384oib.8.1677180542246; Thu, 23 Feb 2023 11:29:02 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83a614p4sh.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Feb 2023 19:28:51 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 23, 2023 at 7:20 PM Eli Zaretskii wrote: > > > From: Augusto Stoffel > > Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com > > Date: Thu, 23 Feb 2023 19:52:41 +0100 > > > > > In general, reporting coordinates in columns between programs is > > > problematic. We see this in many cases, starting with spellers. > > > > Yes, I agree this is problematic -- as soon as you leave the wonderful > > world of UTF-8. The point of this patch is to stay in that wonderful > > world as long as the server agrees to it, which I hope will become > > commonplace. > > Actually, the really "wonderful" world would be if the offsets were > reported in character codepoints, because buffer positions are both > the easiest for us to count and are unequivocally defined. I quite agree. Is this "count in codepoints" capability defined in LSP at all? If so, I'd rather we add support for it over other slightly less imperfect methods. If not, we should lobby in LSP forums for its addition to the LSP spec. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 23 14:52:17 2023 Received: (at 61726) by debbugs.gnu.org; 23 Feb 2023 19:52:18 +0000 Received: from localhost ([127.0.0.1]:35402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHdZ-0001Vm-KG for submit@debbugs.gnu.org; Thu, 23 Feb 2023 14:52:17 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:46050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVHdX-0001VY-5m for 61726@debbugs.gnu.org; Thu, 23 Feb 2023 14:52:15 -0500 Received: by mail-ed1-f51.google.com with SMTP id eg37so42594749edb.12 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 11:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=T49RBVzl0EjmM/Tt7UiCNrK4cjnT/UT7nHK117UYqM4=; b=jm2zQAL/UaFDkNaIVbmQ/4EHD+y5m3mrTrLMWMfpjKdypmFRcnb1Jk+6HVBjOcR2TJ FeVs1Fx0T1tf4IWZV1AMLl3MKr7y4uewCa1O6kuBYWEUbXdhpd1W0kz8M13YeZWeWPrQ xCYnFitRyw27tUUTALaVnTQgrWhdb/l694EEYUAir4x3sMNK9gvhEwPM5TlYo7I2FYVZ YYkecFsO/bDisVYmzJvd9QRYuRit3YkTUIQKAfr7qKrcQwkXID3uJYCgKmcebLj3TtUJ ZzCfQQf0KihjNpdOldSKMl+BMZ3EAmnn0Fo7ObZlJJpKVJbhhb2YGMPYA/xlGk2+v5B1 0ffg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=T49RBVzl0EjmM/Tt7UiCNrK4cjnT/UT7nHK117UYqM4=; b=PgZOgW+SY0cPXq69+JAhL67ZHKiVu1SuLWeKknJv50zF1IVni2cfavw2bARNreq66/ cb85J/e26717Oxtd7aQV7a94auOxARJ3Oyas6ao8X6F0J/f3e8n0o6eT2b0zIbFP1IMB 9UWUv2/dsKtuKIkGEsMufBchhTlxOWifdS2zYigTu6qazd3ptDUlqohR1VowPC8rjQC7 0n6+LidDf90+Gjr6SpT2SwkMzYaA+cyb9Dfo4uj5N+XKgc3P5erox/edExmunRgAq8sX j5ElZC33kHZmE2uCR7nFK0ArAOumIqOMjCeCkqx8Hxx0zUYLLox71Gt2i+n+NoWiObA+ TXlg== X-Gm-Message-State: AO0yUKWMGOEq+HHejQsnSBLHOJGryH1pyZEdSMPr+lX4aif906kHpDBy OktYzTa5975GmWwdrt7DNH+ATJcSaIU= X-Google-Smtp-Source: AK7set/WcBv6crUppkxa3gl/6NgA7ZCGUxjg6FT/BinxvXLyTUrRO+wPt6x8LCBbdi8cjYDTYxjOHA== X-Received: by 2002:a17:906:9bec:b0:8b2:fa6d:45e6 with SMTP id de44-20020a1709069bec00b008b2fa6d45e6mr22056531ejc.2.1677181928872; Thu, 23 Feb 2023 11:52:08 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id md16-20020a170906ae9000b008cafeec917dsm6320017ejb.101.2023.02.23.11.52.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 11:52:08 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Thu, 23 Feb 2023 19:28:51 +0000") 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> Date: Thu, 23 Feb 2023 20:52:06 +0100 Message-ID: <87cz60dus9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 23 Feb 2023 at 19:28, Jo=C3=A3o T=C3=A1vora wrote: >> > > In general, reporting coordinates in columns between programs is >> > > problematic. We see this in many cases, starting with spellers. >> > >> > Yes, I agree this is problematic -- as soon as you leave the wonderful >> > world of UTF-8. The point of this patch is to stay in that wonderful >> > world as long as the server agrees to it, which I hope will become >> > commonplace. >> >> Actually, the really "wonderful" world would be if the offsets were >> reported in character codepoints, because buffer positions are both >> the easiest for us to count and are unequivocally defined. > > I quite agree. Yes, everybody agrees! > Is this "count in codepoints" capability defined in LSP at all? That's _exactly_ what the patch implements =F0=9F=A5=B3. And then it also provides a second option, which is to use "bytes of the UTF-8 representation" as the unit of measurement. And then only as the third option it falls back to the "LSP abiding" nonsense. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 01:43:43 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 06:43:43 +0000 Received: from localhost ([127.0.0.1]:35852 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVRnz-0002BZ-3U for submit@debbugs.gnu.org; Fri, 24 Feb 2023 01:43:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVRnx-0002BL-B7 for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 01:43:41 -0500 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 1pVRnq-0007OP-7m; Fri, 24 Feb 2023 01:43:35 -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=Al25CSn9iFm7kwhQ+mWoNFG5PSNtR2EHiFWCVtpLYPc=; b=pMC7eXr0bLfzRn/hYPZq GnBwvezlx9Kz7BUITHcz6kD+7C5C699Tgnlgk6ln7EnMtRhy+RzbkFggzFkQq3IORdFFcv6zrgk04 2zP/VA1TR8JVjBdTnCeM5KJfirzNfKQOwIzo7CaV50mYxB8JSXwqMagmSx36vVkyv86eu6ZMzTvv7 ed2LL5FfX5gUCTp8uTlnrJEH0HdBF1F0Kt2DrmBJ+D1wlF3RG7oFURTBuf7A6rTJolR86ZDrerRYu AlubciRsr73+iUiAaeyw5lK/sEVJzux7OnogbXqMp+TZpceerWWU73G29S0btp4u9cs6MfoS/q04Z XVT6BSSKtSVn0w==; 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 1pVRnp-0000Ua-Lk; Fri, 24 Feb 2023 01:43:33 -0500 Date: Fri, 24 Feb 2023 08:43:32 +0200 Message-Id: <835ybrpnqj.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87cz60dus9.fsf@gmail.com> (message from Augusto Stoffel on Thu, 23 Feb 2023 20:52:06 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > Date: Thu, 23 Feb 2023 20:52:06 +0100 > > On Thu, 23 Feb 2023 at 19:28, João Távora wrote: > > >> Actually, the really "wonderful" world would be if the offsets were > >> reported in character codepoints, because buffer positions are both > >> the easiest for us to count and are unequivocally defined. > > > > I quite agree. > > Yes, everybody agrees! > > > Is this "count in codepoints" capability defined in LSP at all? > > That's _exactly_ what the patch implements 🥳. It does? then please humor me by walking me through the code and the patch to show how that would work after applying the patch. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 02:18:42 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 07:18:42 +0000 Received: from localhost ([127.0.0.1]:35890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVSLq-000388-0Z for submit@debbugs.gnu.org; Fri, 24 Feb 2023 02:18:42 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:38690) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVSLo-00037s-Mj for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 02:18:41 -0500 Received: by mail-ed1-f53.google.com with SMTP id cy6so45772931edb.5 for <61726@debbugs.gnu.org>; Thu, 23 Feb 2023 23:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Nuzgyez+FrmEleNVt4/YkrqUPiewrRzQjdqC+95zMzI=; b=QQOUCgMLzFbolZ9rKQx1EvpcdT2mkTv9Xf1ToMJry3bcRC8qaI6ihWLX4o/g+tLO7z SXMM+66LTRToMWj7XtIq5CSXw+9uHZyXoyiZ0BGtZmpObb1lA/M3G/B1Ql7YloK3NVnA 5A0CteYdq9QN9mZW/eUikG2iYMQdBbrZ6MU5NPNwV41Qg2y5U6zuu2zTx74j/2QrMPh3 j8IIAV8Tm/fY21HSLSgPkgoRoC1Sphb/94rQm83PPacGGf4qrnM41C/E1tmeznTwfyyF nb1Kl7D4pH6t9RHSuee2/gdU8QADlpvMH6Q9KH7FxeY0MVIOo84Z8CgNld92fjnngf54 Ioeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Nuzgyez+FrmEleNVt4/YkrqUPiewrRzQjdqC+95zMzI=; b=oFaMj0HtqFNrZUefUUUJRsnPQN+DbosKXL/ZG+eham6Tk0dZeJ49Fex0uFFX4v/Fe9 /tuEvgLJTTDwMRYzjgCss90S1xu6ijif/xxWHNSJBjxlcCpuR6KYUFZQZ0JeAB0yRks8 wzYgYxUgwjYtlGs9HUkXOdikB+cS1CfZr9l5aI63kSFzTORQAr3xlmu1K1Ft7T+B/xhU h3sfoFWa8NgrOw4eUnT/UeNK7dNrg/Zx5MOwraUO8oOHlG2dh8g9WHwk1m8LFBZDwv2a uYOJBmwuBerhNBn3p9C9B/UM/QIOeRmeBEi/dA+5e22VRnqL4/CvhgtxbvYyqo6zf1j1 QxPA== X-Gm-Message-State: AO0yUKVe+uk1LiOogTBbCad5+QsJDzkSQ6YPDxZor6g1kIvnJtna7F8Y qaQ+b3f9hnk4aod8kHYGMWKEzF8sHbQ= X-Google-Smtp-Source: AK7set9wItqw7APB2hgLh4Ic0mbV9may1t62mMcg+aaJAn2jFMze2ha5+zueW7GvdfVm/lhUBrwMBg== X-Received: by 2002:aa7:db4f:0:b0:4ac:bf55:7d61 with SMTP id n15-20020aa7db4f000000b004acbf557d61mr15455791edt.9.1677223114426; Thu, 23 Feb 2023 23:18:34 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id p16-20020a170906141000b008ec793ac3f4sm1840464ejc.192.2023.02.23.23.18.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 23:18:33 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <835ybrpnqj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 08:43:32 +0200") 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> Date: Fri, 24 Feb 2023 08:18:30 +0100 Message-ID: <87y1oncz09.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 08:43, Eli Zaretskii wrote: > It does? then please humor me by walking me through the code and the > patch to show how that would work after applying the patch. >From a86601f4e80dfbf21a84230433c431375e3012aa Mon Sep 17 00:00:00 2001 From: Augusto Stoffel Date: Thu, 23 Feb 2023 08:55:58 +0100 Subject: [PATCH] * lisp/progmodes/eglot.el: Support positionEncoding capability --- lisp/progmodes/eglot.el | 65 +++++++++++++++++++++++++++++------------ 1 file changed, 46 insertions(+), 19 deletions(-) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index b569c03e8c2..0268fbf63a5 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -816,6 +816,9 @@ eglot-client-capabilities `(:valueSet [,@(mapcar #'car eglot--tag-faces)]))) + :general + (list + :positionEncodings ["utf-32" "utf-8" "utf-16"]) :experimental eglot--{}))) We announce our position encoding capabilities, in this order of preference: A. counting characters a.k.a. Unicode codepoints B. counting bytes of the UTF-8 representation C. counting bytes of the UTF-16 representation divided by two (which is currently the default). (cl-defgeneric eglot-workspace-folders (server) @@ -1439,20 +1442,26 @@ eglot--warn (let ((warning-minimum-level :error)) (display-warning 'eglot (apply #'format format args) :warning))) =20 -(defun eglot-current-column () (- (point) (line-beginning-position))) +(defun eglot-current-column () + "Calculate current column, counting Unicode codepoints." + (- (point) (line-beginning-position))) I added a docstring. +(defun eglot--current-column-utf-8 () + "Calculate current column, counting bytes." + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) I defined a new function to support the style B. of counting offsets. -(defvar eglot-current-column-function #'eglot-lsp-abiding-column +(defvar eglot-current-column-function nil "Function to calculate the current column. I changed the default so this variable can be eventually made obsolete. Note that it is a workaround variable introduced for the sole purpose of making nonconforming servers work with Eglot. But this problem should slowly vanish with the introduction of the :positionEncoding capability. Hence my suggestion to obsolete this workaround variable. This is the inverse operation of `eglot-move-to-column-function' (which see). It is a function of no arguments returning a column number. For buffers managed by -fully LSP-compliant servers, this should be set to -`eglot-lsp-abiding-column' (the default), and -`eglot-current-column' for all others.") +fully LSP-compliant servers, this should be nil. For others, it +can be set to `eglot-current-colum' or +`eglot--current-column-utf-8'.") =20 (defun eglot-lsp-abiding-column (&optional lbp) - "Calculate current COLUMN as defined by the LSP spec. + "Calculate current column, counting UTF-16 code units as in the original= LSP spec. LBP defaults to `line-beginning-position'." (/ (- (length (encode-coding-region (or lbp (line-beginning-position)) ;; Fix github#860 The LSP spec now describes 3 ways of counting offsets, hence the documenation clarification. @@ -1462,13 +1471,19 @@ eglot-lsp-abiding-column =20 (defun eglot--pos-to-lsp-position (&optional pos) "Convert point POS to LSP position." - (eglot--widening - ;; LSP line is zero-origin; emacs is one-origin. - (list :line (1- (line-number-at-pos pos t)) - :character (progn (when pos (goto-char pos)) - (funcall eglot-current-column-function))))) - + (let ((columnfn (or eglot-current-column-function + (pcase (plist-get (eglot--capabilities (eglot-curren= t-server)) + :positionEncoding) + ("utf-32" #'eglot-current-column) + ("utf-8" #'eglot--current-column-utf-8) + (_ #'eglot-lsp-abiding-column))))) + (eglot--widening + ;; LSP line is zero-origin; emacs is one-origin. + (list :line (1- (line-number-at-pos pos t)) + :character (progn (when pos (goto-char pos)) + (funcall columnfn)))))) + This is the heart of the patch. A =E2=80=9Cgood=E2=80=9D server will provide :positionEncoding "utf-32", an= d we'll keep the workaround variable `eglot-current-column-function' at its new default value of nil. So columnfn, which is called in the last line of the chunck, will be bound to `eglot-current-column'. A =E2=80=9Cbad=E2=80=9D server will provide provide :positionEncoding "utf-= 16" or nil, and then we will call `eglot-lsp-abiding-column' near the end. An =E2=80=9Cinbetween=E2=80=9D server will provide :positionEncoding "utf-8= " and we will call the newly added `eglot--current-column-utf-8' near the end. If the user sets `eglot-current-column-function' to work around an issue, nothing changes in relation to the original version. -(defvar eglot-move-to-column-function #'eglot-move-to-lsp-abiding-column +(defvar eglot-move-to-column-function nil "Function to move to a column reported by the LSP server. =20 I changed the default so this variable can be eventually made obsolete. Note that it is a workaround variable introduced for the sole purpose of making nonconforming servers work with Eglot. But this problem should slowly vanish with the introduction of the :positionEncoding capability. Hence my suggestion to obsolete this workaround variable. @@ -1478,11 +1493,11 @@ eglot-move-to-column-function `c'. However, many servers don't follow the spec this closely. =20 For buffers managed by fully LSP-compliant servers, this should -be set to `eglot-move-to-lsp-abiding-column' (the default), and -`eglot-move-to-column' for all others.") +be letft nil. For others, it can be set to +`eglot-move-to-column' or `eglot--move-to-column-utf-8'.") =20 (defun eglot-move-to-column (column) - "Move to COLUMN without closely following the LSP spec." + "Move to COLUMN, counting Unicode codepoints." ;; We cannot use `move-to-column' here, because it moves to *visual* ;; columns, which can be different from LSP columns in case of ;; `whitespace-mode', `prettify-symbols-mode', etc. (github#296, The LSP spec now describes 3 ways of counting offsets, hence the documenation clarification. @@ -1490,8 +1505,14 @@ eglot-move-to-column (goto-char (min (+ (line-beginning-position) column) (line-end-position)))) =20 +(defun eglot--move-to-column-utf-8 (column) + "Move to COLUMN, regarded as a byte offset." + (goto-char (min (byte-to-position + (+ (position-bytes (line-beginning-position)) column)) + (line-end-position)))) + I defined a new function to support the style B. of counting offsets. (defun eglot-move-to-lsp-abiding-column (column) - "Move to COLUMN abiding by the LSP spec." + "Move to COLUMN, counting UTF-16 code units as in the original LSP spec." (save-restriction (cl-loop with lbp =3D (line-beginning-position) @@ -1515,14 +1536,20 @@ eglot--lsp-position-to-point (forward-line (min most-positive-fixnum (plist-get pos-plist :line))) (unless (eobp) ;; if line was excessive leave point at eob - (let ((tab-width 1) + (let ((movefn (or eglot-move-to-column-function + (pcase (plist-get (eglot--capabilities (eglot-cu= rrent-server)) + :positionEncoding) + ("utf-32" #'eglot-move-to-column) + ("utf-8" #'eglot--move-to-column-utf-8) + (_ #'eglot-move-to-lsp-abiding-column)))) + (tab-width 1) (col (plist-get pos-plist :character))) (unless (wholenump col) (eglot--warn "Caution: LSP server sent invalid character position %s. Usin= g 0 instead." col) (setq col 0)) - (funcall eglot-move-to-column-function col))) + (funcall movefn col))) (if marker (copy-marker (point-marker)) (point))))) This is the second heart of the patch. A =E2=80=9Cgood=E2=80=9D server will provide :positionEncoding "utf-32", an= d we'll keep the workaround variable `eglot-move-to-column-function' at its new default value of nil. So columnfn, which is called in the last line of the chunck, will be bound to `eglot-move-to-column'. A =E2=80=9Cbad=E2=80=9D server will provide provide :positionEncoding "utf-= 16" or nil, and then we will call `eglot-lsp-abiding-column' near the end. An =E2=80=9Cinbetween=E2=80=9D server will provide :positionEncoding "utf-8= " and we will call the newly added `eglot--move-to-column-utf-8' near the end. If the user sets `eglot-move-to-column-function' to work around an issue, nothing changes in relation to the original version. I hope this helps clarifying things. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 03:38:45 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 08:38:45 +0000 Received: from localhost ([127.0.0.1]:35941 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVTbJ-00055s-8E for submit@debbugs.gnu.org; Fri, 24 Feb 2023 03:38:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVTbH-00055c-NR for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 03:38:44 -0500 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 1pVTbC-00040i-47; Fri, 24 Feb 2023 03:38:38 -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=tO2kpSeVqUfws7CBzFUEzyqu7B/5yZnJOH/azNeFZlk=; b=NMOLV9DchW5X0sjUm7Fr RPZMBj2xrlODurMBnos6ogBTtNG6PxzfRIvRdb1QqJBZs0u1llkztIBUgT6PB2jnhdjKSXYcDoHAp 5bQJJJDwgnv1EMD6vxu6g7+Xdz9/7+pY7iJNd5EzVqS3p6+TjdnxLn12ZlsvHSOUQREpNwWLhMp6g 5nRLI44tGXhvCJqDFUIdNutv2RoLtZRlOeMUZ7Me5BkzS5TMVh6w5DOH1+EwAXDafaVh4eriIhXbH vg60zvhqcqjNz9ZjVfNV4otNRQfQOrcdDNfb9ong+n0mVF+x1ubG3vlfcRoMCSbQ+nuEapmfv2dLo OF7w9IE2O/YE/w==; 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 1pVTbA-0002pV-Jn; Fri, 24 Feb 2023 03:38:37 -0500 Date: Fri, 24 Feb 2023 10:38:35 +0200 Message-Id: <83r0ufo3uc.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87y1oncz09.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 08:18:30 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 08:18:30 +0100 > > On Fri, 24 Feb 2023 at 08:43, Eli Zaretskii wrote: > > > It does? then please humor me by walking me through the code and the > > patch to show how that would work after applying the patch. > > + :general > + (list > + :positionEncodings ["utf-32" "utf-8" "utf-16"]) > :experimental eglot--{}))) Is "UTF-32" an LSP thing and terminology? Because I'd prefer a different name if we can. At least for our internal nomenclature, let's use "codepoint" or "character" instead. > -(defun eglot-current-column () (- (point) (line-beginning-position))) > +(defun eglot-current-column () > + "Calculate current column, counting Unicode codepoints." > + (- (point) (line-beginning-position))) Can we please take this opportunity to get rid of the confusing "column" terminology? As became evident from this discussion, we are not talking columns here, we are talking offsets in characters from BOL. So something like "pos" or "linepos" or "line-offset" should be better. João, are you okay with such a sweeping change in all of eglot.el? > +(defun eglot--current-column-utf-8 () > + "Calculate current column, counting bytes." > + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) 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)) Also, for 100% reliable results, we should bind inhibit-field-text-motion to t when calling line-beginning-position. > +(defun eglot--move-to-column-utf-8 (column) > + "Move to COLUMN, regarded as a byte offset." > + (goto-char (min (byte-to-position > + (+ (position-bytes (line-beginning-position)) column)) > + (line-end-position)))) Likewise here. > @@ -1515,14 +1536,20 @@ eglot--lsp-position-to-point > (forward-line (min most-positive-fixnum > (plist-get pos-plist :line))) > (unless (eobp) ;; if line was excessive leave point at eob > - (let ((tab-width 1) > + (let ((movefn (or eglot-move-to-column-function > + (pcase (plist-get (eglot--capabilities (eglot-current-server)) > + :positionEncoding) > + ("utf-32" #'eglot-move-to-column) > + ("utf-8" #'eglot--move-to-column-utf-8) > + (_ #'eglot-move-to-lsp-abiding-column)))) > + (tab-width 1) ^^^^^^^^^^^ This last part shouldn't be necessary: we should move by characters, not by columns. Why is it necessary? > I hope this helps clarifying things. Yes, thank you very much. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 04:15:59 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 09:15:59 +0000 Received: from localhost ([127.0.0.1]:35946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVUBK-00069S-MV for submit@debbugs.gnu.org; Fri, 24 Feb 2023 04:15:59 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:40650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVUBJ-00069D-2x for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 04:15:57 -0500 Received: by mail-ed1-f51.google.com with SMTP id i34so26921518eda.7 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 01:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=gUZbmAcVhTMHoevLEqy7hDrzFaQVYFi39F+GXl89ttk=; b=K1U0UR1IKNCPJpyhFJsEcR4KbUW5ACQcR53rKYgTBDFLgvL+B/J/LpPyMJoGVqeA2i g6AEAzuzjAX1HsQsYVuQp7VufYVoahohRwqBuGtfcKjYWWF4J8Ut7sBgDuCuRvgYq6dv wF1p37uMTOpucRIPtbMnwEsympsh53fWVnpQq9RBVbR61GRkU2jsQL7ZZvXjtHbn5sne 1KvlrJC0eDQm89DfQVF5NqTNTWRJ9dxdXhY5uPExXQmffD6HUimM6/ZD9KfDbia84uh8 igJdkY9ohN8LnY+16zDM/OvC603xbl/q+sirvkyIUX4FPEde9o4MJtALaiUJuYB7+H6j kR6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=gUZbmAcVhTMHoevLEqy7hDrzFaQVYFi39F+GXl89ttk=; b=A1FeJQ0l7aed7VHqt7dN3HyXe/u2jabRSDSUFHD3UBRE2meCEYA2AXCzd4dhzjOKR3 yMLtAbl7rHZkps/ByccHHQMj5dsxlXYwIQoH5Wa63dBXE11QK8XGtiort1sU8F5wn79e 9U2t3MrAXC8E1eV4Kwffy1AVUHa+Ie+VDmiqiH/KEiYg5UejG98h1Ic9P06kMJjcfSM5 CdYPYbnCP3mJvUaSbPTcBodZzRWnfhTRj/lWLWDXjBhBgVtGdfckUYFBZgzCCdOuUwXJ MsBgnVnZGB3ve7+XPRAPvLds6arI7XMAqByjUMvqSFxoc+5bbFscUPsbuKLgeG8SCUh+ Y2NQ== X-Gm-Message-State: AO0yUKW+8Iqzh9pjYYdIy219Lnu4StR36gWCAuJs63vZwQySrJsJ9x9f BGVeRYtNOs3XDjVp3DrLEbANFneP7N8= X-Google-Smtp-Source: AK7set+tcbCcw3XqGiy25vi0GT40G/cWS8LcchJCTxFa2LKQP673mNgYbe9NCgTxx/+8h+/vHwdn4w== X-Received: by 2002:a17:907:b16:b0:878:78f9:d1be with SMTP id h22-20020a1709070b1600b0087878f9d1bemr19069408ejl.23.1677230150779; Fri, 24 Feb 2023 01:15:50 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id f13-20020a170906738d00b008e6bd130b14sm3041655ejl.64.2023.02.24.01.15.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 01:15:50 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83r0ufo3uc.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 10:38:35 +0200") 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> Date: Fri, 24 Feb 2023 10:15:48 +0100 Message-ID: <87356vbf0b.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 10:38, Eli Zaretskii wrote: >> From: Augusto Stoffel >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org >> Date: Fri, 24 Feb 2023 08:18:30 +0100 >>=20 >> On Fri, 24 Feb 2023 at 08:43, Eli Zaretskii wrote: >>=20 >> > It does? then please humor me by walking me through the code and the >> > patch to show how that would work after applying the patch. >>=20 >> + :general >> + (list >> + :positionEncodings ["utf-32" "utf-8" "utf-16"]) >> :experimental eglot--{}))) > > Is "UTF-32" an LSP thing and terminology? Because I'd prefer a > different name if we can. At least for our internal nomenclature, > let's use "codepoint" or "character" instead. Yes, this is how the LSP spec refers to the 3 offset counting methods. >> -(defun eglot-current-column () (- (point) (line-beginning-position))) >> +(defun eglot-current-column () >> + "Calculate current column, counting Unicode codepoints." >> + (- (point) (line-beginning-position))) > > Can we please take this opportunity to get rid of the confusing > "column" terminology? As became evident from this discussion, we are > not talking columns here, we are talking offsets in characters from > BOL. So something like "pos" or "linepos" or "line-offset" should be > better. > > Jo=C3=A3o, are you okay with such a sweeping change in all of eglot.el? I like linepos, if Jo=C3=A3o is fine with not making the absolute minimal amount of changes to the code. >> +(defun eglot--current-column-utf-8 () >> + "Calculate current column, counting bytes." >> + (- (position-bytes (point)) (position-bytes (line-beginning-position)= ))) > > 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: (progn (insert ?x (max-char) ?y) (json-serialize (buffer-substring-no-properties (pos-bol) (pos-eol)))) =E2=87=92 Debugger entered--Lisp error: (wrong-type-argument utf-8-stri= ng-p " (json-serialize (buffer-substring-no-properties (...") > Also, for 100% reliable results, we should bind > inhibit-field-text-motion to t when calling line-beginning-position. We should rather be using pos-bol, no? But how do we keep compatibility with older Emacsen? >> +(defun eglot--move-to-column-utf-8 (column) >> + "Move to COLUMN, regarded as a byte offset." >> + (goto-char (min (byte-to-position >> + (+ (position-bytes (line-beginning-position)) column= )) >> + (line-end-position)))) > > Likewise here. > >> @@ -1515,14 +1536,20 @@ eglot--lsp-position-to-point >> (forward-line (min most-positive-fixnum >> (plist-get pos-plist :line))) >> (unless (eobp) ;; if line was excessive leave point at eob >> - (let ((tab-width 1) >> + (let ((movefn (or eglot-move-to-column-function >> + (pcase (plist-get (eglot--capabilities (eglot= -current-server)) >> + :positionEncoding) >> + ("utf-32" #'eglot-move-to-column) >> + ("utf-8" #'eglot--move-to-column-utf-8) >> + (_ #'eglot-move-to-lsp-abiding-column)))) >> + (tab-width 1) > ^^^^^^^^^^^ > This last part shouldn't be necessary: we should move by characters, > not by columns. Why is it necessary? Maybe Jo=C3=A3o can clarify, but I'm pretty sure this is there to support t= he UTF-16 way of counting offsets, so this ideally should move to eglot-move-to-lsp-abiding-column. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 05:21:00 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 10:21:01 +0000 Received: from localhost ([127.0.0.1]:35992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVVCG-0007uC-JF for submit@debbugs.gnu.org; Fri, 24 Feb 2023 05:21:00 -0500 Received: from mail-oi1-f172.google.com ([209.85.167.172]:35479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVVCF-0007tz-DS for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 05:20:59 -0500 Received: by mail-oi1-f172.google.com with SMTP id c11so16103500oiw.2 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 02:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677234053; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=gWI9i7DWJQsPyDSCHBM28vnDzfcKEIRdqE/GOGVDW1Y=; b=YwSSozMo2mrcOr23zsSw46pDvZ799fBluWbPhQ0B9C49ocr8EJoSLRojLqNwvqACyh DZt/pxajydRt+qjY4uyHY3kU68EGyx27Uf7ES76mV1Qf8HHf02+O2I8yQYsHroMDMkpH fs2LE3g4k7ALmfVBStHIcOrZ+IORXNW/mWsbiYLmWk7c496wke9lCIYz7kFQA2JYic7r WwPd3OUrD9OvEtT3+ofNYeaDaffp3CVbe7BfgtD6gLjUx/ViEW+VDKnlKfAs9VyhD2Db 79iGQ2UOgs9nbVbfCEtsj2W/xqC2fP7FcVjucejczSrpyCVvyHLh77FOKcp2Vv4jPkcH wJhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677234053; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gWI9i7DWJQsPyDSCHBM28vnDzfcKEIRdqE/GOGVDW1Y=; b=dPyh+E2TFKGjps/MDjt0WnAdu+qPSHPGWS5ewz7itsOkApxqjXCTzuteIEjidPoLFL t7UlZLTsTRbVkHJMRinhnSx5ik4n1nZGBJKrfAU/EQEINrha6eyCs4bgiEdCTEQucyL+ yLRk2j/+IaeU8U8xyeIiMRL4cvQ29ePxxvH5gl+XYhhy2Gch8wqOpPTIIVMRHDVOHqf6 0x6Fpl3wRoTM+3//58MwITEbjvhZehcLGxYe2Udt19wmiS/G1qzZmUBuvPQhh+tLprox UnHQnnJXpkcaIJU2WAK7OaBDIWBJ6aCleK61cpeSZVFk/XpT4orWXWHDAkzCkBYlR9gi 6ESw== X-Gm-Message-State: AO0yUKUyjisvvYcufAaYkzOpuhZ0xvQ38ZnD+ov35142r6Sqz7dmQEPt Xg1V5DDuZvorhj3mWZpWnOo4arD0GZc7BlelQtU= X-Google-Smtp-Source: AK7set9Ugdfrii8LXXZDZ8o3A5lu4Fezp8MW6lU1NILLsa+Crp20Ngx15O0gSszlsRzGfp+t5mPamJnhF8TQ/QWdx6w= X-Received: by 2002:a54:409a:0:b0:384:253:642d with SMTP id i26-20020a54409a000000b003840253642dmr136637oii.3.1677234053704; Fri, 24 Feb 2023 02:20:53 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <87356vbf0b.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 10:20:36 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 9:15 AM Augusto Stoffel wrote= : > > ^^^^^^^^^^^ > > This last part shouldn't be necessary: we should move by characters, > > not by columns. Why is it necessary? > > Maybe Jo=C3=A3o can clarify, but I'm pretty sure this is there to support= the > UTF-16 way of counting offsets, so this ideally should move to > eglot-move-to-lsp-abiding-column. I have to be brutally honest here: I don't like this patch. I appreciate the effort, I really do, and thank for guiding us its the motions, but there are two main things I really don't like about it, and 1 that I'm on the fence about. The first thing I don't like is likely the reason that Eli is confused here. The late binding of column-counting strategies is confusing. I wrote these functions so that each one has a separate well-defined, readable-inasmuch-as-possible, vc-region-history-traceable, performant column-counting strategy. The "lsp-abiding" naming might be off, I admit, but only since LSP started supporting more than one strategy. The second thing I don't like is also due to the late-binding idea. This is a hotspot in Eglot, some of these functions are called many many times, for each LSP server interaction depending on how many document positions are exchanged (and they can be a lot). I do remember benchmarking strategies at the time and seeing a perceptible difference. Plus, this late-binding is really useless as a server will guaranteedly _not_ change its column-counting standard during the LSP session. The third thing that I'm not crazy with but I don't mind is the necessity to support the "utf-8" strategy. If "utf-16" is mandatory, and we already support "utf-32" anyway, why should we be adding this additional complexity. But, if it can be hidden behind a new pair of functions and Eli accepts it, I'm OK with it. Finally, here's a patch that doesn't use late-binding, doesn't introduce new strategies and supports "utf-32" and "utf-16" today. As you can see, the patch is nearly trivial. diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index eea8be6d1aa..ae8afa69651 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -807,6 +807,7 @@ eglot-client-capabilities :rangeFormatting `(:dynamicRegistration :json-false) :rename `(:dynamicRegistration :json-false) :inlayHint `(:dynamicRegistration :json-false) + :general `(:positionEncodings ["utf-32" "utf-16"]) :publishDiagnostics (list :relatedInformation :json-false ;; TODO: We can support :codeDescription after ;; adding an appropriate UI to @@ -1789,6 +1790,9 @@ eglot--managed-mode (add-hook 'eldoc-documentation-functions #'eglot-signature-eldoc-fun= ction nil t) (eldoc-mode 1)) + (when (eq (eglot--server-capable :positionEncoding) "utf-16") + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-co= lumn) + (eglot--setq-saving eglot-current-column-function #'eglot-current-column)) (cl-pushnew (current-buffer) (eglot--managed-buffers (eglot-current-server)))) (t (remove-hook 'after-change-functions 'eglot--after-change t) As I said, enhancing this patch with a new pair of "current/move-to" functions that add in utf-8 support is acceptable. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:01:59 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:01:59 +0000 Received: from localhost ([127.0.0.1]:36043 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVVpv-0002wq-Ee for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:01:59 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:33692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVVpt-0002we-QO for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:01:58 -0500 Received: by mail-ed1-f50.google.com with SMTP id ck15so54567901edb.0 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=a7qMbeBYtEFHwKcMb3ZPPiOqMJn3/oJXyqqH4PRcdsk=; b=QJzqwvJsWwEUrscpZ1Xlw3l1O6wJlLS7sgEpEbL4OLBaX6itS/PVtY8XGZ4rn2rabq HnUDhsm7jxoc5Dw9a/lWikWSwd0qzgctxl6xLQfFnFdZoEZLqnXuinB9+Gb80KpeGVxj VCE91ntp6W7GLaGhBrwGmxGgdqRZVjgG6THqe6C4UL10jg1chZx4A3h31m+6akNdwmwe facVr2atN79BuP6AnMJO7RjWtcNrR9OumTcO8JVUK39hHoDltb0pZmQVvOY3aAyyB9dT 9F7cuNnY6jgUr2trMrWN3xfDIGFwr6EIj1MPJudQI0pGUczQxXdoj9VHo/WThjPO0UxU E5Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=a7qMbeBYtEFHwKcMb3ZPPiOqMJn3/oJXyqqH4PRcdsk=; b=OySle+/dqRmORu0kDwzktomKpYEWGlbQhDDW/w7mztVT3lxQemqt0qJHdsdQSJiCCW UrPTqFXOpS8R4NZABt/pG1txLnHyH4xPOWuAFx/l7FXJh/GdicixX9tm52/Bz+CUkrMO Ty4cjFvb8FVr69GJ6yfR/PnBocacUnFaknWrWVbNYk+TqimaNLafv4fAjdkb/meDFb/6 SHeOVF9NZQRDp+BJp19n0JqYYyxxaEUoJ2CtY34v7bmYfx2AvmtifhPJSRYwt0tJNIUT vk7slqIp6c0M2KxKMiGEV0ecpVkurZc3XjDPuqYdIvvy45kPIGBsPJ4wmn4Esltwsqlr huwA== X-Gm-Message-State: AO0yUKWIwFuuL8IiG1UMNAxvggLPPvdX/BsBp/UzRI8CpCcFF/TsBVUU eE44bOepPdqZqDOlXwyq88LzkzZwBWI= X-Google-Smtp-Source: AK7set/ylQ/PQji8eu82rVL+cnVJH8tHIAuONxM6HBAnKUG3LJo3V98up/3kCexzEsLQ98EPMNGphQ== X-Received: by 2002:a50:ed16:0:b0:4ae:eb0f:4273 with SMTP id j22-20020a50ed16000000b004aeeb0f4273mr15463793eds.15.1677236511214; Fri, 24 Feb 2023 03:01:51 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id z5-20020a509e05000000b004ad03b18ae3sm5531159ede.62.2023.02.24.03.01.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 03:01:50 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 24 Feb 2023 10:20:36 +0000") 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> Date: Fri, 24 Feb 2023 12:01:48 +0100 Message-ID: <87wn479vj7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 10:20, Jo=C3=A3o T=C3=A1vora wrote: > The second thing I don't like is also due to the late-binding idea. > This is a hotspot in Eglot, some of these functions are called > many many times, for each LSP server interaction depending > on how many document positions are exchanged (and they can > be a lot). I do remember benchmarking strategies at the time > and seeing a perceptible difference. Plus, this late-binding is > really useless as a server will guaranteedly _not_ change its > column-counting standard during the LSP session. `eglot-lsp-abiding-column' allocates a new string! I doubt that looking up a few plists makes much of a difference compared to that. But when using the better offset counting styles, I think it might indeed make a difference. OTOH it might as well be premature optimization. > Finally, here's a patch that doesn't use late-binding, doesn't > introduce new strategies and supports "utf-32" and "utf-16" > today. As you can see, the patch is nearly trivial. I'm fine with that way of doing things, but please respond to my concern from the other message: do you really want to store a server capability in a buffer-local variable? What about your plans to support multiple servers? I suggest you to guard against future headaches. We can store the offset functions in two slots of the server class if you don't like to traverse the capabilities plist each time. > diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el > index eea8be6d1aa..ae8afa69651 100644 > --- a/lisp/progmodes/eglot.el > +++ b/lisp/progmodes/eglot.el > @@ -807,6 +807,7 @@ eglot-client-capabilities > :rangeFormatting `(:dynamicRegistration :json-false) > :rename `(:dynamicRegistration :json-false) > :inlayHint `(:dynamicRegistration :json-false) > + :general `(:positionEncodings ["utf-32" "utf-16"= ]) > :publishDiagnostics (list :relatedInformation :json-false > ;; TODO: We can support > :codeDescription after > ;; adding an appropriate UI to > @@ -1789,6 +1790,9 @@ eglot--managed-mode > (add-hook 'eldoc-documentation-functions #'eglot-signature-eldoc-f= unction > nil t) > (eldoc-mode 1)) > + (when (eq (eglot--server-capable :positionEncoding) "utf-16") > + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-= column) > + (eglot--setq-saving eglot-current-column-function > #'eglot-current-column)) > (cl-pushnew (current-buffer) (eglot--managed-buffers > (eglot-current-server)))) > (t > (remove-hook 'after-change-functions 'eglot--after-change t) > > As I said, enhancing this patch with a new pair of "current/move-to" > functions that add in utf-8 support is acceptable. > > Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:16:35 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:16:35 +0000 Received: from localhost ([127.0.0.1]:36067 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVW43-0005gf-FP for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:16:35 -0500 Received: from mail-oa1-f47.google.com ([209.85.160.47]:38884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVW42-0005gT-BP for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:16:34 -0500 Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-1720433ba75so19332726fac.5 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677237388; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rT/Wlc4WtcVENfqZPVcOlpTAHJVUmy5mq6iUJ5+fcD8=; b=cH4BhOOU2jtq+Iw6Sjze25w4ZFdte2KyeXhO6ZR2XO4eToZrVFR8+nAgGqSbgCZD8A O1x0SR4p4t5nJJolZXNnThjkzxdUmI3cx6dhMYAdQspO5w1hkJ0Yq/5dZhB1+fs3YS0l 9cUK6xHS8KaYbQuEojryodc27Flir9IZnVYTo26v3JionGoW5nn22DfTwicyFuJI3ZwM AaVZxQ4peu2TotV69i/ahQJr/R3lUjH6civ258OrVOeRSZgLheln30gYuEa8M3GfSVT3 6yqMzoaVZT3tVjYjxmYVE7s98vj8bLm558iZ8wRXC63L6SoYkUmV1UDccnFF7goJuL6A 7ZBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677237388; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rT/Wlc4WtcVENfqZPVcOlpTAHJVUmy5mq6iUJ5+fcD8=; b=RZGEKtlsOE95a9+p+Ui7jTJjiIijjmJbTlqPXhwB1CdQ76tpiYT7ZZMo9VYOVXYCw5 jgPlRCS+o1GObnu6SjaMpGBLqISPoDUY3qa+5r1mYppureY20p9DCtJL2tiBRJ34PFzS b2tgZKgyyhUuM9mWAL7W8GlZcHaD+ahBs0cGUhgvKWe1DnpBj+FFKgfwNLLASxPYOmAh fKhhmaBFQeYatP/UGuU6VvmhL/ufDjs7u3zaymTpqsTbe3M+8vrXhLuM1zux/sm537qL XenAOJ99V2ccHNbiHXzvtJZFZ4QHU8zLrFyKlBSgUqwGdqb7fGldMfWNcGW37ZSMuZOg HBBg== X-Gm-Message-State: AO0yUKWlLIW2H0zE5Npzdj5LrfRk/CWXX1JwvUn//GQ5M4U9nXvaj7Mi DaXPUL900eEwNTn9w/qelj6eoh1J49i6xgfEqS4= X-Google-Smtp-Source: AK7set9U2ZBUFH/S31IhCYoHpquQjxURZuVi2kXr+bZ+pgh/GZzQ7tJnxjqtE1HnQqXcXzf64LKCLVX3qI8XwzrOGG0= X-Received: by 2002:a05:6871:6b97:b0:16e:2f74:e5c1 with SMTP id zh23-20020a0568716b9700b0016e2f74e5c1mr754057oab.8.1677237388597; Fri, 24 Feb 2023 03:16:28 -0800 (PST) MIME-Version: 1.0 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> <87wn479vj7.fsf@gmail.com> In-Reply-To: <87wn479vj7.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 11:18:11 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 11:01 AM Augusto Stoffel wrot= e: > > On Fri, 24 Feb 2023 at 10:20, Jo=C3=A3o T=C3=A1vora wrote: > > > The second thing I don't like is also due to the late-binding idea. > > This is a hotspot in Eglot, some of these functions are called > > many many times, for each LSP server interaction depending > > on how many document positions are exchanged (and they can > > be a lot). I do remember benchmarking strategies at the time > > and seeing a perceptible difference. Plus, this late-binding is > > really useless as a server will guaranteedly _not_ change its > > column-counting standard during the LSP session. > > `eglot-lsp-abiding-column' allocates a new string! I doubt that looking > up a few plists makes much of a difference compared to that. But when > using the better offset counting styles, I think it might indeed make a > difference. OTOH it might as well be premature optimization. And this is why we measure. You can find some scripts for doing that and some discussion in: https://github.com/joaotavora/eglot/pull/125 The 2018 issue where this all started. > > Finally, here's a patch that doesn't use late-binding, doesn't > > introduce new strategies and supports "utf-32" and "utf-16" > > today. As you can see, the patch is nearly trivial. > > I'm fine with that way of doing things, but please respond to my concern > from the other message: do you really want to store a server capability > in a buffer-local variable? What about your plans to support multiple > servers? The capability is stored in the server object and reflects in the buffer-lo= cal variable which will be restored when the session ends. I don't see any problem with that. My idea of supporting multiple servers is to create a proxy program that invokes multiple processes and negotiates a common set of capabilities, so I don't see it as a problem either. If server A suppor= ts utf-32 and utf-16 and server B only supports utf-16, the multiplexing server C only declares support for utf-16. > I suggest you to guard against future headaches. We can store the > offset functions in two slots of the server class if you don't like to > traverse the capabilities plist each time. No, this is exactly the type of complexity that I strive to avoid in Eglot, especially when the added value is small. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:27:53 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:27:53 +0000 Received: from localhost ([127.0.0.1]:36082 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWEz-00067H-Eu for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:27:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWEx-000673-Gd for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:27:51 -0500 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 1pVWEq-00058E-MZ; Fri, 24 Feb 2023 06:27:45 -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=fGNpM0a5fCPx+7fSNOTb3jqYrmBu53diqX+ovngbEtA=; b=Bh6rk3j/5By4XfgEVriv hAeqXmL5z4cX6U/ZGOgt8sZjLdA57kh/8r18fBYA+4Bv2TZ8Dgrm7KG+kDITkdGsH8rxjeY5+oqtM +vM7ai8ox7cn/ytsVXvgo88L8b07h6nxYzSQeGIXBzAAv+U1iMep1hf6hWTJPIOknCg03Vz4zNKpS tad9rX63l9uI6ljU9XfI2esCAQrKsrnI8e/lOin7K4Eq6h+1TwUlm+KhCZqIvZPuQDKm4OCdAX+X3 SbI2slLrGhmTnWHNZOq83bXBZy6AjjUwdlE88EO7+dChwHodws+yuj96KH8Xvuu6r4Y8h7XNoFf7L n+pfT2+uovWeVg==; 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 1pVWEn-0004hp-Vx; Fri, 24 Feb 2023 06:27:44 -0500 Date: Fri, 24 Feb 2023 13:27:41 +0200 Message-Id: <83pm9znw0i.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87356vbf0b.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 10:15:48 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 10:15:48 +0100 > > >> -(defun eglot-current-column () (- (point) (line-beginning-position))) > >> +(defun eglot-current-column () > >> + "Calculate current column, counting Unicode codepoints." > >> + (- (point) (line-beginning-position))) > > > > Can we please take this opportunity to get rid of the confusing > > "column" terminology? As became evident from this discussion, we are > > not talking columns here, we are talking offsets in characters from > > BOL. So something like "pos" or "linepos" or "line-offset" should be > > better. > > > > João, are you okay with such a sweeping change in all of eglot.el? > > I like linepos, if João is fine with not making the absolute minimal > amount of changes to the code. João? > > 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. > > Also, for 100% reliable results, we should bind > > inhibit-field-text-motion to t when calling line-beginning-position. > > We should rather be using pos-bol, no? But how do we keep compatibility > with older Emacsen? Exactly. pos-bol is Emacs 29 and later, whereas Eglot is available from ELPA for older versions of Emacs. > >> + (tab-width 1) > > ^^^^^^^^^^^ > > This last part shouldn't be necessary: we should move by characters, > > not by columns. Why is it necessary? > > Maybe João can clarify, but I'm pretty sure this is there to support the > UTF-16 way of counting offsets, so this ideally should move to > eglot-move-to-lsp-abiding-column. Then perhaps the UTF-16 way of counting offsets should be changed as well. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:38:56 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:38:56 +0000 Received: from localhost ([127.0.0.1]:36127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWPf-0006T2-Qy for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:38:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWPe-0006Sq-8k for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:38:54 -0500 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 1pVWPY-0000Hr-QK; Fri, 24 Feb 2023 06:38:48 -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=BaNFvsO14auCRRWpqi2CeJPdKGLIOswzxXsq2IEQirQ=; b=Bam/YZL61yD8SWQACq3r TYLfS5ahCBTiUkoSVAN52GDTaRZhjpPuAqJpEGz83Y3r19ChSZtKVzoQCcCLE41tDz+PPJoHg4axm 4HPSrrgaAkBI+zlmnUC8mWcEaq8rhTHsv7I01iK/WsV7HwxwYZ1NH5zaGQZoTIPZ0Y5C8t9ZEfnWO C3rFMSCoGF7tBvw1eKH9VLRm/KfUo4sjKaldbgzV/ihGR54FMzh+zlRoBZp+iu7q7FFDkgDcNwGpx lp4qTgLJXhR2p8ioBo4Phev5T8qKcwzlzM8mHU+nZWxMnu7s+tTzsM6MSlbjpx2muItL0+4NngdFn UOQUrDy9z2ArTw==; 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 1pVWPY-00029H-7I; Fri, 24 Feb 2023 06:38:48 -0500 Date: Fri, 24 Feb 2023 13:38:48 +0200 Message-Id: <83mt53nvhz.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87wn479vj7.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 12:01:48 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> <87wn479vj7.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 12:01:48 +0100 > > On Fri, 24 Feb 2023 at 10:20, João Távora wrote: > > > The second thing I don't like is also due to the late-binding idea. > > This is a hotspot in Eglot, some of these functions are called > > many many times, for each LSP server interaction depending > > on how many document positions are exchanged (and they can > > be a lot). I do remember benchmarking strategies at the time > > and seeing a perceptible difference. Plus, this late-binding is > > really useless as a server will guaranteedly _not_ change its > > column-counting standard during the LSP session. > > `eglot-lsp-abiding-column' allocates a new string! If that is a concern, eglot.el could use a private temporary buffer into which the encoded text is inserted, eliminating the need to call 'length'. The impact of that in performance should be measured, of course, to make sure it doesn't make code slower; it will definitely improve the GC pressure aspect. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:43:37 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:43:38 +0000 Received: from localhost ([127.0.0.1]:36131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWUD-0006aO-Hq for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:43:37 -0500 Received: from mail-oi1-f178.google.com ([209.85.167.178]:42985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWUB-0006a9-Ed for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:43:36 -0500 Received: by mail-oi1-f178.google.com with SMTP id bh20so15292401oib.9 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:43:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677239009; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8RnYHR7JsKTyt3RjZzfGdI2X0t2utJljUOWrHnNCJuA=; b=og9+zlnGNlldBF1v9+fh1KRFERiQcIY4RH81eiB7xo4biaz95ebXKk55JNbdaQHsf0 7TomUlyD4LZMFqLj2O/2/o6xScrcZB2fn9SYFeWjdiE6TThmtHJ5OBaROPnhHd3DivTa hHRkxcCEKPyMbaG9M3fv7gq1j2iIfVKooJAgZEvRuD/6Aa+mowMIWOfJ1sVo2cBBygnP vSZSXW3ghBTWHRMsseBsT5lj2gIOwe03FFxzPeKoJ9rx5G7VXTsYUXG8anBcaTHLmHxd WE0ZzuxQ1wiS40ME4CN8xZySzkmMd/CrS88cZqNT3ulW/n1wHEefEPfYvR/7eglpo5Wo UFGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677239009; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=8RnYHR7JsKTyt3RjZzfGdI2X0t2utJljUOWrHnNCJuA=; b=M/jMrBK5ZZo+17AwQG+cMT80LQfznaM+4rLSHkwEOJMSIbUKiUZK7JdaFck0wEibEc r+tlcnW35TlQBR5XXjKZRjP2mVQnW6jjl8sMdH2VbXQkB4B0sbfHZ5esS8wZZnzfn2qr NTcmZK4i6SbyqFXGf9AuQ5jZwUXJDBshJtpBI7JBL8U3RO/06uKVVBOPkWMKuv9tFQud E0WDB5gZ6k37eLhizRS5ztUoOXNoGffaSbC8BrFZVgVh99FBa7ggt97qDI1oAk2GcYkU t7EJP2tPYI+FUlSZOENtJePCLyntLeiKLlKiotYCL23UIYofKYdqWDG5tLfJXYT9R/GW ppTQ== X-Gm-Message-State: AO0yUKXCM1XnDBgnvnw25aVbtnQp+80QuccpIwj8G6R5YJ6cURCskTRQ Z7bd8OtWEhwDN7LhfsgM097/ylgsBh7zROOXhDs= X-Google-Smtp-Source: AK7set9cesyy8hiyAyWa8CRw2BL8h4nHsmJQ2uaARtIO/9M2KQklxWf9ctJcF0/SbWF62vvD3i9BlTJK2lrsxvsDYRU= X-Received: by 2002:a05:6808:10d:b0:378:8018:ce36 with SMTP id b13-20020a056808010d00b003788018ce36mr1011759oie.8.1677239009625; Fri, 24 Feb 2023 03:43:29 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83pm9znw0i.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 11:43:18 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 11:27 AM Eli Zaretskii wrote: > > > From: Augusto Stoffel > > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > > Date: Fri, 24 Feb 2023 10:15:48 +0100 > > > > >> -(defun eglot-current-column () (- (point) (line-beginning-position)= )) > > >> +(defun eglot-current-column () > > >> + "Calculate current column, counting Unicode codepoints." > > >> + (- (point) (line-beginning-position))) > > > > > > Can we please take this opportunity to get rid of the confusing > > > "column" terminology? As became evident from this discussion, we are > > > not talking columns here, we are talking offsets in characters from > > > BOL. So something like "pos" or "linepos" or "line-offset" should be > > > better. > > > > > > Jo=C3=A3o, are you okay with such a sweeping change in all of eglot.e= l? > > > > I like linepos, if Jo=C3=A3o is fine with not making the absolute minim= al > > amount of changes to the code. > > Jo=C3=A3o? eglot-current-column is a user-visible function. would need obsoletion aliases. Are you sure it isn't better just to add some clarifying comments? I fear for my ability to recall details about this code with such a sweeping rename, accuracy-improving as it may be. So it's a balancing act, your call. > > > >> + (tab-width 1) > > > ^^^^^^^^^^^ > > > This last part shouldn't be necessary: we should move by characters, > > > not by columns. Why is it necessary? > > > > Maybe Jo=C3=A3o can clarify, but I'm pretty sure this is there to suppo= rt the > > UTF-16 way of counting offsets, so this ideally should move to > > eglot-move-to-lsp-abiding-column. > > Then perhaps the UTF-16 way of counting offsets should be changed as > well. I've vc-region-history'ed it to: commit 2cf7905887f2137869f44c3383a55636e38b4b81 Author: Michal Krzywkowski Date: Mon Nov 19 21:22:14 2018 +0100 Treat tab characters as 1 column wide in position conversion functions Fixes https://github.com/joaotavora/eglot/issues/158. * eglot.el (eglot--pos-to-lsp-position): Call eglot-current-column-function with tab-width bound to 1. (eglot--lsp-position-to-point): Call eglot-move-to-column-function with tab-width bound to 1. Following the link, I read this there: "This is because move-to-column and current-column count each tab character as tab-width chars." And, as far as I remember, at the time we were indeed using move-to-column = and current-column. But now we aren't anymore. So maybe, just maybe, this can be removed. And the full test suite must run afterwards. And then probably more tests should be added. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:47:22 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:47:23 +0000 Received: from localhost ([127.0.0.1]:36140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWXq-0006hN-KS for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:47:22 -0500 Received: from mail-ed1-f43.google.com ([209.85.208.43]:46948) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWXp-0006hB-Ai for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:47:21 -0500 Received: by mail-ed1-f43.google.com with SMTP id x10so52944392edd.13 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=uw7ncQPZ7dEXFpFczQc1btbDR3/ZEEQfvKKLZCsACGE=; b=PumjCtOIhtsxFlutbfqvUpxOQY7OwDUBoJRi4EXtlH5MTbde4vqmpoiQ4jTijelUAs dL3sBHvN0FYXw/NQD5RBnJlXn8t3e9IiPknDEZw+tvnmsa2KMKyAihyZfQUFmeWv7Vd1 jsIj5CiR4gI+x+W7kGDFJLViyn6WxlgPW+2xbp1W94hdReYJshPdf7qPtecJ6VcaJ1qz E/4YApLROZmUicpHJTwiapd6eGw2Jt3f+fwZ46pjY77O30Bd1nOXsrv2sl4ZDgjnn99g zDX8SrNwkqKiCtBAiLi40AyXmrWhDsflB9Ca4J0n1I+WH/cASkAC/P8atdrxrfZ3T2tE nMsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=uw7ncQPZ7dEXFpFczQc1btbDR3/ZEEQfvKKLZCsACGE=; b=WPZ2NrKb+NOiTUc+bSvbi9Oeqq1Me47SWUTZ97flQcFsbq8M/3O79u1hF1+PS8/4CW s1labGRz/fD2412Cp41+EYrXP+nh/BSiE2kiXH4emRUj9alSg1wtcigunoZYwpBdbsfd LsS8voxoVFD4xoNK8ddhQbFc1sp+Ohtmq68XO12nlhaWnVBM6kHbQrlNRybtkclBkPrg Jk1TrEWzhExNiP0IwS0banfaaBCJd0CDcyMiEUELO7gYVeM0GdjG1TR1osT7cKfDCHEC Fz+d8PYtT/U8+R/yCautLGqLpJOHxLQX9jDg086Bn1CEr3wmIkwUwK0/u4qwqmY99tza DZgw== X-Gm-Message-State: AO0yUKXNJsCCCQjW6q7J8K3tMymR+opDRLgDPdpLgIMWcxAXMCZyorcI PeTslPuX5JMHz/m95ebcwk2nBzwuKD4= X-Google-Smtp-Source: AK7set9kGgDjG4+bQ1fiFRPeqPau+r8moTEysplMYuZAEnfSWlTgTzSX+qrCxQowEHjOeC3DcDCzqQ== X-Received: by 2002:aa7:c317:0:b0:4ac:b6b2:1233 with SMTP id l23-20020aa7c317000000b004acb6b21233mr14536811edq.30.1677239235056; Fri, 24 Feb 2023 03:47:15 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id n5-20020a170906378500b008ecda4510c9sm2042063ejc.146.2023.02.24.03.47.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 03:47:14 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 24 Feb 2023 11:18:11 +0000") 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> <87wn479vj7.fsf@gmail.com> Date: Fri, 24 Feb 2023 12:47:13 +0100 Message-ID: <87pm9z9tfi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 11:18, Jo=C3=A3o T=C3=A1vora wrote: > The capability is stored in the server object and reflects in the buffer-= local > variable which will be restored when the session ends. I don't see > any problem with that. No problem, let's use your approach then. >> I suggest you to guard against future headaches. We can store the >> offset functions in two slots of the server class if you don't like to >> traverse the capabilities plist each time. > > No, this is exactly the type of complexity that I strive to avoid in Eglo= t, > especially when the added value is small. You see how =E2=80=9Ccomplexity=E2=80=9D can be a subjective perception... = To me, entangling things is a hallmark of complexity, and you are entangling server information with buffer information here. OTOH, adding a slot that is set in 1 place and read in 1 place doesn't feel like complexity at all to me. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:56:07 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:56:07 +0000 Received: from localhost ([127.0.0.1]:36152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWgJ-0006za-6J for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:56:07 -0500 Received: from mail-oa1-f49.google.com ([209.85.160.49]:46062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWgG-0006yx-BC for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:56:06 -0500 Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-1729bdcca99so2553453fac.12 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 03:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677239758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9D9TvTkggg/xB0zlPkOTxBk21JIc95Soo03Ox95Itoo=; b=P04jHLYGRwVCVFBdOj7KBp8xqV36oZqa++n2G4J+QhiS9Hbck+s84RGAUvtvObeseF jepyyhdAGecBkbex7mNN84M1VTaFPVAWiN13MhvVjcHIwntNCtZDDYlVGulSKY/hhOOc mjbUZbBqO+GKsXDxZOZPXkVOO+rQHpLc080b195pzZl4HI698o/UlUgoeFt/trOu4s0W cklPNeCJD+s0oXF7+Ltv1OZV1YC9TOfjaZHgaTYZJEZdbOfaGbJKyoYjmgg+dtz/SFeO U/wk0J5Zx2J2aGdJTO5xN0xP5GTt3UYk6Ar/I5EFLxjk6QVl2cTaTMt1gppUFq2hCmOb Ffdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677239758; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9D9TvTkggg/xB0zlPkOTxBk21JIc95Soo03Ox95Itoo=; b=Zf5ieZFMO0Ri+luwT0KxoWy51iVyX4DZ14C8/obQAmN4viIyyAIVgntbShyz32PQqx ktsXZY3b/yJgD/2ZTY/LuTSdNy3OXMvhnrtH/LOeFhYP9ACEw0m8MPykt9wGV+/U5Gvv 1A5s1ffWgHxIPF8cTx+FM8P4uTzRwFwCj1SOyK2YxrNKk3iTcQ1O1Q3xSTxWZ0ujbjyY T8+9s2seXq6CMS1lmOrKlstM028cZeVLTc7ISMBhJshRv9NOsFwgBvOPMbcGbMZ/3OKB IvmbNe5HbkuxQdCZsK8s9V1cSbgng1RnyA8RiTYeQ/tpA+aABAvlVTfh2r7lGaXKf80z GgtQ== X-Gm-Message-State: AO0yUKWcowilID8kDjwsCrFKqfIYr8Fx7JD99eSZjQVGexbZxVhzoYkp p2nEO8AVME3Aunp1194rGoY/LWj2xx8dd0UB0eo= X-Google-Smtp-Source: AK7set+eGBojrFUgTeryutG5eEsqjn2S+Qk2pZF6xEwAY0zp24AAtSolYzchze8DgDBnvZ6LH0WLmkai/3IcaLjtBBs= X-Received: by 2002:a05:6870:954f:b0:16a:6ab4:e878 with SMTP id v15-20020a056870954f00b0016a6ab4e878mr959691oal.8.1677239758491; Fri, 24 Feb 2023 03:55:58 -0800 (PST) MIME-Version: 1.0 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> <87wn479vj7.fsf@gmail.com> <83mt53nvhz.fsf@gnu.org> In-Reply-To: <83mt53nvhz.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 11:55:47 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 11:38 AM Eli Zaretskii wrote: > > `eglot-lsp-abiding-column' allocates a new string! > > If that is a concern, eglot.el could use a private temporary buffer > into which the encoded text is inserted, eliminating the need to call > 'length'. The impact of that in performance should be measured, of > course, to make sure it doesn't make code slower; it will definitely > improve the GC pressure aspect. Indeed, maybe something like this (untested): diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index e20d209332d..78e0f9c1f0c 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -1454,11 +1454,15 @@ eglot-current-column-function (defun eglot-lsp-abiding-column (&optional lbp) "Calculate current COLUMN as defined by the LSP spec. LBP defaults to `line-beginning-position'." - (/ (- (length (encode-coding-region (or lbp (line-beginning-position)) - ;; Fix github#860 - (min (point) (point-max)) 'utf-16 t)) - 2) - 2)) + (let ((measure (with-current-buffer (get-buffer-create " *eglot-utf16-measure*") + (erase-buffer) + (current-buffer)))) + (/ (- (encode-coding-region (or lbp (line-beginning-position)) + ;; Fix github#860 + (min (point) (point-max)) 'utf-16 + measure) + 2) + 2))) (defun eglot--pos-to-lsp-position (&optional pos) "Convert point POS to LSP position." From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 06:58:06 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 11:58:06 +0000 Received: from localhost ([127.0.0.1]:36161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWiD-00076w-M7 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 06:58:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWiC-00076S-1I for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 06:58:04 -0500 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 1pVWi6-0002yH-Et; Fri, 24 Feb 2023 06:57:58 -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=gTy9asBQOgUNLA5hOyauhplObHbtACPb482kdxi0uAo=; b=ile0ojNqK1KPLNhRI4nU T4g2BaiELgSDdRAEKYxxzrkfGzCoi+YefuF9ImvYQjeNBqTsZfVIAspItWjcDX7EihViDVA2azYop BtV+s2ICL7h3S9zMIpGW3oxvFmCT9ymmROikcDAqqVnW7W30AwNuSoj3Wk8b7/VCboBWqYOZ+YugH 8+TRP4iY3CEVojHvBoJS00A2auByjAdlYi4H4iYm8CsAHYyrBqY87tH64ytLLca4h9vfvNQrKD6Zh KybuRwU/AO15IexG1r4ETVSaETcVpbtURNkkhp1T2XrfcvXW/5GK6w9YctFvKpLCCNJyLdT0XahlR MooP/OM++ZkOIw==; 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 1pVWi5-0006cf-Kn; Fri, 24 Feb 2023 06:57:57 -0500 Date: Fri, 24 Feb 2023 13:57:57 +0200 Message-Id: <83ilfrnum2.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 11:43:18 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 24 Feb 2023 11:43:18 +0000 > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > > > > I like linepos, if João is fine with not making the absolute minimal > > > amount of changes to the code. > > > > João? > > eglot-current-column is a user-visible function. would need > obsoletion aliases. Yes. But that is not a problem, from my POV. > Are you sure it isn't better just to add some clarifying comments? I'm okay with that as well, but the clarifications should be in doc strings of public functions as well, if we go that way. > > > >> + (tab-width 1) > > > > ^^^^^^^^^^^ > > > > This last part shouldn't be necessary: we should move by characters, > > > > not by columns. Why is it necessary? > > > > > > Maybe João can clarify, but I'm pretty sure this is there to support the > > > UTF-16 way of counting offsets, so this ideally should move to > > > eglot-move-to-lsp-abiding-column. > > > > Then perhaps the UTF-16 way of counting offsets should be changed as > > well. > > I've vc-region-history'ed it to: > > commit 2cf7905887f2137869f44c3383a55636e38b4b81 > Author: Michal Krzywkowski > Date: Mon Nov 19 21:22:14 2018 +0100 > > Treat tab characters as 1 column wide in position conversion functions > > Fixes https://github.com/joaotavora/eglot/issues/158. > > * eglot.el (eglot--pos-to-lsp-position): Call > eglot-current-column-function with tab-width bound to 1. > (eglot--lsp-position-to-point): Call eglot-move-to-column-function > with tab-width bound to 1. > > Following the link, I read this there: > > "This is because move-to-column and current-column count each tab > character as > tab-width chars." > > And, as far as I remember, at the time we were indeed using move-to-column and > current-column. But now we aren't anymore. > > So maybe, just maybe, this can be removed. And the full test suite must > run afterwards. And then probably more tests should be added. How about removing it on master? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:01:26 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:01:26 +0000 Received: from localhost ([127.0.0.1]:36170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWlR-0007E4-PV for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:01:25 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:35619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWlQ-0007Ds-0c for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:01:24 -0500 Received: by mail-ed1-f50.google.com with SMTP id ee7so38773273edb.2 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0HV57kOUUw80uQcEk4S1/gFCUKUxdw5a9C9pNNw+zfQ=; b=eeNe7qLbxca8wVFORblIMRn+GSChnicI3BZOHGXTJnTerY9Wgha3Zc5WFvsFFNFzwt K5Pl0lf99IKd5ds23JJf/bPmOosPlJqfMXemzmYrMFkF0yu/yBu5XV5l1jEld+Hc/7du /AprBE0ziDCWG9gDGR0xwlvN9Bs0CKVAHME9DYV4LlGYHZJoFtUTjmT/RGZtdbMVT1o0 YeB43eIiSPXvJbfiUIc/CiexODfxcLruj8KFpFFPI1dnXsfSxLmm1gJUkaLtAG3rvDfp 9QzPVMv9Y25Sj3ONEAGnJQ/UMvPYQk4P4NyXGZtT4MKaltGrNzBxKErF3N1nDaXJ4b1v hISw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0HV57kOUUw80uQcEk4S1/gFCUKUxdw5a9C9pNNw+zfQ=; b=kMZ7kIenyJ3MFnoOCkOs2ZA5PsLLUZU64HIwNpaqwl4Io8tQyxW3SZIXUgxMeQTpB1 b4MrIGGb/pbzO6MLm81109fgmtxBptBaGre8KWqUK0z7b0eM6005M8e4fQCInv6T4OaH GHSiteoIw+Y7CfUkVHD4a5ceRKqHYJaNQnw0ggY6yhC50v/jJrwXkGXSh7W/k1L71LKO Usw2IeZkOJ5FTRWe27Jw/FbpHTYgGfX42qSYxCQDkCMbvXShD1e3CHQQxfxkg9NJCiM2 JAKs/ez04yWIpNVAhelLY6Zp31xnmGKO8cFkeN/Gub//oo7O7sb98nLNzuTm0N9h8ZcW Xyew== X-Gm-Message-State: AO0yUKXXb8Ts12f3Uk3qdtIY9muasLeRj4itppnXGYVJkWhBPoAIv1+D kPqwUM6uFtP+PXPW69BkTTcydGFZXSg= X-Google-Smtp-Source: AK7set+uKrSdg37r9H5tjblhXpmYfG03Alsi6/CI/2F6e9W2JIPQgBxJ3J7QOJwba17LWQqQBkeEnQ== X-Received: by 2002:a17:906:9bde:b0:8f4:1d98:af83 with SMTP id de30-20020a1709069bde00b008f41d98af83mr1946681ejc.74.1677240077548; Fri, 24 Feb 2023 04:01:17 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id u13-20020a17090657cd00b008e125ee7be4sm4288670ejr.176.2023.02.24.04.01.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 04:01:17 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83pm9znw0i.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 13:27:41 +0200") 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> Date: Fri, 24 Feb 2023 13:01:16 +0100 Message-ID: <87lekn9ss3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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)) >>=20 >> 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. Between two =E2=80=9Cwrong=E2=80=9D but perfectly functional implementation= s, I'd choose the more efficient one, because efficiency actually matters in this case. So which one is more efficient? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:05:25 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:05:25 +0000 Received: from localhost ([127.0.0.1]:36174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWpJ-0007KD-CP for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:05:25 -0500 Received: from mail-oa1-f42.google.com ([209.85.160.42]:44910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWpH-0007Jy-QZ for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:05:24 -0500 Received: by mail-oa1-f42.google.com with SMTP id 586e51a60fabf-1720600a5f0so19354696fac.11 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677240318; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fP7pQvpqSTBPlxmWsOn3Qg6Yfy4Lt/toBLUl0weXvyM=; b=S4rwER26oqAiM0IEjHPK1zf+04FGIs7iWeXjIY4zzw1iBygfkPRYJwqTpfhCIPqP3x 4UNX5M/EPINhiGJVM6X+0esazQfaGEzw7HJ4eck9BXpwR+l6sn1g1oYRplDMmrecw+P8 EoR5S9LJ4xVbLHoVAQ45Ptgxr2mmKXtQ7gxo+0Z5AFu+cKdKCZvuIxsqwxYGa7PruqR2 dloH48fKjHWBC9SfcmHoIrbnuVO6tm6w4CBY6kjCSclUND2ufSFW3fz+Ua8jig7pgW6T AnSBcHADpyUew0tgjnHn4kcxC3TvM7L6FlEQraGkmuFazm09A5rBpvQGX7kTUx0tlw4H 34BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677240318; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fP7pQvpqSTBPlxmWsOn3Qg6Yfy4Lt/toBLUl0weXvyM=; b=g9UfS/ZWIkMteO8YpE5EmP92j/960Xad4/aXYY8AXIEtQBovUYdKF498ZHtK1qXRrO rA2EiSy80J8CCebgfY0Ha0RCXDR8qyWGj43wueR9ejRrq/ickTfmZrq7IoqYlM9paIRH cp/NcXTdmlqjWuVY3t2m2JSkwV7dwVBegnDt1HIoiAyyD91qUoUYiMGekbduqYZsvuAp VH6O1b02JFjDe0fgvutEftTIzpJVmYU8mvaV5nai8YzTlNayrthjz3T1kh+1NSIW6stT bA32e383n8t32IhH+QpKmVUUGuUEA8y994qu+ExuM01vtSosv0n+wwmNhHkw0jA7Q+lq 1zew== X-Gm-Message-State: AO0yUKWlL7HEhWobpCbey45QwL/hSPwUg9HMOaSBJBcWFznQo1c4nrol bd2HXVT9IQkeRGrEcrnFVNDQzRVvPRL2kURuGlE= X-Google-Smtp-Source: AK7set/J5/Exhl2DRWkAOqRoutrFxnhSEWtyQ39jcRxTLaL7oL7pMi4zO/jbGB7/1wvKHZAoSiEcIQGrVvyg5b7j+9s= X-Received: by 2002:a05:6870:3a34:b0:16a:17d9:b66d with SMTP id du52-20020a0568703a3400b0016a17d9b66dmr950869oab.8.1677240318269; Fri, 24 Feb 2023 04:05:18 -0800 (PST) MIME-Version: 1.0 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> <87wn479vj7.fsf@gmail.com> <87pm9z9tfi.fsf@gmail.com> In-Reply-To: <87pm9z9tfi.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 12:05:07 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 11:47 AM Augusto Stoffel wrot= e: > > On Fri, 24 Feb 2023 at 11:18, Jo=C3=A3o T=C3=A1vora wrote: > > > The capability is stored in the server object and reflects in the buffe= r-local > > variable which will be restored when the session ends. I don't see > > any problem with that. > > No problem, let's use your approach then. > > >> I suggest you to guard against future headaches. We can store the > >> offset functions in two slots of the server class if you don't like to > >> traverse the capabilities plist each time. > > > > No, this is exactly the type of complexity that I strive to avoid in Eg= lot, > > especially when the added value is small. > > You see how =E2=80=9Ccomplexity=E2=80=9D can be a subjective perception..= . To me, > entangling things is a hallmark of complexity, and you are entangling > server information with buffer information here. OTOH, adding a slot > that is set in 1 place and read in 1 place doesn't feel like complexity > at all to me. Very true, it's subjective. But both of our approaches are using multiple levels of removal from the source of truth. The source of truth is in the server, then it's cached in eglot--capabilities. Then I propose another level, cache it a buffer-local value, and you also propose another level, cache it an additional slot of the server. And don't forget that the "server" is _also_ hiding behind an indirection, the eglot--current-server function and buffer variable. What IMO makes your solution more complex is that the new alternate place of caching will not cause eglot-move-to-column-function and eglot-current-column-function to be deleted. We can't delete, even if we wanted to, because of backward compatibility. If you could, I would agree that our two solutions are of similar complexity. But that's not the reality. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:09:33 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:09:33 +0000 Received: from localhost ([127.0.0.1]:36185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWtI-0007Qi-QB for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:09:33 -0500 Received: from mail-oa1-f48.google.com ([209.85.160.48]:34780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWtG-0007QT-Kt for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:09:30 -0500 Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-1723ab0375eso14982581fac.1 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:09:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677240565; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=bsWUUvBAAqZ5GfnQFqzsk7lUx/E1+rz6tKQK5Ggf3+4=; b=QpOIHyJB9I+ZV87WhMvknYfQVLK5ZenjwOeERsCar4LYjkQyduW2nJ7e4BMtAPHTaV uL3xqogiCjGcaWxUQV9itFEccrzW0MFgLU6cdJXKZ9cg9hU66OxpanPOIylMkYwnaVnx gHnaKSwzgxhRq6/gwp/3JykmN93RR+ZnCapxdXaOmaqSD17Uwc5oykXElP3IPnUIaO4d ++32WYIeAnmYTnVZpeRqPRFZ1mtpLA9V2kMQStDQFaiRcMPbsmIDNm1b9DWvC6v+vBo5 N6J9qnUWBuViGu+XKiHTcFGgGLVNvigSg5k5yNOW+ua6cj7tXTV3LOexxLIQTvKDxMWD EQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677240565; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bsWUUvBAAqZ5GfnQFqzsk7lUx/E1+rz6tKQK5Ggf3+4=; b=mLjh5VHBu1rdj6Q5FvBuMGUseoP2QHHDanPFbFxzYAZy0cQN+9Qyxvh0Q+gRdqUvb2 z325PlY7TujObPzpVU0QIO5VhpPbM4D/8YKfgnSLzb3wHS2b9aII7Ta2ylBFVMH3CR2b naDFwes2/Lv/arGj5wLENasPAlGxD6MuXW3VOQLbp6P1Zzi9XWgHpZmMbgj8pun/P+gW dOFs2QPLN7pbbEnYfpbbrsCNyy38knOOlhvCrKFIqlwam3lR7JWTA+DsBVM9vu92XlZl fA9541iONs/IDcO/HiUjTjxrhMCfr6QxgSazb61BSxywcV9peDF+CEhk1hBl5pEfRAHB UXFA== X-Gm-Message-State: AO0yUKUMJo9swZLSaU1h8ieADGa3z3pAuFdE71MR3xWQcvSy43FJ1gQy IgqCH4zD2r0bjMa5KSm63S9XO5l3qx145r3T075QSf3X X-Google-Smtp-Source: AK7set99EqBsotscguQWq/APGVy8uwjMXaOz196TE6cHl2TcNDPETRGVtRFK3YnKPFl5QBF4wnSf8IjAyi+A8T0ko2o= X-Received: by 2002:a05:6870:954f:b0:16a:6ab4:e878 with SMTP id v15-20020a056870954f00b0016a6ab4e878mr970587oal.8.1677240565112; Fri, 24 Feb 2023 04:09:25 -0800 (PST) MIME-Version: 1.0 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> <83ilfrnum2.fsf@gnu.org> In-Reply-To: <83ilfrnum2.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 12:09:14 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 11:57 AM Eli Zaretskii wrote: > > eglot-current-column is a user-visible function. would need > > obsoletion aliases. > > Yes. But that is not a problem, from my POV. True. > > Are you sure it isn't better just to add some clarifying comments? > > I'm okay with that as well, but the clarifications should be in doc > strings of public functions as well, if we go that way. Yes, makes sense. I'll let you decide what is cleaner: sweeping renames or docstrings. And thanks in advance. > > And, as far as I remember, at the time we were indeed using move-to-col= umn and > > current-column. But now we aren't anymore. > > > > So maybe, just maybe, this can be removed. And the full test suite mus= t > > run afterwards. And then probably more tests should be added. > > How about removing it on master? Doesn't make much of a difference because ELPA :core package. If the change is harmful, that harm will be visible "soon". I think we can just add some tests to eglot-tests.el and test the problematic case collected from the old bug tracker, if it's not being tested already. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:14:59 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:14:59 +0000 Received: from localhost ([127.0.0.1]:36203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWyZ-0007a2-C3 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:14:59 -0500 Received: from mail-ed1-f41.google.com ([209.85.208.41]:36459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVWyY-0007Zm-01 for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:14:58 -0500 Received: by mail-ed1-f41.google.com with SMTP id da10so55269025edb.3 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:14:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pYcfOoizcGR0l0q4OG6ZDpfAr2qBWYCWeukmVPeTQ7k=; b=po8XxZF0zim6X4AdKWTVeAHAg5uwWDznwKtJykBLIhRUCU+aR0sChIQ7TmKLn7LRLL 2xbCDruVeOnaU0QZ0cewrtY9skrCBMbqW838pQtRvkjXADMLuYGUYPgzRN7oOYFytBvI glztK69ZY0QVuCMFQ0BFo3c+2ESxYrRJeN2JipGDHTpoHB7sUOeUQTKz0HMEnA6tWR/T OVc3QZvJ59k10EUL6Kpaqp3b6G65QuM7IfK/g1hBLekYSYq24GeX6uvrzhxqFu1Ts5NX HcnrwKDnooLC8+zvXeKWyr4cyyW+rZjhqIi8MrL6LDRKHgjhNbHJYmASFH1gf7ljlSDT /HXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pYcfOoizcGR0l0q4OG6ZDpfAr2qBWYCWeukmVPeTQ7k=; b=F91b6JAEBQuEEwg0nbn+MjDrR8PRsqCmO7nwlLm4VS22srkF/oUffjFIlQ2nNK+2ek iy0HL12mVYSD4ozfGJKsSB70iGOygTunaKaMjDHMjgp/NYYhkqzvfMzOXSushAytsplK BMXy55ThN0q+O3nmtsjw+dRdQXz6feiaPtoU03fG3tPugTkODzeVjWTKpaNINXKh5lph pwxBZz5qMFJ9Pmct5mquhnZu6aRBycZagoMKnRibZZWXK4v/kZm+QpOGxsMe1u9ojSRT hf3e8s+N/dEnnpcfCm2p2keu0rX7inyuHeyqrYU1LdA8vu/cDpRvAUBdg/Ul6UdxtYfN MZcA== X-Gm-Message-State: AO0yUKWuJ+nCZyJxrxvTx+10JhuYWhGiIJsOBIAZ9i4T1frW5Rxg81OA v+5OcX4SqVKInsOZVfHgr1TuYKZQ6wE= X-Google-Smtp-Source: AK7set9yp2/zeMNE90lMZUequdwBQXScyvwKN6QBe496UlgrSTN4fQF3P/uWmbx3MrsvpHbpqiZUSA== X-Received: by 2002:aa7:c1cc:0:b0:4ad:7204:6968 with SMTP id d12-20020aa7c1cc000000b004ad72046968mr13239488edp.32.1677240891781; Fri, 24 Feb 2023 04:14:51 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id z5-20020a509e05000000b004ad03b18ae3sm5614961ede.62.2023.02.24.04.14.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 04:14:51 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 24 Feb 2023 12:05:07 +0000") 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> <87wn479vj7.fsf@gmail.com> <87pm9z9tfi.fsf@gmail.com> Date: Fri, 24 Feb 2023 13:14:49 +0100 Message-ID: <87h6vb9s5i.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 12:05, Jo=C3=A3o T=C3=A1vora wrote: > What IMO makes your solution more complex is that the new alternate > place of caching will not cause eglot-move-to-column-function and > eglot-current-column-function to be deleted. We can't delete, even > if we wanted to, because of backward compatibility. If you could, > I would agree that our two solutions are of similar complexity. But > that's not the reality. You might have missed it in this long thread, but my proposal was to obsolete eglot-move-to-column-function and eglot-current-column-function now and remove them in after several Emacs releases. The rationale is that these vars were introduced to work around nonconforming servers. With the new LSP capability, there should be no excuse for nonconforming servers to exist. They should all adapt in the medium term. So yes, I have no problem admitting my approach looks uglier today, but it's clear to me that it would lead to a cleaner result in 2030. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:17:07 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:17:07 +0000 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 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 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==; 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 Date: Fri, 24 Feb 2023 14:16:58 +0200 Message-Id: <83h6vbntqd.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87lekn9ss3.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 13:01:16 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:18:48 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:18:48 +0000 Received: from localhost ([127.0.0.1]:36217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVX2G-0001dT-IJ for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:18:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56918) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVX2F-0001dH-2F for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:18:47 -0500 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 1pVX29-0005df-Mb; Fri, 24 Feb 2023 07:18:41 -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=GbCL/Afvyx/kedp590YjIbLlV2eqnrPzfDfgFf4vt58=; b=XgNQVA1r/VFDpFI/pkRg pYEJLkvfiZK+9mR1JHLGCJKHOTMEARz8Xbtvnlsn5WUzCVIitN3fVKInjWlZ4qIqKWafZEG5sC8p2 w5pQlDI0yNZll7keYcw6j7utAByefEh/5sR187PMD9xZrsDgUbgYILZiXPxwkAEqJjszg2R/3ZDAY AJrP2zUW4+0c7ehqdssvmg/YIC82IN2L1wdfjytC+P7xdLx5dri5guoB4hOYZ6JyiesT34qQdkWcn +t67oRO2ygH8Ky+JwXTvQD4XFerYn7cDnSLRoMI0KsAEVOGW67w1VSxaKGfBNIn+V1de0i34vh9aw PA7hhrspdoiA6w==; 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 1pVX28-0003Hm-VG; Fri, 24 Feb 2023 07:18:41 -0500 Date: Fri, 24 Feb 2023 14:18:41 +0200 Message-Id: <83fsavntni.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 12:09:14 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> <83ilfrnum2.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 24 Feb 2023 12:09:14 +0000 > Cc: arstoffel@gmail.com, 61726@debbugs.gnu.org > > On Fri, Feb 24, 2023 at 11:57 AM Eli Zaretskii wrote: > > > > eglot-current-column is a user-visible function. would need > > > obsoletion aliases. > > > > Yes. But that is not a problem, from my POV. > > True. > > > > Are you sure it isn't better just to add some clarifying comments? > > > > I'm okay with that as well, but the clarifications should be in doc > > strings of public functions as well, if we go that way. > > Yes, makes sense. I'll let you decide what is cleaner: sweeping > renames or docstrings. And thanks in advance. I'm not doing the job, so I think this is up to Augusto. > > > So maybe, just maybe, this can be removed. And the full test suite must > > > run afterwards. And then probably more tests should be added. > > > > How about removing it on master? > > Doesn't make much of a difference because ELPA :core package. > If the change is harmful, that harm will be visible "soon". > I think we can just add some tests to eglot-tests.el and > test the problematic case collected from the old bug tracker, > if it's not being tested already. Fine by me. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:32:06 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:32:07 +0000 Received: from localhost ([127.0.0.1]:36227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXF8-0004Nw-MJ for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:32:06 -0500 Received: from mail-ed1-f46.google.com ([209.85.208.46]:39664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXF6-0004NR-Do for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:32:05 -0500 Received: by mail-ed1-f46.google.com with SMTP id f13so53650902edz.6 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=6KLpr6hEYISEUZZfoSoVl+bebwCfNialGL7PTAry+YI=; b=LoWN9J55WiiWEPmWxMbqMl9yVKUtc9KlmOGXm5hd1BgGnkI5nO6mwbHjuSwXpFqxSH bMQ5OsxNnC63H1QwQ8qKfiZmYfRUwLMjY4YdhsRm4kVlkLUg8iZzZfySswWgtDX+aQ1y J2MRhbHW/wrcrBWkHGe4pwYwCI/O9pHahoJLQSkFC/lc7XXKqSPxGUmW4KugD2AA9SDv hJi7CeD8OWo9YFut+Fosd+eN0m91vOq+nKve/IeTOvAGKeu9Vm87Evs/Pqk6aWJ2HrB7 /U/iTOIWeAEYa4THyjou2D3HHQtnBs6qYf0V8Kf3LryiSVbKNBZlQt0lRjEGjL9KyQH8 wuxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6KLpr6hEYISEUZZfoSoVl+bebwCfNialGL7PTAry+YI=; b=JEFlguGotM6Io0Hl3uTGNw9gTDnJvBBqfT3mTS2H/S6ZdCdvNfYHQ8QG5LbmZovfGt gJA7oiLV1P56rpkVhjg9TiswSuGbhGihSbhfxI2QGknEv+cRU29o4n6UszEs/bvifkYr aiFL7Tt44fePLguNRmG2DZ7xm3oBl07DPbAqRK4qHSdrlIgKKaovqqsBljUMMx2b/K3q DyqLIEBm1L7qJXtOU5WNPz3JHhArQOFB+smU6w3y9/a4aqZM8Qcrl7ln4lthwLeDBa0w VoinP3GGe/BkDrzsTe1rT3/OIJWQux9pze+yFIdrju3KGBBGz07s46ppDPPW2j0bgzmR ftig== X-Gm-Message-State: AO0yUKXcIN7Qr7s1mm4GVXesX+ZmIlIQy9x9CGURjI5I8SdnxFl9FCFb z7RsPBSPO32VpQge7SSXHsmZyaGK3cA= X-Google-Smtp-Source: AK7set8s4RSgmQs8JanpfkAj8hI2YwvAkWf2+Nh6Xxywa7uHAX2LceiM6lhmOYnjr7fzzEtL/fgVlA== X-Received: by 2002:a17:906:ad82:b0:8af:40b0:3dd1 with SMTP id la2-20020a170906ad8200b008af40b03dd1mr23770085ejb.27.1677241918055; Fri, 24 Feb 2023 04:31:58 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id s15-20020a1709062ecf00b008e97fdd6c7csm2708275eji.129.2023.02.24.04.31.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 04:31:57 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83fsavntni.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 14:18:41 +0200") 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> <83ilfrnum2.fsf@gnu.org> <83fsavntni.fsf@gnu.org> Date: Fri, 24 Feb 2023 13:31:54 +0100 Message-ID: <87a6139rd1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 14:18, Eli Zaretskii wrote: >> Yes, makes sense. I'll let you decide what is cleaner: sweeping >> renames or docstrings. And thanks in advance. > > I'm not doing the job, so I think this is up to Augusto. So I'll provide the new feature using the old-style names, and then we can see about names and docstrings afterwards. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:35:49 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:35:49 +0000 Received: from localhost ([127.0.0.1]:36235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXIi-0004TD-M2 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:35:48 -0500 Received: from mail-ed1-f47.google.com ([209.85.208.47]:44593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXIg-0004Sy-Vr for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:35:47 -0500 Received: by mail-ed1-f47.google.com with SMTP id s26so54193789edw.11 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bv6fR6xgw7VwuCAB+FqtXm+/xCpRW5z/uEX72eImxTU=; b=eOgAqKBrixTel/erAbDLddY0hdjYWU02NpLh1kFpCIoH7bxgc+g/U6L09A/+gvfF8M wDlB6MTEPKdc+f/0YYJNIip1hthF2woBqJF4D9wxr8to+eMyVxvkHpvvU/liicZAO6sb VE9waiupscMWPmhFYhh3b3L+EG9pc1o9Tt+7+XnlKsh0tPxClAaRm/IuAubHFB9kLFdO xeMTchq8crfcwVoi2nsmjP7EYQ7rIzwvx3Ye7qt3FNkcAzLie81lf5qxCbG5X8IvLle4 ZEHq+v1o9rkMGs0/Lh72jBMMtgcDBQDKBcTaWi9uIB8ReU7NdFyhz3Y3CZQECOX/ApGA 4gNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bv6fR6xgw7VwuCAB+FqtXm+/xCpRW5z/uEX72eImxTU=; b=Nmcp5k0DOX8sy7ZLbubGcTFqgZ62pIbx3DmTtS6TD0OSbJHCzEs/9LW3lqumnOYSuv p3OVUUOoIYaK9wg4qm7dCXOH+GFaplxCpXmAzVQNXUBUSGlRTKSbCSdFvnyW2YItSWIk tS7XLSZ+MpZT/WQAtEnVjpEIWqf3ZkUMbZOdGTkR1dsQ0lIOjOpE9v+iYBM3fDzvOqvz a7MqKKEtm0QbRfKto6dd58wpxup9kvG3y+VJ8J1xL/3xr2a3AzgVx2eKdfpJO+Zy26G0 eokvxoxQaLXr+VcPnOhmln4IXOGqy8tixWuUDYsXJvu5XnSrGlcZpEdzzbtNDp1Md9OA SUSQ== X-Gm-Message-State: AO0yUKXVrejHzz5Dk7PwiRgrJyF/Y/5/Io+IxEkwkD9OWsIQ3vQrh8SQ 31lPyDk6iQW60zcThjyU0hJzaKjkpeY= X-Google-Smtp-Source: AK7set/omttZMaoZggEPzZglCg6+RXouKePuLNkyOBCnJbbbzbXq66Wx7+p49fT5H62kE18ltSwz/w== X-Received: by 2002:a17:907:3f2a:b0:8e1:12b6:a8fc with SMTP id hq42-20020a1709073f2a00b008e112b6a8fcmr17875926ejc.4.1677242139704; Fri, 24 Feb 2023 04:35:39 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id y17-20020a1709064b1100b008b7a9ff7dfdsm8813173eju.162.2023.02.24.04.35.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 04:35:39 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83h6vbntqd.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 14:16:58 +0200") 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> Date: Fri, 24 Feb 2023 13:35:37 +0100 Message-ID: <878rgn9r6u.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 14:16, Eli Zaretskii wrote: > 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. You can't even send or receive a message through the JSONRPC channel if it's not valid UTF-8, and `json-serialize' rightfully emits an error. So there's nothing Eglot can do to cope. It also should not, IMO, because we don't know how the server will respond, and we must trust the server when it tell us to do destructive operations like adding or deleting text. > I don't know, and I don't think efficiency is the main concern here. Okay, but Jo=C3=A3o expressed his concerned with efficiency 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. Here you have a good point. LSP got into this mess in the first place because of exposure of JavaScript internals. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 07:55:38 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 12:55:38 +0000 Received: from localhost ([127.0.0.1]:36244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXbt-00051d-Re for submit@debbugs.gnu.org; Fri, 24 Feb 2023 07:55:38 -0500 Received: from mail-oa1-f49.google.com ([209.85.160.49]:41883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVXbr-00051P-Ms for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 07:55:36 -0500 Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-172334d5c8aso15718101fac.8 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 04:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677243330; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=J4DP3JrIikgLqgiPa2QpJ+K9Nggq7hHDmLnOrVUZJHA=; b=Jgw0awMV1CErkc0IkEoqLgQ+b0iQFGJyUdfeMMW/x7aCy7/1vc/c7ttkB+xGTc0NB4 i0K93kLJNjXJDmzl5u7B+h2bdQgkwBLhLNPCLcwL66b2GC6JTxnoW21rkw9yR2uwGob9 TDqT7FIDa+y6FAWIiuSxNJz7sRMEjttsd76sigdqARF8aKLiz6whRH4YRdK/EL3lIIYp c0yDa7UuTRaGPS+nHd88RSFWtuhvvzITkzW79jKn/wGBLyg+38lrl+NZ35QveZBXSCMQ kE/UotDHebI2RcU4qwSgMZrLpKNFlkXE+pjjL4fYFqM5xnozNk1tDj6YADZvDMRKyqxR VB5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677243330; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=J4DP3JrIikgLqgiPa2QpJ+K9Nggq7hHDmLnOrVUZJHA=; b=dT/c/1zyElMJajK0OXKn1bXEZ+lJKYpBTn5ilkbB9tYnPpalW7RKVlKCB0v2UzQMtj UZrScSqFER4gC/e+bdswpVLZ5dhr3Hkd1N+ZA1Mwx1Rph4Mgw+JDO6NuJg4oWqacrOQY wHdz+yIPk3Sen4p/+Di0xux14WcfDw/7iScfyPaLgOa79ujgwfsMOJgZ+bwoJaF0MjPf wi0B8oXmMJv/z2g99uN78XjvVs/9ApJcqDu0870oAa3vftVLb7X9wT9dPXPzVvps9V+j Bzdk4WNUnWg4bBlsghHeMmrGpUktVM3eMAFmib77wM3xKdGCfvE+rw6Q3u9yOEnUNohs 5LPA== X-Gm-Message-State: AO0yUKVxLAo+MqoTRR74hY94Y/EjiRdRRxP+4Us2USrVMovdifJFvhS6 Lq+CBLi43sV7sg2ieJ/r9pKdmRz5yUYhDlNzRFs= X-Google-Smtp-Source: AK7set/rdTCYOofupTc2X1GkGm/MmpDEKDt88VPTqbR1cF/E3dR0xioDA2F5vK5kl5SLjnpDnU4qtvCBY5ev9DBtSCc= X-Received: by 2002:a05:6870:3a01:b0:171:8f59:3437 with SMTP id du1-20020a0568703a0100b001718f593437mr1044544oab.8.1677243329943; Fri, 24 Feb 2023 04:55:29 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <878rgn9r6u.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 12:55:18 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 12:35 PM Augusto Stoffel wrot= e: > > On Fri, 24 Feb 2023 at 14:16, Eli Zaretskii wrote: > > > 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. > > You can't even send or receive a message through the JSONRPC channel if > it's not valid UTF-8, and `json-serialize' rightfully emits an error. > So there's nothing Eglot can do to cope. It also should not, IMO, > because we don't know how the server will respond, and we must trust the > server when it tell us to do destructive operations like adding or > deleting text. > > > I don't know, and I don't think efficiency is the main concern here. > > Okay, but Jo=C3=A3o expressed his concerned with efficiency here. It's _a_ concern. And so is clarity. I don't want to have unneeded late-binding. These functions are called very often and the continuous advance of LSP with more features like say, server-calculated fontification will make us rely even more heavily on them, almost like we rely on a fast goto-char. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 08:34:28 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 13:34:28 +0000 Received: from localhost ([127.0.0.1]:36312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYDT-00064g-NG for submit@debbugs.gnu.org; Fri, 24 Feb 2023 08:34:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYDR-00064S-Qq for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 08:34:26 -0500 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 1pVYDM-0004gt-Jt; Fri, 24 Feb 2023 08:34:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8Sjqns6/3LQYtwZWFKAFae3AZiuo3zM//kd/FDNaCEA=; b=oDMS/KFc9h17 lI1rcxMCu3umwyOfV5ozYRuwr06MegUuolnql6wSEvs/Osq1p1HRRsg6t9ccYlkyIJE75c3k6NEac PSZzJ0yNa/ExkIUPYNDBX1CopL4opQe6ozxKuu06ETW2OyVLNMmlFzogqMV5vS+bKKPDmN1VQ86/G hj67by1YSA637K8kVqSfbWT2RELdsj8gxDu+Y7fr7S5WlCmEEeeqxkiXpGvGyrhrCCkrp3Rqq+3PS Kuppqp3x1j0qqfJ68unNCBK8Mf1BIdRNUr7K5fLVpmAm9MJtmJEEgSeDlWVitWsaWaE4xOwMBc3Fa Gy84gllVJyUrFnaJScbY0g==; 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 1pVYD7-0006av-3B; Fri, 24 Feb 2023 08:34:20 -0500 Date: Fri, 24 Feb 2023 15:34:05 +0200 Message-Id: <83edqfnq5u.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <878rgn9r6u.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 13:35:37 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 13:35:37 +0100 > > On Fri, 24 Feb 2023 at 14:16, Eli Zaretskii wrote: > > > 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. > > You can't even send or receive a message through the JSONRPC channel if > it's not valid UTF-8 That's because we _decided_ to behave like that. A decision that is not carved in stone. > and `json-serialize' rightfully emits an error. There's no "rightfully" here. It's our decision to signal an error in this case. Substituting some innocent character for the unencodable ones would be an entirely legitimate alternative. > So there's nothing Eglot can do to cope. I'm talking about Emacs as a whole. Eglot shouldn't second-guess what we might decide some day, definitely not in areas that are not specific to Eglot, such as JSON. > It also should not, IMO, because we don't know how the server will > respond, and we must trust the server when it tell us to do > destructive operations like adding or deleting text. See above: replacing problematic characters would also solve this problem. Some other applications out there actually behave like that. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 08:43:48 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 13:43:48 +0000 Received: from localhost ([127.0.0.1]:36322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYMW-0006IX-Gt for submit@debbugs.gnu.org; Fri, 24 Feb 2023 08:43:48 -0500 Received: from mail-oi1-f181.google.com ([209.85.167.181]:37811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYMU-0006I8-7F for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 08:43:46 -0500 Received: by mail-oi1-f181.google.com with SMTP id be35so15891031oib.4 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 05:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677246220; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Bfkgbc31b3Aj9WP/+PbrlhMC2xBWimPRc+VsW3XNKv4=; b=CUBEpY3SsEiqDTYMZ4Vvyu+d2PBZALUeXRcynlglSMXegNv/NpN1E5npjv8UW35+lR 1WvvQcidJ7o1F6HsYiQQeua+DP8rrDlvaNR3mNFj0/oRxrmzjICwRGFPeRUstlzTqyOi qslvjMt+0Gyghi8D9Mwh1KURI1qbNb2YDapfImANms8Ty05BrS9F1dBsYSnifAj3Iqa6 P7usaWHZbqy0BX/NNRsjciwvhQCvIw4ue0sWx5/VJ8y8by6EpLPig1iFXtv8adGIeD7j Q8a38xp+bhaysGvVJqX0arjWrknGdvovjr0To5fAco1Jp4UWj8FAJod+hmv8jen1KD0I LVuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677246220; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Bfkgbc31b3Aj9WP/+PbrlhMC2xBWimPRc+VsW3XNKv4=; b=JQ+dge6J6HZQD0rcFbw9Gp6cSpFDEFbRbELz/dU69dZ0fsS0hBRe3GCdoXpmpbVsLf Vk51mRVMX8uioX4T3LjvY2Th9dRRYYLnBhpQmxR7NUimXSA1e7EAWAq/1avEFuell9dS ndBJh/lobKCSj0D0wmyVB+ELqOoTp+7ZgLIS5bZAZTjZNdkiLQorYTGfgb+PDXvlm+1Q rOaeIoBYm92sSZEI50MK1Jb/jQ2ujJW6owOymCl/zaqOp5fJYMbAYJxsIFOmIc9lQuLk kNY6VDLU0Y+9cIRuqFSJxAdF7LhwB2MaGAApHQc0YIIGP2KWQYmTT74XwIg0WHLkHYLd ekyw== X-Gm-Message-State: AO0yUKUafT+urv4OSotPsoU1hIaPJ+r/D/X9vO1F/ckgBx8Crh7HVA2O SWO53jvA8fPf+85Dc9FDLs2anra/SEFW7iW8KvE= X-Google-Smtp-Source: AK7set+FwZkD3Rm2AYUT2GxBZsjl9lw3ECpY64ycNG8t/tbDwPjjWuJBKColjS9dt4sxvuBiZjXVIcgQKxo1UmstsLk= X-Received: by 2002:a54:4193:0:b0:37d:6c5a:15bc with SMTP id 19-20020a544193000000b0037d6c5a15bcmr1052291oiy.8.1677246220566; Fri, 24 Feb 2023 05:43:40 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83edqfnq5u.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 13:45:23 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 1:34 PM Eli Zaretskii wrote: > > > From: Augusto Stoffel > > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > > Date: Fri, 24 Feb 2023 13:35:37 +0100 > > > > On Fri, 24 Feb 2023 at 14:16, Eli Zaretskii wrote: > > > > > 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. > > > > You can't even send or receive a message through the JSONRPC channel if > > it's not valid UTF-8 > That's because we _decided_ to behave like that. A decision that is > not carved in stone. At least or LSP, it seems it must be UTF-8: https://microsoft.github.io/language-server-protocol/specifications/lsp/3= .17/specification/#contentPart "... utf-8, which is the only encoding supported right now. If a server or client receives a header with a different encoding than utf-8 it should respond with an error." No problem with making jsonrpc.el support more encodings, but for LSP it must be UTF-8. I don't see how this is relevant to the code-point counting problem here, though. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 08:51:46 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 13:51:46 +0000 Received: from localhost ([127.0.0.1]:36338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYUE-0006Zz-6p for submit@debbugs.gnu.org; Fri, 24 Feb 2023 08:51:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48148) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVYUC-0006Zh-JF for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 08:51:44 -0500 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 1pVYU7-0001lH-CA; Fri, 24 Feb 2023 08:51:39 -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=HxWaLid/lvMbIGAidv5jkxZDa8NbSP0zZre3Izr+wRc=; b=UsE6PC5MUW4q88xK+qec YuymgikJkXlCVrHpHO5wmE4n/aHo5PzjMGxS/6hA9+ZJmyBP0XiFF0Kfx0JIr4yG/syMt7/40zFDx h5VS7cV1ib5txU91LNjunUHDPeoVzfnPZ4FvLu3MiZ39re1cxbSa5I+3pi0yYuAYxOqxZCXhgZZCW LHp8YtQl9qW/S7ElPVb5WPz8VhPe6H2tCP6ZrcSq/g8bdfznytOqIbh7ASB+5UpMKcW6iC2Vsv6Rm uhBgaT5zN4fHSZwsY3T7JAkwIOGq1vG8BmKVI3WSYnG3/Q+ePJGzZo+er/e0jWqi+JY1myJE6iN/3 cojRdbZOWLHGDA==; 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 1pVYU6-0003oH-Hw; Fri, 24 Feb 2023 08:51:38 -0500 Date: Fri, 24 Feb 2023 15:51:39 +0200 Message-Id: <83bkljnpck.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 13:45:23 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 24 Feb 2023 13:45:23 +0000 > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > > On Fri, Feb 24, 2023 at 1:34 PM Eli Zaretskii wrote: > > > > > You can't even send or receive a message through the JSONRPC channel if > > > it's not valid UTF-8 > > > That's because we _decided_ to behave like that. A decision that is > > not carved in stone. > > At least or LSP, it seems it must be UTF-8: 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. Substituting some innocent character for the unencodable > ones would be an entirely legitimate alternative. > [...] > See above: replacing problematic characters would also solve this > problem. Some other applications out there actually behave like that. That's the alternative: replace the unencodable character with some replacement. > I don't see how this is relevant to the code-point counting problem here, > though. It started when I said we cannot count bytes in the internal representation of text when we need to produce UTF-8 bytes. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 09:45:41 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 14:45:41 +0000 Received: from localhost ([127.0.0.1]:36482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZKP-00080u-Bz for submit@debbugs.gnu.org; Fri, 24 Feb 2023 09:45:41 -0500 Received: from mail-ed1-f42.google.com ([209.85.208.42]:40900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZKN-00080f-6d for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 09:45:39 -0500 Received: by mail-ed1-f42.google.com with SMTP id i34so30341708eda.7 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 06:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=yp8i6EoMEvTtaSt4Jv0hcYlB7SnUqvBODHFvvD+TDAw=; b=C/HDMaFI6i3hfTq5q0jxL7qpQqY62+XyVHkwoQd4WwtfpDESanc8lBhw2MLXQ9yNF7 d4W9JhQ1AgVH2k+icd1x2fp8HUTC+e5Za1LFdMu4KXkmCtuc//WiGi/kZIciD+CcvY9e Ry2C1EkMDYd3DNWoSOzqNK4FdV4Qyo9znYrOOp31VJJlLJuAgsRkUTypUDfv17EG9M1i bXAA5yJxnbKSK0tOVRIn8pnF1zMhAyG3uftkO72PsS8h57XkoI+FYmiRbov5vlCqDdKs JZHprF+CmVJ/w6mW41dB0M8SI5I/ShyQDNuWM1P+svOJuoZr7PuHhrpyJQlWuwOb6Yw0 aaag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yp8i6EoMEvTtaSt4Jv0hcYlB7SnUqvBODHFvvD+TDAw=; b=zil2w/4nUJ4VcwZLQ0SpFSAjFqpydNozNrkta5Quv8hR6MOdWkq8TqZo7X9K1NC2xj Yh45mWHhXMxl0wl/WNN01T5AhCDTxaT822qytLEp47BtpZZfXllTRcwxLo/Pqv7YTC7y uq557yVnU6mGNxFYcDtfgPQhrzKVg84OXzhZ59dgZh4t05J9aVE3UzLhFcWZub3/44p5 +e/qg9Eo8jW6oERfSUXHkCFUYwKWo5a5rSNxmnfwFgsQhKkhHoFj+ISEBgv/+nsDL9t9 TTPpUrZPDkvV9704slJLGDlL1MgVyhHD30XlSKCiBVYAvLA10q6pxIXkBcK1/U43TavJ 34fw== X-Gm-Message-State: AO0yUKXxIZQb/AL9DzYY7mj8uS5IDDLiIyElJMtrENfeHrL2CsHn9AI0 NWfA3mrLbZ4PhPxyMkTefzIIjyozq68= X-Google-Smtp-Source: AK7set9C5YXuR5+cbd6XF5WxsOwuRgWT+TYDYZl0vGOWqToN4okRJ8bd6mLn3V1ayJrISDKkvvlx/A== X-Received: by 2002:a17:907:97d5:b0:8eb:d3a5:b9f0 with SMTP id js21-20020a17090797d500b008ebd3a5b9f0mr9494611ejc.67.1677249932930; Fri, 24 Feb 2023 06:45:32 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id kq9-20020a170906abc900b008d9c518a318sm5730855ejb.142.2023.02.24.06.45.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 06:45:32 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83bkljnpck.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 15:51:39 +0200") 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> Date: Fri, 24 Feb 2023 15:45:30 +0100 Message-ID: <874jrb9l6d.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 15:51, Eli Zaretskii wrote: >> > > You can't even send or receive a message through the JSONRPC channel if >> > > it's not valid UTF-8 >> >> > That's because we _decided_ to behave like that. A decision that is >> > not carved in stone. >> >> At least or LSP, it seems it must be UTF-8: > > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 09:54:58 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 14:54:58 +0000 Received: from localhost ([127.0.0.1]:36495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZTO-0008J7-GB for submit@debbugs.gnu.org; Fri, 24 Feb 2023 09:54:58 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:39462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZTK-0008IQ-4E for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 09:54:54 -0500 Received: by mail-ed1-f51.google.com with SMTP id f13so55215184edz.6 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 06:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=q9wPH8jeIaJRLe37dWAmryzJBaJyM854NBDPb8cnao8=; b=G7TpXKWOwsCtOTw35GtgA4BLqyYcogjPhu9Cm81chePi7PuMfTiTv62sJEmoUg/IbV UM8jROxlPYR8epEClxCP/gJTTJue/q9Q99QWl7SmYPRLBSTO8OhpPajNC6RzqXLwuPaB OrUkqm+QujeQ1B1OCslYyJASipvu+pqdnzyTafDe0/3x+TmWPrv1FnSOtdCXiYWrPkcl zN4HyeIvsBW8dY5uNCqAdvRopAyqCr7BjiIiqARwzShFFoIZvbF3ULi0LLqSm3WPZdLs Y45qCyiq2HeLZBwsOw6sTuVkoRuwkcjAjPJ1ZAYznaXmmaw0YPHE+qXcuypTbpkT0CA7 sRYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=q9wPH8jeIaJRLe37dWAmryzJBaJyM854NBDPb8cnao8=; b=EffmLnArA60MHzJ+F/n296c8bDsp+tPRzxKRrbdtoKdap6serfrgevjcvMIXWRjCvl /1xKjLhvW4+e/I6/FULsbU+6ueY/eh3iyI97KTE5bV/6DsszleXWFai285Gp4ZWYTp/1 pay/mSRjBWbM3g5FOPnxG2uPukbsjGABbhflpxmubQr3HLTNSLuojC9PY+jbgqY6wmOe RqY1QKnDRk99/x9LYPq11i3jKCMnRvsPs3aFpTRChLaOMx1pPZ6Wx0XQYSSyQMKAP+SN jHSeiVavhjEH+vsBQWNc1pn5hPKwBWUZIlr+U4Y6FKAuRO+dehwEWyb4WGz4TIiZmRbT Y6cQ== X-Gm-Message-State: AO0yUKUs1poHyJkXnV+7gEjDY5cwJ0DDNvqYHDxE5FHbE2c6U7iXmzum Pw5jCOMqeWxj9q6eM7PxNOzHBsH5Kd0= X-Google-Smtp-Source: AK7set8VsrhZK8lr79KEP4bkhmnAoC4fQf72GDOdRFkCjc5z0RWXKzTa5UAyJZfwnUVGIwTNznLwGA== X-Received: by 2002:a17:906:4784:b0:8f1:da18:c6ca with SMTP id cw4-20020a170906478400b008f1da18c6camr5906953ejc.3.1677250487939; Fri, 24 Feb 2023 06:54:47 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id bi8-20020a170906a24800b008e8e975e185sm2991573ejb.32.2023.02.24.06.54.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 06:54:47 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 24 Feb 2023 13:45:23 +0000") 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> Date: Fri, 24 Feb 2023 15:54:46 +0100 Message-ID: <87zg93866h.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 13:45, Jo=C3=A3o T=C3=A1vora wrote: > I don't see how this is relevant to the code-point counting problem here, > though. The relevance is in how the offset-counting function should proceed when the buffer is not UTF-8 encodable: - My patch has a garbage-in garbage-out behavior. - Eli made a suggestion he deems more correct, but is more expensive. Since JSON must be UTF-8 encoded for data exchange purposes, I don't see the benefit, and in fact I consider this option just a different choice of garbage-in garbage-out behavior. - A third option is to make the function throw an error. However, if the buffer is not UTF-8 encodable, we already get an error from json-serialize, because it doesn't let you generate invalid JSON: (progn (insert ?" (max-char) ?") (json-serialize (buffer-substring-no-properties (pos-bol) (pos-eol)))) =E2=87=92 Debugger entered--Lisp error: (wrong-type-argument utf-8-str= ing-p " \"\377\"") From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 10:19:29 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 15:19:29 +0000 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 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 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==; 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 Date: Fri, 24 Feb 2023 17:19:20 +0200 Message-Id: <834jrbnlaf.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <874jrb9l6d.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 15:45:30 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 10:23:34 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 15:23:34 +0000 Received: from localhost ([127.0.0.1]:37937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZv4-0000zl-9c for submit@debbugs.gnu.org; Fri, 24 Feb 2023 10:23:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60312) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVZv2-0000zY-BH for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 10:23:32 -0500 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 1pVZux-0005mA-18; Fri, 24 Feb 2023 10:23:27 -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=GzkUTW5EfyxQt/nSSMSoBo5lxF5z0zveggbZ85cmzSM=; b=YDkO3c+9jZ3VXgJKBt4a 7A+qJq2A93zz9NBSPgOgMOBXHNb7Nc2CMjuw6jIL2oZe8yvH9x4KXW+PVjK9qDNDm6U9mtQWDp9t8 PrTu5P0/fMZYCyzXv9GebgIJwd2kZq8y8LiLeRrLR7GeVMlQeEzoX9JSXJzghkRdL9gJkcR6EeS6k qRNkBw8ka9QrL5idIAsQlPfJanuhHA4x/IwdvWHm4SS1yYRag+/YqlqhxdTi56sViEPkzgcQGPrRx GJ1MCmdptmcelqaJFM1Rt1RMtC3ptWWh25+Pdpu53TihI2k8Zqs7VtJ03k5bVBaIc5hAx6EdByEUp TYRiA+ruT8nxSw==; 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 1pVZuw-000635-Gq; Fri, 24 Feb 2023 10:23:26 -0500 Date: Fri, 24 Feb 2023 17:23:25 +0200 Message-Id: <83356vnl3m.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87zg93866h.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 15:54:46 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> <87zg93866h.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 15:54:46 +0100 > > On Fri, 24 Feb 2023 at 13:45, João Távora wrote: > > > I don't see how this is relevant to the code-point counting problem here, > > though. > > The relevance is in how the offset-counting function should proceed when > the buffer is not UTF-8 encodable: > > - My patch has a garbage-in garbage-out behavior. > > - Eli made a suggestion he deems more correct, but is more expensive. It is not more expensive. The underlying functions we call are already capable of producing replacements instead of characters that cannot be encoded in UTF-8. We just don't use those capabilities in json.c because some of us had strong feelings about signaling an error in these situations. > Since JSON must be UTF-8 encoded for data exchange purposes, I don't > see the benefit, and in fact I consider this option just a different > choice of garbage-in garbage-out behavior. The benefit could be that Emacs is more lenient in face of such situations, and doesn't signal errors from very low-level code which has no idea about the context. > - A third option is to make the function throw an error. However, if > the buffer is not UTF-8 encodable, we already get an error from > json-serialize, because it doesn't let you generate invalid JSON: > > (progn > (insert ?" (max-char) ?") > (json-serialize (buffer-substring-no-properties (pos-bol) > (pos-eol)))) > > ⇒ Debugger entered--Lisp error: (wrong-type-argument utf-8-string-p " \"\377\"") What if json-serialize stops signaling an error at some point, and instead uses the replacement mechanism I mentioned above? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 10:52:37 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 15:52:37 +0000 Received: from localhost ([127.0.0.1]:37983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaNB-0001ts-1I for submit@debbugs.gnu.org; Fri, 24 Feb 2023 10:52:37 -0500 Received: from mail-ed1-f52.google.com ([209.85.208.52]:39424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaN9-0001ta-FS for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 10:52:35 -0500 Received: by mail-ed1-f52.google.com with SMTP id f13so55933004edz.6 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 07:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=x1l38+fHB+ThwJus7hTk//wGulvYUHLWPWsmoFI3NJ4=; b=ZzGsW5zPr6T9hGHfC67GEWmuWMgiE0r5zMTDDMQXZAreNVJY5ve0y2sSNziCDiTgT/ 1PJ+s9rC15VqN3wd58zp0HcK12pMYInC8coRNst0LqPhHem4Q6YPkYVflaOlGK1T+3k3 dPn/G9WJab3lP02TZXi9pi6NuVJDHnr1S9gwSzWbRg/IU9K+7sjdUJN7kt4NbiPJYa0q x4bPbcLcY0Df1Fmt1fsesydWbn3xp9T/rbyWPfKjk8Yk1P9G+srSjM/03JM2SsWqHWg6 NwbTV9Ti/yzcEamg0eqDBDrgvYplzr0H0yo/VEYBYZwIysnviRmuQH6sCZsjVobjmFGv htEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=x1l38+fHB+ThwJus7hTk//wGulvYUHLWPWsmoFI3NJ4=; b=JmKKSnT84lXnYMxrFHATFHoWyEoyb3Q4niF5+do7mDS95EdevudTKnr8OVITi8txgw QU0t3knegt9vHZ47l9ajvEyaiFMbqv6uqllKx0fazg0WxpJjC8min58xdlDmthpvqF3A tALckDRW6nbxQAb0W/CJnzgyZB/TJtmcM51f486QE1dOY96HHrO1DiyWNKR0owilhhJt U2iMf2E95mum8C3iL+OWB6Q1HbhMEIFIhD4ybfmB5jKyHKYHCXojGb45ShkjyGznohcS fn8tx7beY3FMLatOJmPLa+KBkdaHdMtav3fBudzth6Xe9zRJFpdncaOLk/WHaryhmTb3 k/OA== X-Gm-Message-State: AO0yUKUX0WByHxe4oAAuX0pIr6DEIPF1IIKWtY1fS5I4fBn3pwSK/zsW iiXK5/rBUBs0Um30X1Sl0eh6874C8Ic= X-Google-Smtp-Source: AK7set/iPNCerDzJHZ05pk/TwRBteml8oUrG+eoVXgVrczrbrOSouSbGFmU4BfVlWPfX1zvq5dgQsQ== X-Received: by 2002:a17:906:f88c:b0:8b2:8857:5963 with SMTP id lg12-20020a170906f88c00b008b288575963mr25524727ejb.8.1677253949126; Fri, 24 Feb 2023 07:52:29 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id g21-20020a170906199500b008e34bcd7940sm4065879ejd.132.2023.02.24.07.52.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 07:52:28 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <834jrbnlaf.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 17:19:20 +0200") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> Date: Fri, 24 Feb 2023 16:52:27 +0100 Message-ID: <87v8jr83ic.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 17:19, Eli Zaretskii wrote: > 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? You made yourself clear the first time. What I don't understand is, why do you think this is a good idea, because in my view it clearly isn't. So suppose we lie about the buffer content and say it's "abcde xyz". Then the server sends a diagnostic saying "found unexpected space character at column 6". What sense does it make to the user? Even worse, imagine we then request instructions to reformat the buffer. Suppose that the replacement "abcde xyz" -> "abcde\nxyz" is meaningful in our language but the replacement "abcde\201xyz" -> "abcde\nxyz" is dangerous. Do we want to get into this kind of trouble? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 10:57:08 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 15:57:08 +0000 Received: from localhost ([127.0.0.1]:37991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaRX-000225-W2 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 10:57:08 -0500 Received: from mail-ed1-f48.google.com ([209.85.208.48]:36617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaRV-00021U-JX for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 10:57:06 -0500 Received: by mail-ed1-f48.google.com with SMTP id da10so57766384edb.3 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 07:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=R2qfY1l3WdhnqKbyHf2IQS/02oDcCk/aLSbjTGoxum8=; b=kE6n2W5dYZF2wz+SiNeGioexum+lbHJouFwv1QvCFRDLp0537voyVbDYeWZrRUENvA WXaAc37gUgxeL2sCDJwBXryyig97TrmxZ5KgEwlD/XpE3XQjDqcgwadU+sTV7fAO1ql0 6jmBRlro7U0bCgL+mRPwhjSVo/4Kyka8qHPZQ0mOXDIydekGCXjgYA2LFfxFZhi6u+RO NmD1xqB2xKvc2zT7S4EmNzh35tKCfBYDzr27FsBeptnGKKhm3wWx0pvy3T3IMELFQg5I K9zD+3JSqQc/T27id5Cwv7s3qHiymkpbZGmol7vDhnEEs8Yjp3hTeKuagOSXV0ednke3 salQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=R2qfY1l3WdhnqKbyHf2IQS/02oDcCk/aLSbjTGoxum8=; b=fTajHvKQ3DH0/uCik/ZXIvuKGvQKyFRW7VgasYu9ms1PtigKBjH5xEcKtLtG4RtyQ5 ZocHxcpSBYvCakHMJDQPAAdSaQCf/nSvJrHRoO+sL+O46bcN2BY6zYFXqxiLjSjobyHS sX3HtWHPyHSeVedbRB2w3Ql4dUYF2bWSo9QrOUtQN0JLSWS82HVhWiGChYsI6Hi5PWsp Fqu6YZi5NOt5bmI8fMjPQFYJyB5t2NAOkmkITdooI3rbWTuLeIggoQ6oWK6EZtjq/RV5 c8CNfW787/O3sO81Fso2HYi0NdY1RDvhChqGiczgS6G3UgyrwQlnaOg2YecKGeJDJf0w y2xg== X-Gm-Message-State: AO0yUKUDdrEDhACM/V1ey+dwcgh2Im0rrraIKxGgZtTuiRKd0D6c+lQE 1ObLTb8cC1zXWixo0WFy71YycbKL/rQ= X-Google-Smtp-Source: AK7set8h5J4BoZmaQfgqMrer94EA3WCSsJFkdrERY1cDT7wQKUsOvbJw7+ONE5WtQpWZbysFQim9NA== X-Received: by 2002:aa7:da97:0:b0:4aa:a0ed:e373 with SMTP id q23-20020aa7da97000000b004aaa0ede373mr13388401eds.7.1677254219496; Fri, 24 Feb 2023 07:56:59 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id by17-20020a0564021b1100b004aef48a8af7sm5803257edb.50.2023.02.24.07.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 07:56:58 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83356vnl3m.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 17:23:25 +0200") References: <87a614g628.fsf@gmail.com> <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> <87zg93866h.fsf@gmail.com> <83356vnl3m.fsf@gnu.org> Date: Fri, 24 Feb 2023 16:56:57 +0100 Message-ID: <87r0uf83au.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 17:23, Eli Zaretskii wrote: > It is not more expensive. The underlying functions we call are > already capable of producing replacements instead of characters that > cannot be encoded in UTF-8. We just don't use those capabilities in > json.c because some of us had strong feelings about signaling an error > in these situations. I didn't track down byte-to-position and position-bytes in the C code. So you are saying they're as expensive as encode-coding-string? If (and only if) this is the case, then I take back my point :-). > What if json-serialize stops signaling an error at some point, and > instead uses the replacement mechanism I mentioned above? In the other message I explained why I think this is exactly what we should _not_ do. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 11:02:03 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 16:02:03 +0000 Received: from localhost ([127.0.0.1]:38001 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaWI-0002Cc-W7 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 11:02:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:37412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVaWG-0002C9-SP for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 11:02:01 -0500 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 1pVaWB-0008W3-HE; Fri, 24 Feb 2023 11:01:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=AlopVx0MXVQVyyz7du8LF1NMOGsoq9df69I1T39Nun4=; b=eXzUv2SFAG+y encQvkgvSX3sqoycfn9oTZ6u+LgMI92iApgBn2AZI5pmupzmenBPGv00pIbFfLpZsZukwS2c+2p0Q dvlnW0jz3+ydjpZzh+sd2ONtEJ3hjwFGgkGKV3v0WV272k9XVyzQ35fW25LMnHGoMMuA+GaGjK9Ed 4n7HAuR0+9Kh1vHJze+z4FHFRK9DqPRplTK+VvF8XL30kZWlP6Txo4dcmTaPVOCaPRTuG4skt5LCx hf9zEUovwlm+U+twYmuZglEenAKC1yhyBKhKoEEQH7DZgeJ1RQdHVzPlHX2lnsrJw+f5E+jzR7Pzw rcYi8F4CYvvtZ7EsxshAbQ==; 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 1pVaWA-00073Y-P3; Fri, 24 Feb 2023 11:01:55 -0500 Date: Fri, 24 Feb 2023 18:01:55 +0200 Message-Id: <83v8jrm4r0.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87v8jr83ic.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 16:52:27 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 16:52:27 +0100 > > > 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? > > You made yourself clear the first time. What I don't understand is, why > do you think this is a good idea, because in my view it clearly isn't. > > So suppose we lie about the buffer content and say it's "abcde xyz". > Then the server sends a diagnostic saying "found unexpected space > character at column 6". What sense does it make to the user? How can that happen? Raw bytes can be in comments and in strings, and basically nowhere else in a program. How would the server decide that a space is not valid in these contexts? > Even worse, imagine we then request instructions to reformat the buffer. > Suppose that the replacement "abcde xyz" -> "abcde\nxyz" is meaningful > in our language but the replacement "abcde\201xyz" -> "abcde\nxyz" is > dangerous. Do we want to get into this kind of trouble? "Dangerous" in what way? And your objections/fears seem to circle around the special traits of the SPC character, so what if instead of SPC we use U+FFFD? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 11:34:53 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 16:34:53 +0000 Received: from localhost ([127.0.0.1]:38070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVb24-00032s-T2 for submit@debbugs.gnu.org; Fri, 24 Feb 2023 11:34:53 -0500 Received: from mail-oo1-f47.google.com ([209.85.161.47]:43661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVb23-00032f-3e for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 11:34:51 -0500 Received: by mail-oo1-f47.google.com with SMTP id a23-20020a4ad5d7000000b005250867d3d9so1186779oot.10 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 08:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677256485; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XrvzZkyAN9f0tTRsHNKIVvDroBfqyPcM8NVVlxWqxDc=; b=BJi1gghpVht2Afh4C5YZ/w2dIFCPvmLgJd97IO/QzZqqIDmf/o3TMdiY499fgVrkdH jSFzSvB6UY3C+dwxogtsIB0/TfQKy2yOasCczZYjzvCq63aYmpdIL5/Jl7efYjRhuQNN pPyiPgaRaqikAZRhtf5S/l6WFgNv/04IrOI+h272a1ktoKrfnby88lvCQ6Od14zZp79c pRR9xq6RdG871By0sp2WFpp73ARy+yGH+iEdaStVA9z7QhFf0okiquWydYzo4Jmip5Sk y3ju+FRgM9jtXgkF3hMQ0n9xscQF9srVYBay+tx5ISHSn2L2/sQbIcTduGTwXxkWMTfN cPeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677256485; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=XrvzZkyAN9f0tTRsHNKIVvDroBfqyPcM8NVVlxWqxDc=; b=qfLaQbksqFvU9mBuHz3bl9hE++aLKzKauGbq6hayMlv4825ZPA8egcJ33Ywr7Bs6H5 SowmXE694rr4d8Naty+xt03krsFUmmk1+tSyXJ8ZfgMmv4PzDu/XdW2YqRm4N1wuJdx6 oe8Gi6bOb3ASbkpj8Uf6RgN1RDI/cJ0DBu/wrwKOpjID2aIQu+UTEZtQzxy/TYDj+Z+v XlF2xTg87dW92XB6zWbler7OYW8CVZoigU3VOq0UeGipbJS9Mr3+6DDBsyy1BZkzNO3H XLvY/6SnH2JwL2ojiw6wbQMyc3B+nEKiXzGh5aq//ZhWDZphYwcscLO8Sbw0W9E1By4i p3Hw== X-Gm-Message-State: AO0yUKUEMFJS/Ee2N5SUorTrQHpxPDOX3Ud68z/7rxB/Uvu7ll11I7R2 SuN4AOWPje+HwYIZo3zfsu6y0j3MTkMUtmOYJC0= X-Google-Smtp-Source: AK7set+70UBNn8LyjYjdQLN7mAAwrA415O5S2C21t2vm4tCXUJvB8eFCPdyIcQleFJHd7j/aT7IDyduSWmT7zrh8Eos= X-Received: by 2002:a4a:304a:0:b0:525:499e:ce2f with SMTP id z10-20020a4a304a000000b00525499ece2fmr13109ooz.1.1677256485311; Fri, 24 Feb 2023 08:34:45 -0800 (PST) MIME-Version: 1.0 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> <87zg93866h.fsf@gmail.com> In-Reply-To: <87zg93866h.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 16:34:34 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 2:54 PM Augusto Stoffel wrote= : > > On Fri, 24 Feb 2023 at 13:45, Jo=C3=A3o T=C3=A1vora wrote: > > > I don't see how this is relevant to the code-point counting problem her= e, > > though. > > The relevance is in how the offset-counting function should proceed when > the buffer is not UTF-8 encodable. OK but this is just for the forthcoming utf-8 pair of functions eglot--move-to-linepos-utf8 and eglot--current-linepos-utf8, right? It doesn't affect the current utf16 and utf32 (move by codepoint) pairs of functions, does it? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 11:39:21 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 16:39:21 +0000 Received: from localhost ([127.0.0.1]:38088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVb6P-0003Ah-Fh for submit@debbugs.gnu.org; Fri, 24 Feb 2023 11:39:21 -0500 Received: from mail-ed1-f51.google.com ([209.85.208.51]:36518) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVb6N-0003AW-Qu for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 11:39:20 -0500 Received: by mail-ed1-f51.google.com with SMTP id da10so58289677edb.3 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 08:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=yoEhUI8STSrMwOpD1IDt2KLrwLn2umbBH618jVFvhmc=; b=StsJ+Dpmw4hpGK4JScxC7pfMC3EBwSG2neEeULvL5mwMY32TBIwGzuJfvdyIc/JgSQ 85j5j+p/OYZovBMLUowYa9Y0hVeuW4P4FtpYtThkFGtptyBrPblUE8mi2ld70A7cWIw1 so/W4VLNJe/6t1qNSICkcyySNee5GqBkDikHiRK12mHrlxbTcWWqm+BWf2Y0b+OrW7V4 u2tQyWCnbjoKoA1Rk+Rf7xvVpcLViAaka0X+QSk8+2LllRbVAqTgATNYss8aUD2btOG3 rZADwg+f3Qr07Kp0tyKbsArFT4jQjVs4kuZqR2wt6XrPhBRQAFCiqm7eVM6k9ZyU48Aj sk2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yoEhUI8STSrMwOpD1IDt2KLrwLn2umbBH618jVFvhmc=; b=kCaEZV+nQXZFUjGU1pYO196NBKM4eIhIl0SX1SkF2LO1rSQScZmGcbCby3/CBHppA4 Y0JE9Y7k+bJN7ovCsbe5gZK02GXyPW+DmdFQgwiZEINvifF0Dv9igIOAggsjIocKn9JL MZVfVGbvHml3TAZeuIKsfz4kW0x9fB+YBJHM43SDC018AHNksEOGaertatTtDlxqdKCu oB94clKsGj+fHpupDOv5RNe1IpBHsOrc00Uh944sv+GeQMk7Xc8MOUV0CQaKIDqt5AEr bKz56qxtPUndnGAys9Is1QMNWVdLqIzAsIbLG4ELziySFHV6gY+0+AeN9HjrYyp2gL9U 7vvQ== X-Gm-Message-State: AO0yUKWPIYRuEknl0VGG+xfmDe7nelvZxZJgXemyJXRX/ttD/sXUdYdP Z4vKVH7Cg0wMtMLyMPnEm97DueDPdWo= X-Google-Smtp-Source: AK7set9ZYRhOd8RAaQ0EGY3zZ85HKc9zRLv4FOIyKJm/KPCx6xJxFR91mD1IbsCzWiodN3r4Zv5H8A== X-Received: by 2002:a17:906:ecf9:b0:8c0:6422:e0c2 with SMTP id qt25-20020a170906ecf900b008c06422e0c2mr18816297ejb.22.1677256753536; Fri, 24 Feb 2023 08:39:13 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id me19-20020a170906aed300b008b17662e1f7sm10470607ejb.53.2023.02.24.08.39.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 08:39:12 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83v8jrm4r0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 18:01:55 +0200") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> Date: Fri, 24 Feb 2023 17:39:11 +0100 Message-ID: <87k00781cg.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 18:01, Eli Zaretskii wrote: >> From: Augusto Stoffel >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org >> Date: Fri, 24 Feb 2023 16:52:27 +0100 >> >> > 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? >> >> You made yourself clear the first time. What I don't understand is, why >> do you think this is a good idea, because in my view it clearly isn't. >> >> So suppose we lie about the buffer content and say it's "abcde xyz". >> Then the server sends a diagnostic saying "found unexpected space >> character at column 6". What sense does it make to the user? > > How can that happen? Raw bytes can be in comments and in strings, and > basically nowhere else in a program. How would the server decide that > a space is not valid in these contexts? > >> Even worse, imagine we then request instructions to reformat the buffer. >> Suppose that the replacement "abcde xyz" -> "abcde\nxyz" is meaningful >> in our language but the replacement "abcde\201xyz" -> "abcde\nxyz" is >> dangerous. Do we want to get into this kind of trouble? > > "Dangerous" in what way? If someone thinks this is a good and useful feature, of course they could work on it. I think the current behavior (json-serialize error) is better because it sticks to the letter of the specs. My point of view is very straightforward: you can have language servers; you can have arbitrary bytes in your files and buffers; but you can't always have both. But I'm sure I've already communicated this, sorry for the repetition. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 12:02:37 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 17:02:37 +0000 Received: from localhost ([127.0.0.1]:38131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbSu-0003s6-VQ for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:02:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbSt-0003rt-6B for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 12:02:35 -0500 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 1pVbSn-0007SC-T7; Fri, 24 Feb 2023 12:02:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=nM6aPnpfk1xeN4HwuBQN8wEd2jeIQKcpt8BJphRxFjQ=; b=d/4yCFk37yd0 CgfS6Cw1YiBGjgL3Tj+pj4C9q1mEyXnj4Ebw0kBvV1g7Mq3dQjPQPw2x/27r5zRK963tkjkE33wfo 1kQWJZr1w/G/EgT/m6YHabugm9FJ11QRjrNMxKVIC/GR8i0MkFENBCnvnD3DKeWJ+EztX6MQuRmUi ulcdfMf7HVdoyByxBPK3MHkaEfjHpULrpVqYJLLX2+8PFdRR5G6HSW0zaBQ8+Re4s0DwkB+wUJ/lR L7fCPJT0WyMBbYkizDWf6csDZ7Gk8Z56KnV4u0zZElAeG0YuGN9K056tjQm7O3Gce1sOrlvzh9YdN GL0IFEAFw5BYVR4vmEFbrw==; 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 1pVbSU-0008Vi-O6; Fri, 24 Feb 2023 12:02:29 -0500 Date: Fri, 24 Feb 2023 19:02:08 +0200 Message-Id: <83ttzbm1yn.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87r0uf83au.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 16:56:57 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <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> <87zg93866h.fsf@gmail.com> <83356vnl3m.fsf@gnu.org> <87r0uf83au.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 16:56:57 +0100 > > On Fri, 24 Feb 2023 at 17:23, Eli Zaretskii wrote: > > > It is not more expensive. The underlying functions we call are > > already capable of producing replacements instead of characters that > > cannot be encoded in UTF-8. We just don't use those capabilities in > > json.c because some of us had strong feelings about signaling an error > > in these situations. > > I didn't track down byte-to-position and position-bytes in the C code. > So you are saying they're as expensive as encode-coding-string? If (and > only if) this is the case, then I take back my point :-). I didn't mean those functions, I meant the functions used by json.c to encode strings. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 12:06:35 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 17:06:35 +0000 Received: from localhost ([127.0.0.1]:38144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbWk-0003zG-RH for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:06:35 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbWj-0003z4-7D for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 12:06:33 -0500 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 1pVbWd-0008Hb-D2; Fri, 24 Feb 2023 12:06:27 -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=or1WbjQzRCLGg7AeoDcJR8c93ksxg9IdLJ2C/gVpdro=; b=b1B1BAZiWQrpd4jt8UyO hVjhmTkgyTNqGYCOPWNyjq19R4573VxXOeDum/+YxxWI1GPwCtOUtU7hMYQaoEfFGdaMRMVxVj3cM MA+MLVjTvCpS+OUez61GU0h5Oh/AuqD1/+zi7G5nVc398x/yiZ+ImszLoaq4Ap6JptRlR/JFSM2/x N1L+4IzvLzg1gh6KfvfwSk/DqfOgk9xcQK7gbraOsQrD+HbkumaoSCHoTta00GZCWxqOaB2prlW06 8Ji/+9NjtYBJ6ighKBHuHGIe5Fr1UnklSeoKEIhtG9dVz7kzJGPOCzcivebcurRVHx3Kj7iDzDcBe //o9O3din3HBWw==; 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 1pVbWb-00085p-Qd; Fri, 24 Feb 2023 12:06:26 -0500 Date: Fri, 24 Feb 2023 19:06:25 +0200 Message-Id: <83r0ufm1ri.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 16:34:34 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability 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> <87zg93866h.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 24 Feb 2023 16:34:34 +0000 > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > > On Fri, Feb 24, 2023 at 2:54 PM Augusto Stoffel wrote: > > > > On Fri, 24 Feb 2023 at 13:45, João Távora wrote: > > > > > I don't see how this is relevant to the code-point counting problem here, > > > though. > > > > The relevance is in how the offset-counting function should proceed when > > the buffer is not UTF-8 encodable. > > OK but this is just for the forthcoming utf-8 pair of functions > eglot--move-to-linepos-utf8 and eglot--current-linepos-utf8, right? Yes. > It doesn't affect the current utf16 and utf32 (move by codepoint) > pairs of functions, does it? No, it doesn't. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 12:07:55 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 17:07:55 +0000 Received: from localhost ([127.0.0.1]:38155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbY3-00041a-9u for submit@debbugs.gnu.org; Fri, 24 Feb 2023 12:07:55 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVbY1-00041J-5l for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 12:07:53 -0500 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 1pVbXv-0000A5-Uv; Fri, 24 Feb 2023 12:07:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kjRUfC+rIOA9BthfFzuJyrV68oT3Dmd1cESB5CmBVIM=; b=T1Cbi1mtbWgz Hhctk5pmbV6AHKwkpUi9WdMFTCpYqRki5hB4R5obTlLrW77wEfMp6ucTxMAQtVbHJip821C1xCHGp hnjiM118bg4O3osj6v0JhOEQ1ealRgM4F/0xYbm7Qdp1GNt5FuJJ1DMnEie8sXRVC8HysWZMc52jU ZwYuatdxngOxGfECviki8NB+hRrMD8N7wynMyCdbGbIiOqxlXRG20bjf+L31yMiHz45NNQtaNFzkJ 6R+nxuU/pCKmeNnxRJrahK7Bop4DSK17E6VnytaQLrX/Cg+X40hh1WawMc53q04WazfbBIQSZkgzu ByeXsaQJXXZOuqUWyCfzYw==; 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 1pVbXv-0008N2-Df; Fri, 24 Feb 2023 12:07:47 -0500 Date: Fri, 24 Feb 2023 19:07:47 +0200 Message-Id: <83pm9zm1p8.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87k00781cg.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 17:39:11 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87k00781cg.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 17:39:11 +0100 > > If someone thinks this is a good and useful feature, of course they > could work on it. I think the current behavior (json-serialize error) > is better because it sticks to the letter of the specs. The spec doesn't tell us to signal an error, it tells us not to send invalid UTF-8. Which under my proposal we will still adhere to. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 13:08:26 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 18:08:27 +0000 Received: from localhost ([127.0.0.1]:38222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVcUc-0005jD-FK for submit@debbugs.gnu.org; Fri, 24 Feb 2023 13:08:26 -0500 Received: from mail-ed1-f49.google.com ([209.85.208.49]:35641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVcUZ-0005iy-PJ for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 13:08:24 -0500 Received: by mail-ed1-f49.google.com with SMTP id ee7so700422edb.2 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 10:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=9SuM9iC3OKkKk4vHI8ZKiWnePZiw2pohd3QbEa+XgXg=; b=jVgyq+olT0KKFqkVBc1t8xDZbwwI/RSWIE0SvId+GXsoMtuYgdWYDV+L9MbhObWQ96 gA83VRfXy4vKN9bK1pWeITkCnzEpe8Ynazf4WS2LY707kIT7PfREDFqGqB5eYLMwBDNa LGVhVxlNSUsgeHEmqmARkKP6AMALlgWbHNo3tAnJDH0hH2P7p6QB/0Xxdn/wUNBIcmFW rMQzQm9A9A8KNswxGZDGMMYtvdjjTmnevmxHpQWygNtlG8pSvrHnFyARx4IrFhbTy0aQ j2K0ZSr3y+f3S2ptUZaI7fzhWxEm1i2GLqK9cEbt62IV/+ipC1YODfOWwUTwN96vZ33y DdAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9SuM9iC3OKkKk4vHI8ZKiWnePZiw2pohd3QbEa+XgXg=; b=Ajf+xxDClklbX6fGzpnLQA1RPuBGoeEiOZ/7dA8sbOwKxCAmFBUuu0KnqTy19/PycZ +F4KLvAtNbX0AL8hYb5BeYrb7rqr0JCU+ePMOk2dDVfI9U5aZxyUvqaQMt8IM+1Eyo7V /OAh19XMZH8bAz37nYjMc0w/tL2/Ovj7yu34H2WJGqMYwVuLrHUNpKy76PoopNS90OpU JRlSFvF8hMNUYOqRVa5hXIbXBHgfksantevRthzFrXedUiW97Okq0tOwfcyOOKHI6iDg l60srFqXxz8jbbZFj321GPHoupybgeALb+Y7HBtHcgSbqgA7COIZ6kkY9VwqMWVzhFTS rOTA== X-Gm-Message-State: AO0yUKUaeV1wg+Xt43JrwkqAMiwf8zciyB0e4gl7PoAPkgbrbKryYZBt h+HHK6K2xd9wi/k0eI+hoQqRETWev7o= X-Google-Smtp-Source: AK7set9ScM6TNVfYRfu8DnlMozsh9edI4xDNThyFoqvPMCroiWQNaREdBvQAPEIuXttIfNjaGWWFhA== X-Received: by 2002:a17:907:970b:b0:8ee:72c0:6ba3 with SMTP id jg11-20020a170907970b00b008ee72c06ba3mr9063295ejc.7.1677262097373; Fri, 24 Feb 2023 10:08:17 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id w5-20020a1709064a0500b008bbc4f3bceesm8696324eju.118.2023.02.24.10.08.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Feb 2023 10:08:16 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83v8jrm4r0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 24 Feb 2023 18:01:55 +0200") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> Date: Fri, 24 Feb 2023 19:08:14 +0100 Message-ID: <87fsav7x81.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain I've attached a minimal functioning version of the patch. I would prefer to merge this and do all possible refinements discussed here at a later stage. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Eglot-support-positionEncoding-LSP-capability.patch >From 9b6794a729ac27b02472d68f849066c3a10297d4 Mon Sep 17 00:00:00 2001 From: Augusto Stoffel Date: Thu, 23 Feb 2023 08:55:58 +0100 Subject: [PATCH] Eglot: support positionEncoding LSP capability * lisp/progmodes/eglot.el(eglot-client-capabilities): Announce the new capability. (eglot-bytewise-column, eglot-move-to-bytewise-column): New functions. (eglot--managed-mode): Set 'eglot-current-column-function' and 'eglot-move-to-bytewise-column' appropriately. --- lisp/progmodes/eglot.el | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index b569c03e8c2..9a4d5733d0b 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -816,6 +816,9 @@ eglot-client-capabilities `(:valueSet [,@(mapcar #'car eglot--tag-faces)]))) + :general + (list + :positionEncodings ["utf-32" "utf-8" "utf-16"]) :experimental eglot--{}))) (cl-defgeneric eglot-workspace-folders (server) @@ -1441,6 +1444,10 @@ eglot--warn (defun eglot-current-column () (- (point) (line-beginning-position))) +(defun eglot-bytewise-column () + "Calculate current column using the LSP `utf-8' criterion." + (- (position-bytes (point)) (position-bytes (line-beginning-position)))) + (defvar eglot-current-column-function #'eglot-lsp-abiding-column "Function to calculate the current column. @@ -1505,6 +1512,12 @@ eglot-move-to-lsp-abiding-column (forward-char (/ (if (> diff 0) (1+ diff) (1- diff)) 2)) (end-of-buffer (cl-return eob-err)))))) +(defun eglot-move-to-bytewise-column (column) + "Move to COLUMN as computed using the LSP `utf-8' criterion." + (goto-char (min (byte-to-position + (+ (position-bytes (line-beginning-position)) column)) + (line-end-position)))) + (defun eglot--lsp-position-to-point (pos-plist &optional marker) "Convert LSP position POS-PLIST to Emacs point. If optional MARKER, return a marker instead" @@ -1758,6 +1771,14 @@ eglot--managed-mode :init-value nil :lighter nil :keymap eglot-mode-map (cond (eglot--managed-mode + (pcase (plist-get (eglot--capabilities (eglot-current-server)) + :positionEncoding) + ("utf-32" + (eglot--setq-saving eglot-current-column-function #'eglot-current-column) + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-column)) + ("utf-8" + (eglot--setq-saving eglot-current-column-function #'eglot-bytewise-column) + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-bytewise-column))) (add-hook 'after-change-functions 'eglot--after-change nil t) (add-hook 'before-change-functions 'eglot--before-change nil t) (add-hook 'kill-buffer-hook #'eglot--managed-mode-off nil t) -- 2.39.2 --=-=-= Content-Type: text/plain For the 2 new functions I've followed current naming scheme, replacing "lsp-abiding" by "bytewise". We can then get rid of all the suboptimal nomenclature (lsp-abiding, column, bytewise) in one go at a later stage. I also didn't attempt to make 'eglot-move-to-bytewise-column' and 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' throws an error. I think it's clear that Eli and I have different definitions "correctness" in this context, but Eli's proposal requires substantial further work, including recovering from possible errors raising from 'json-serialize'. Lastly, I used 'line-beginning-position' naively in the 2 new function because there are at least 4 other pre-existing naive uses in eglot.el. This refinement deserves a patch of its own, probably using something on the lines of (defalias eglot--pos-bol (if (fboundp 'pos-bol) 'pos-bol ...)) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 24 13:55:38 2023 Received: (at 61726) by debbugs.gnu.org; 24 Feb 2023 18:55:38 +0000 Received: from localhost ([127.0.0.1]:38240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVdEI-0006v2-9X for submit@debbugs.gnu.org; Fri, 24 Feb 2023 13:55:38 -0500 Received: from mail-oa1-f46.google.com ([209.85.160.46]:45728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVdEG-0006uo-W4 for 61726@debbugs.gnu.org; Fri, 24 Feb 2023 13:55:37 -0500 Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-1729bdcca99so488850fac.12 for <61726@debbugs.gnu.org>; Fri, 24 Feb 2023 10:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677264931; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+iwxm5wq6ZMOKJN/TNETB6dqaWGlcTpUDuJyVM0Ce2w=; b=iIA0ST6XTIWopY3Mb82QObLPwHQdvccIHc1Efv9BKOYPRfjgMGwsUwvsyCt1gPu5fW Jj4HSi/2/ZSEa+KO36UTNXA8RhkpozOBH/3uOGisujFYqC2rixoIk2YLnlgcs39CuEbv PJEoyETlpGs2Jur31kSSZ3iRDBekFAN5ceaNGiqW/VEvf1GopVsfhQejb+6WUJnubGE1 bfLyaOPQj1m0Abwf5oAIK3mFGO1Dz92t6yr8vFaqZ/b/MwM0W9RREKfRdHCCO+f6d79V +Kz6QKLaZIWnsyZwmf+x4t3ZH05mv9U3OIc882RwVBpLsWLxyPj/8oIrsPH4yr/y9kaX YJqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677264931; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+iwxm5wq6ZMOKJN/TNETB6dqaWGlcTpUDuJyVM0Ce2w=; b=3mC6yP0/SsOM3XQjdU0Wi9jOw5bt5BYPBqGUYUhoo7l47OdDIOWmmPhF08aNYH/XPA oZlJe4TKpBSVazQHAQH0Xr2XmlaEcnE9ZCbokkDq3wChtz/A/sRC9zknByyqHpzFLo/4 f/vVIEAVabFsiKiemMOG/bVFRQg8+AjkgpDhCqPgjBy9LcwbHlb/QgV5DoJ+p+MYAsLu ZUnF6zaQ0gzkrY9JYPcqb7zpLPs4KgggdrQFy1LuT9pS7rIWkoWHyb69zB6XVlcKrbxr AlBEi2gysyCDfaSxYK80Wum+ntDAqM7/D1UEr07me23T/Km/WjZjCZqeHeZ11f9IobXg Lo2Q== X-Gm-Message-State: AO0yUKWXgTcfEH+8FAXO+dBXEZkkDYd90TUr94kGzHAavEE/RZpe1lmg xxuJydk2GMqzN/9pxqYX4eUdUXzyw6TONV6TECc= X-Google-Smtp-Source: AK7set9zmMW/3ExyWTX/RlhER1BCqdme4vHrZuigujlnYAQJQJpGqySC/pnwW4xk8PXRGH6nGHaNaDZZepYHrhhgBIQ= X-Received: by 2002:a05:6870:5302:b0:16e:8b45:1e0d with SMTP id j2-20020a056870530200b0016e8b451e0dmr1326157oan.8.1677264929613; Fri, 24 Feb 2023 10:55:29 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> In-Reply-To: <87fsav7x81.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Fri, 24 Feb 2023 18:55:18 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 24, 2023 at 6:08 PM Augusto Stoffel wrote= : > > I've attached a minimal functioning version of the patch. I would > prefer to merge this and do all possible refinements discussed here at a > later stage. This is OK with me. I think the current patch is OK, modulo some very minor whitespace and formatting options that I can fix myself. > For the 2 new functions I've followed current naming scheme, replacing > "lsp-abiding" by "bytewise". We can then get rid of all the suboptimal > nomenclature (lsp-abiding, column, bytewise) in one go at a later stage. OK, but not too late though, as these are user-visible-functions, and I'd like to tag an Eglot version soon. > I also didn't attempt to make 'eglot-move-to-bytewise-column' and > 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' > throws an error. I think it's clear that Eli and I have different > definitions "correctness" in this context, but Eli's proposal requires > substantial further work, including recovering from possible errors > raising from 'json-serialize'. If Eli is OK with this provisional UTF-8 impl, then so am I. How complicated do you estimate Eli proposal to be in comparison? > Lastly, I used 'line-beginning-position' naively in the 2 new function > because there are at least 4 other pre-existing naive uses in eglot.el. > This refinement deserves a patch of its own, probably using something on > the lines of > > (defalias eglot--pos-bol (if (fboundp 'pos-bol) 'pos-bol ...)) This is also a good idea. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 05:57:10 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 10:57:10 +0000 Received: from localhost ([127.0.0.1]:39256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsEn-0000Yd-UK for submit@debbugs.gnu.org; Sat, 25 Feb 2023 05:57:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45904) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsEm-0000YR-74 for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 05:57:09 -0500 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 1pVsEg-0003v3-Mh; Sat, 25 Feb 2023 05:57:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FB1fOhxc8g8+jlJ/M1BzwSF3vGyg+vVVzqvWXRcpkeo=; b=r2pE/C2k6Dzt UIzBzwTgk7fMEJIM+9lLyt/h2V6tchZwBsbic2K9mrbO+s4pnwIwIoCFsF91vwTSuxSQaIMNHVrTK VS6utDemlBbEL04l1jbUbHd4NBiqqEd+OuyHMAX99Wz4FOURJVfStymoChI2XcX7ih/XWtV7gtOlX Wj/oB1aw8rrZG/A8OdY5h/3CgCpZosOOotcvkoGHwJP1GGXT5CYUpmchvD+KEexNCOhPmx74V1etC zr0r/2EwnrSQ+RnjefqKfi18DoikvQv7oLeJJVKhEVi0XtoHs86k8lPDFlT6137RU7Wepxju0XK/r i5bsbf/btstRiHgXwfis8g==; 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 1pVsEg-0001j6-2j; Sat, 25 Feb 2023 05:57:02 -0500 Date: Sat, 25 Feb 2023 12:57:04 +0200 Message-Id: <83a612ko73.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87fsav7x81.fsf@gmail.com> (message from Augusto Stoffel on Fri, 24 Feb 2023 19:08:14 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Fri, 24 Feb 2023 19:08:14 +0100 > > I also didn't attempt to make 'eglot-move-to-bytewise-column' and > 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' > throws an error. I think it's clear that Eli and I have different > definitions "correctness" in this context, but Eli's proposal requires > substantial further work, including recovering from possible errors > raising from 'json-serialize'. No, it doesn't. All I'm asking for is to use encode-coding-string or encode-coding-region to measure the actual number of bytes in a UTF-8 sequence that corresponds to a region of text. Nothing else is required or requested. Can you please humor me and implement eglot-bytewise-column like that? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 05:58:33 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 10:58:33 +0000 Received: from localhost ([127.0.0.1]:39261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsG9-0000ah-A4 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 05:58:33 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33586) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsG7-0000aU-Pk for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 05:58:32 -0500 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 1pVsG1-00050Q-KC; Sat, 25 Feb 2023 05:58:26 -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=/uD6vaEgsyaNe1hQ/PhpzlVcUd52hTBenZNOt7UMURY=; b=QSdP3Ste9p7YO6m7OjlO OGT5BuunL4zYALIJilZURbysIW7weuJsM+a+hC0SAAlBAC5cz5QH93SmBRwibPvPU4CapseTvP/Cu Xgk7PLQwCZ6riFQXMBOvRb9NfoBCapsjOWfWvYdMf+Yrll1Azw9nJADEiTh5ZVJppxCXm1S7RJVQs JlXFa2fQlLLVqdLRiWDlUCEMPT7gky7fUiHjxucp2TMRsJWg69mZtcvI7mbdWOd434CvoYKFzmR5U X/GSDn+D4afwrQzgvWYaiVaSeNij0jjQBtLeswyVdz36g4bVEKnpJ27Sum+9Inwtyx5hlWXu3vlcB MzBs4k5o77VFqw==; 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 1pVsG0-0004UO-NW; Sat, 25 Feb 2023 05:58:25 -0500 Date: Sat, 25 Feb 2023 12:58:26 +0200 Message-Id: <838rgmko4t.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Fri, 24 Feb 2023 18:55:18 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Fri, 24 Feb 2023 18:55:18 +0000 > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > > > I also didn't attempt to make 'eglot-move-to-bytewise-column' and > > 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' > > throws an error. I think it's clear that Eli and I have different > > definitions "correctness" in this context, but Eli's proposal requires > > substantial further work, including recovering from possible errors > > raising from 'json-serialize'. > > If Eli is OK with this provisional UTF-8 impl, then so am I. I'm not. I asked for a simple modification. > How complicated do you estimate Eli proposal to be in comparison? It isn't complicated at all. I've even shown a possible implementation in one of my earlier messages. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 06:29:13 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 11:29:13 +0000 Received: from localhost ([127.0.0.1]:39275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsjp-0001X7-4R for submit@debbugs.gnu.org; Sat, 25 Feb 2023 06:29:13 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:40733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVsjn-0001Wt-Cr for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 06:29:11 -0500 Received: by mail-ed1-f53.google.com with SMTP id i34so7317143eda.7 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 03:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=zN0JfbpDUoEKXnYlSV3gW8jw0MnBUYqmvD9jN63Osng=; b=pATiGkFPZ0bDhStU9Fh6DSxJYR/05Sdhh4iujbAGOzSqCg8VgYmQhowdXrBA3wrs0u 6TJM6JYnQwmnBMI13aJs8ozEj+fYVTwj3dduzhsxt3coQ4a/ta1JtYHaqZJDLWkacVSX WuN5e8RO8ht4hojJF6sM4bYTgjXoNGvK+780MPLrMfNSQowWOFLChufbbbRISHg0KvbG bzBVnXLALLOOaoSsLKjL4qRum6Bz4hJPW2ykdUITxKzxGx7p83ObU1F+xhAokCZL4zUi QG7Qbp/Boi1TOr+QmBIn0cop938Zfag4SXCKupAVAB1WIk+03iD9WPJQMVPnY2sx3VDH rQQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zN0JfbpDUoEKXnYlSV3gW8jw0MnBUYqmvD9jN63Osng=; b=oM2prn/FIBZwkEmpQz5UwbUWW8IyJVX92MdwDRYfChNOp+aesATmVkdFpwNsR80nZU 355KzYtNQMOHnilEHumFAqT0JdI+xNzffZhs+3lMbveP+2kmM0/L/nKxV4Bk5RSQgTsz BO1OJFp7Z1YlJjySYgDiwFWsqEZZD4ix6EB53eAlgfSxVSJHNkT8M9B3oEdj3Eh+xTpK byoV//xNbssY8okrKmeKrRmN05i0C4Q8Ec7USzMC0uD73MPBDbRLBcuCH3ZxRobsaexP nUFXaeshKHl5PqDXP/BKYwguf7pT0c3LHuV69MpWlR/2ZAPg+I988bMXAUEfxIdW/WUk 0/xw== X-Gm-Message-State: AO0yUKWHNE5CLtJy7HpzV7eIvCLM2nFIPtoCLr+xyVw6PDB59kQgbzXO 3l+lp+xjj0ieGjkJYbHxjjDVwJTfj1A= X-Google-Smtp-Source: AK7set9MJwB0O0cr92uy3akj956EbaUkSE0GqJZEoveiHd7ttcBUdFBM/olYJ6KTHOTSdChJXG40aw== X-Received: by 2002:a17:906:3a46:b0:8af:54d2:2088 with SMTP id a6-20020a1709063a4600b008af54d22088mr26971385ejf.37.1677324544962; Sat, 25 Feb 2023 03:29:04 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id q18-20020a1709060e5200b008e493b7bb61sm731572eji.153.2023.02.25.03.29.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 03:29:04 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83a612ko73.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 12:57:04 +0200") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> Date: Sat, 25 Feb 2023 12:29:02 +0100 Message-ID: <87ttza3rwh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 25 Feb 2023 at 12:57, Eli Zaretskii wrote: >> From: Augusto Stoffel >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org >> Date: Fri, 24 Feb 2023 19:08:14 +0100 >> >> I also didn't attempt to make 'eglot-move-to-bytewise-column' and >> 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' >> throws an error. I think it's clear that Eli and I have different >> definitions "correctness" in this context, but Eli's proposal requires >> substantial further work, including recovering from possible errors >> raising from 'json-serialize'. > > No, it doesn't. All I'm asking for is to use encode-coding-string or > encode-coding-region to measure the actual number of bytes in a UTF-8 > sequence that corresponds to a region of text. Nothing else is > required or requested. > > Can you please humor me and implement eglot-bytewise-column like that? I would be glad to do that, but unfortunately I'd have to ask your advice as to how to make the corresponding adaptation of eglot-move-to-bytewise-column. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 08:47:27 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 13:47:27 +0000 Received: from localhost ([127.0.0.1]:39354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVutb-0007iI-75 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 08:47:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVutZ-0007i5-ER for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 08:47:25 -0500 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 1pVutU-00027n-5I; Sat, 25 Feb 2023 08:47:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XjN5smGdoYxdUHU89lZqBuckquWVjwIRWk7CGuCsk5U=; b=I8szLl5bvnf9 IW6yQ0MwBCjEHFDm9m15qI6vfu6oau5q9i9uR2GWvSaVqRzuWp7ARXQ0Js4fxiNEsIK7fakiPzoiH kurZwof8DkJDVOd1P+MAXHpu/I+CfNhlAwTgz7niVl5cweTaP8BccosU7PXCrUY9NJAAvDqo243j+ ejauoDNDlgvjm5ViNonx8MGn/HRxMa9o2NHMkL3xzh5OTNlT+6JRaNz5ME7KvQdjei0GJ9FDfdBHZ aqRKv27MQdLrc8ZfAWwtoeeGbbPrYtdNWMHJQBA68O4kUa1LZ0Wi00xbnRrEXtxRiXqkJFPdiyJLr qwnWoKWU5oDjfpUShgX22A==; 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 1pVutT-0001Pw-K5; Sat, 25 Feb 2023 08:47:19 -0500 Date: Sat, 25 Feb 2023 15:47:21 +0200 Message-Id: <83356tluvq.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87ttza3rwh.fsf@gmail.com> (message from Augusto Stoffel on Sat, 25 Feb 2023 12:29:02 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Sat, 25 Feb 2023 12:29:02 +0100 > > On Sat, 25 Feb 2023 at 12:57, Eli Zaretskii wrote: > > >> From: Augusto Stoffel > >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > >> Date: Fri, 24 Feb 2023 19:08:14 +0100 > >> > >> I also didn't attempt to make 'eglot-move-to-bytewise-column' and > >> 'eglot-bytewise-column' "correct" in the cases where 'json-serialize' > >> throws an error. I think it's clear that Eli and I have different > >> definitions "correctness" in this context, but Eli's proposal requires > >> substantial further work, including recovering from possible errors > >> raising from 'json-serialize'. > > > > No, it doesn't. All I'm asking for is to use encode-coding-string or > > encode-coding-region to measure the actual number of bytes in a UTF-8 > > sequence that corresponds to a region of text. Nothing else is > > required or requested. > > > > Can you please humor me and implement eglot-bytewise-column like that? > > I would be glad to do that, but unfortunately I'd have to ask your > advice as to how to make the corresponding adaptation of > eglot-move-to-bytewise-column. Instead of this: (defun eglot-bytewise-column () "Calculate current column using the LSP `utf-8' criterion." (- (position-bytes (point)) (position-bytes (line-beginning-position)))) use this: (defun eglot-bytewise-column () "Calculate current column using the LSP `utf-8' criterion." (length (encode-coding-region (line-beginning-position) (point) 'utf-8-unix t))) From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 09:14:17 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 14:14:17 +0000 Received: from localhost ([127.0.0.1]:39385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVvJY-0008SU-N2 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 09:14:16 -0500 Received: from mail-ed1-f50.google.com ([209.85.208.50]:39468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVvJX-0008SF-9V for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 09:14:15 -0500 Received: by mail-ed1-f50.google.com with SMTP id f13so8315963edz.6 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 06:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=hlrTxRUk9yp1gMw7YVu+yKifDKjMbUAtTk1F08fLu5I=; b=Dk394zew6MaeZpmweFLTfcdqI8vvNn/8sGuByJfUzf9CPZddz6jHeE+DQ/LVYyPeqx xqfMIUqD2/CJujUfbwP6NYz8jyU+tSJjszS3EfA9zQr5iI1qwk3/u9ghq9ciJv37u4jv 70lsM9NUOErNz8tRacBKh5M7pe1jvyPcGtr+Jxj6FYwYT3aGmdcGpDxfqlCgRSK3NUXc BHjc8AlIdaP323DIAP93jFGanzbuwAwqADRaRbTj0RuHvcCZM7/tf/EYd9KlfhKaLwQG EEKFG5q0R7Jr9hT5Tgraz1z3FJ3GRpoqcq2zqMotzPrgeYowzHvOitDT4qlhvuauWS6l U1JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hlrTxRUk9yp1gMw7YVu+yKifDKjMbUAtTk1F08fLu5I=; b=6jJfKcjst/CHelYLKIT4d79Rs2GPQzCKX5u33bnwfgkmqZ0h0M4BN6GgX3d9wnJgob VLGO0TDYjwkiXwzHh8Yf5dokDJ6vvgzlSdyw7j6zW1UtKIRg/Abl5M0Pjh+i+xNQleho JVyEBVY8bZBeaTv+H8RWp70DvJl1/yko1TWuyZ8Vjae0b1mUsa4PvKEoFystPwzGq874 Z8C/pf2RXnSQw28pHb0x/r8/Pis8Il/ZMtiqRX/hjC4a6OGZpUzVIATxeOJ0I/fkH3pe uUJbMV7caGu7ISh7plLN1s8/HInlusZfXAqkNW3wkhCnoHprj1iR2Wpx9StEuuBTdF2Q 2z5w== X-Gm-Message-State: AO0yUKUuesOnDnUJ0vlrhBQWaMGop/berVF0vDZygIiZNzYA/bkFGxyJ tMzyQvM8jsU4bOFPg1gvrDMRc03JIb9DEw== X-Google-Smtp-Source: AK7set9uO/2TLDdLLymhIvpP5qM0WE8rGL4jtu+EfkoYS8ER7XWZ7ApRzMUOw5caurNh/3K0Og8F3w== X-Received: by 2002:a17:907:7851:b0:8b2:3eb6:8658 with SMTP id lb17-20020a170907785100b008b23eb68658mr30471404ejc.0.1677334448989; Sat, 25 Feb 2023 06:14:08 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id 13-20020a508e0d000000b004af6e957b22sm908129edw.6.2023.02.25.06.14.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 06:14:08 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83356tluvq.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 15:47:21 +0200") References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> Date: Sat, 25 Feb 2023 15:14:06 +0100 Message-ID: <87a61125ox.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote: >> > Can you please humor me and implement eglot-bytewise-column like that? >> >> I would be glad to do that, but unfortunately I'd have to ask your >> advice as to how to make the corresponding adaptation of >> eglot-move-to-bytewise-column. ^^^^^^^ > Instead of this: > > (defun eglot-bytewise-column () > "Calculate current column using the LSP `utf-8' criterion." > (- (position-bytes (point)) (position-bytes (line-beginning-position)))) > > use this: > > (defun eglot-bytewise-column () > "Calculate current column using the LSP `utf-8' criterion." > (length (encode-coding-region (line-beginning-position) (point) > 'utf-8-unix t))) From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 11:26:09 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 16:26:09 +0000 Received: from localhost ([127.0.0.1]:41349 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVxNA-0003mR-N9 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 11:26:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVxN7-0003lv-RW for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 11:26:06 -0500 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 1pVxN2-0006df-DI; Sat, 25 Feb 2023 11:26:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PXfIfGM2GaYo1wAQdp6H8VZyaLyfR/aOA9fpCy7PrL8=; b=kud5qK8utW9c 4S/e+h4l17uNSUOSgikyUrvgUTS15AJ7HhbOEN1caNYm8azIlAf0y6FA4x2nGSiq05jcvMteD2AI0 d/eXRXrwjF1byi63Y+Oo74L68FJgpTd45ThADTphupA6brcfObONpfPX0S8PqObXYk7bj5BbhXgVe DfpehT2Rv+KULz/8WIUZ+K9ztowFguonLfq6E284m7pfgx19y96u27+JXqH3ZhrB0Lun7qOsBzf/G HHXik8IPLN/pFkPG7U+Ni2pnOlmDhJbxKwaHyiytQfFAnYRBhAq+aK5qqT323Gi2BVAq7g+4PLAO9 Q/pQIdtbykGVCXADfp6Efg==; 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 1pVxN1-0000WJ-S6; Sat, 25 Feb 2023 11:26:00 -0500 Date: Sat, 25 Feb 2023 18:26:01 +0200 Message-Id: <83wn45k8yu.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87a61125ox.fsf@gmail.com> (message from Augusto Stoffel on Sat, 25 Feb 2023 15:14:06 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > Date: Sat, 25 Feb 2023 15:14:06 +0100 > > On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote: > > >> > Can you please humor me and implement eglot-bytewise-column like that? > >> > >> I would be glad to do that, but unfortunately I'd have to ask your > >> advice as to how to make the corresponding adaptation of > >> eglot-move-to-bytewise-column. > ^^^^^^^ Sorry. Here: (defun eglot-move-to-bytewise-column (column) "Move to COLUMN as computed using the LSP `utf-8' criterion." (let* ((bol (line-beginning-position)) (goal-byte (+ (position-bytes bol) column)) (eol (line-end-position))) (goto-char bol) (while (and (< (position-bytes (point)) goal-byte) (< (point) eol)) (if (>= (char-after) #x3fff80) ; raw bytes take 2 bytes in the buffer (setq goal-byte (1+ goal-byte))) (forward-char 1)))) From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 13:10:34 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 18:10:34 +0000 Received: from localhost ([127.0.0.1]:41380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVz0E-0006Lo-Al for submit@debbugs.gnu.org; Sat, 25 Feb 2023 13:10:34 -0500 Received: from mail-ed1-f41.google.com ([209.85.208.41]:39480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pVz0D-0006LZ-3a for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 13:10:33 -0500 Received: by mail-ed1-f41.google.com with SMTP id f13so9791751edz.6 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 10:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=X1HAt0ca4GXa2K36AD1/JGw/VqZIMr9VHQUkpwjG+mo=; b=fTQAjEYS3sUdAyyJfgzCe0dZ4lyDGgR1H+A0NJ6qHy4dZbXbPJDIPAEIRG/R4GmTA5 DE7645iMlwgIga8Lev2h6prqUXIUyYBcGkH3qxVMsnR1iDgfvK93fwzE/MPttZ1VAace q5TfNnxC1XJn3NRN+OuHLccVwNXkvYC7/JskcGqRQDL5J1hofiXlxZKPOs72Z0lGfSeD TaHW37llXJ5ZZEJNkFUl0rdBse3HzZoM6a49oTbqKEmFqMJFd1A8MtlDfdEVa2v0XIjL 2C7/uTBIkW2/dXP2qcCBhtEke9E+qI7Ge+Pntidg7kikr2rciLWWi3zrscgXTxFcokLC GhXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=X1HAt0ca4GXa2K36AD1/JGw/VqZIMr9VHQUkpwjG+mo=; b=SLWbts1CG1NqAxPww7hYOPWwpl+28a+LI8c+R9Y3uJ0xLMWrx0ShuxEspynD0yPfKc dT5IlhUE8R0F+cJNi2ObIw6HehCMlQy3pPGj2agN0NMjTy495gPpsVFMthfNzLShf9yE p5v8zkKTn+cEPeopJpHHKw3s+Iqmp33TvGgpzUrjUX2DbKaqnzzMGZMW3UoTQUb1F8DX oWhvRMFbEKKBrBFKgcfsAi0Nq5G/kkl4ORrRi8TDLXuWN4+qoAItGRonKOgj//sG0+75 tK0ekMO5Iv9ECtxfyuV1XQlSCJ4pSjCBag836zWq8Bfdsb8k7jElm+f+9YBN0J6Qt2Co f7lQ== X-Gm-Message-State: AO0yUKVE9UMd0J5f/VkUszQUz/P0KTC/VEqMfmEMarsjRK58ZWSY82xE U9QbRwdO8bJkmHRwbl1i1tbnA1VWgCsC9g== X-Google-Smtp-Source: AK7set/oa8GaT+URVBZl4kDBjTIU5qAKV8109h38Qzln07BfGaO2UiKT+votw7QbOmMbpOeHd7C4hA== X-Received: by 2002:aa7:d6c2:0:b0:4ac:c57f:e19c with SMTP id x2-20020aa7d6c2000000b004acc57fe19cmr20048164edr.39.1677348626359; Sat, 25 Feb 2023 10:10:26 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::8b3a]) by smtp.gmail.com with ESMTPSA id u4-20020a170906068400b008f883765c98sm1056001ejb.14.2023.02.25.10.10.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 10:10:25 -0800 (PST) From: Augusto Stoffel To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83wn45k8yu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 18:26:01 +0200") References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> Date: Sat, 25 Feb 2023 19:10:24 +0100 Message-ID: <875ybp1ur3.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Okay, I've attached a new patch with your suggested implementation, which to the extent I'm able to test works correctly. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Eglot-support-positionEncoding-LSP-capability.patch >From 0a2f143cae00db4488a56a5f9e27f0e3589a08ef Mon Sep 17 00:00:00 2001 From: Augusto Stoffel Date: Thu, 23 Feb 2023 08:55:58 +0100 Subject: [PATCH] Eglot: support positionEncoding LSP capability * lisp/progmodes/eglot.el(eglot-client-capabilities): Announce the new capability. (eglot-bytewise-column, eglot-move-to-bytewise-column): New functions. (eglot--managed-mode): Set 'eglot-current-column-function' and 'eglot-move-to-bytewise-column' appropriately. --- lisp/progmodes/eglot.el | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index b569c03e8c2..6b38d39c7b7 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -816,6 +816,9 @@ eglot-client-capabilities `(:valueSet [,@(mapcar #'car eglot--tag-faces)]))) + :general + (list + :positionEncodings ["utf-32" "utf-8" "utf-16"]) :experimental eglot--{}))) (cl-defgeneric eglot-workspace-folders (server) @@ -1441,6 +1444,11 @@ eglot--warn (defun eglot-current-column () (- (point) (line-beginning-position))) +(defun eglot-bytewise-column () + "Calculate current column using the LSP `utf-8' criterion." + (length (encode-coding-region (line-beginning-position) (point) + 'utf-8-unix t))) + (defvar eglot-current-column-function #'eglot-lsp-abiding-column "Function to calculate the current column. @@ -1505,6 +1513,18 @@ eglot-move-to-lsp-abiding-column (forward-char (/ (if (> diff 0) (1+ diff) (1- diff)) 2)) (end-of-buffer (cl-return eob-err)))))) +(defun eglot-move-to-bytewise-column (column) + "Move to COLUMN as computed using the LSP `utf-8' criterion." + (let* ((bol (line-beginning-position)) + (goal-byte (+ (position-bytes bol) column)) + (eol (line-end-position))) + (goto-char bol) + (while (and (< (position-bytes (point)) goal-byte) + (< (point) eol)) + (if (>= (char-after) #x3fff80) ; raw bytes take 2 bytes in the buffer + (setq goal-byte (1+ goal-byte))) + (forward-char 1)))) + (defun eglot--lsp-position-to-point (pos-plist &optional marker) "Convert LSP position POS-PLIST to Emacs point. If optional MARKER, return a marker instead" @@ -1758,6 +1778,14 @@ eglot--managed-mode :init-value nil :lighter nil :keymap eglot-mode-map (cond (eglot--managed-mode + (pcase (plist-get (eglot--capabilities (eglot-current-server)) + :positionEncoding) + ("utf-32" + (eglot--setq-saving eglot-current-column-function #'eglot-current-column) + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-column)) + ("utf-8" + (eglot--setq-saving eglot-current-column-function #'eglot-bytewise-column) + (eglot--setq-saving eglot-move-to-column-function #'eglot-move-to-bytewise-column))) (add-hook 'after-change-functions 'eglot--after-change nil t) (add-hook 'before-change-functions 'eglot--before-change nil t) (add-hook 'kill-buffer-hook #'eglot--managed-mode-off nil t) -- 2.39.2 --=-=-= Content-Type: text/plain I still maintain that we are doing a lot of extra work (LOC and CPU-wise) just to guard against the impossible. On the other hand there are probably better places to look for optimization opportunities. For instance, I noticed that when completions arrive form the server, we call eglot-current-column once for each candidate, although most of those will never be used. Also, in a few years every serious server should support the codepoint-based counting method anyway. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 17:11:44 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 22:11:44 +0000 Received: from localhost ([127.0.0.1]:41744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW2lc-00073F-En for submit@debbugs.gnu.org; Sat, 25 Feb 2023 17:11:44 -0500 Received: from mail-wr1-f49.google.com ([209.85.221.49]:42556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW2lb-000733-9Y for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 17:11:43 -0500 Received: by mail-wr1-f49.google.com with SMTP id j2so2592431wrh.9 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 14:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677363097; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=fBJMbWFMwNGn92+OPewvu8B/bat0E9xC3zU2Aj1EeoU=; b=LumV+XtM6bKvWKq7U4F2lMdWUdBm2prArJi4eWcVmZC1YeKGP2iTJUVerOq394GTyW XkoYH5ookeOfqkz4k0ugjigQ+BHWx0zBPpnowxA/hkXF6PECFl7+kpu4Mui/gXBqzBwI JkeGlqKeL7kFviqHSci1dr9hJHhqAM4TjZAe2LcgysQKcPog9NjasRAu+05ZBeOVTRJM iPTN9ZDXEyOwYe/ytqJJr9+9iJg+jpm/UbLTfQTzwqoZYyWCwuAuQmf/SdEyk5wPu4cz 3+igd2mWfU6oXXkx/jAt4Z/PnSv/ngrvtCC4BH1cClKeHINuU+1/Wm1WrayXWbFpYYdJ EsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677363097; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=fBJMbWFMwNGn92+OPewvu8B/bat0E9xC3zU2Aj1EeoU=; b=j7UX+T9fcVMXTOWHRnzqXiOlMmiCgQ+Y2H45CHWEgSA5h0HndHU5jth3U89L9Ar1Og lJaKtdbBtnRByQrx7yNuE6XuoV5RIk4z7jPRiJo/AeCtNXSHACHX+zlmOoNIdjadyhYq ZWAVqNcFWUHBvp7Z0oQsLkhOsvv/lwq4z+Eg521PSN+lG99Gvki4mDuuGq8edtj1T9m7 jLypFuQxCZYcBNMENOkRpkQTGNWLwnSeX3c3Zkj9WJNvV+eLs0a0WYjjavE7JMc/smZ2 LaiPi8JAMldbFDGO2dyIit4fHW9DWb6YsS2iun8aY44y3WQHVkLRKZd+Fm1lF8wUpfCZ 9foQ== X-Gm-Message-State: AO0yUKX+bv6Ma2z5aM3pHKybky/ZLomVHpFXzNU6sywMT53GZjGnvGRN cpKsV6ywyN1TuR6+m2amxIov8uXAqYY= X-Google-Smtp-Source: AK7set8Av+4o4xjlFSvsKfTqmNoBHbCthpiDgG6zwEAWfB3oy0I8x1cmb3snK84Y1D6aLZIuucuJeg== X-Received: by 2002:adf:e808:0:b0:2c7:1d0d:7184 with SMTP id o8-20020adfe808000000b002c71d0d7184mr6137945wrm.11.1677363096970; Sat, 25 Feb 2023 14:11:36 -0800 (PST) Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id i2-20020adfdec2000000b002c71dd1109fsm2775711wrn.47.2023.02.25.14.11.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 14:11:36 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83wn45k8yu.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Feb 2023 18:26:01 +0200") References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> Date: Sat, 25 Feb 2023 22:13:29 +0000 Message-ID: <874jr9z94m.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Augusto Stoffel >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org >> Date: Sat, 25 Feb 2023 15:14:06 +0100 >>=20 >> On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote: >>=20 >> >> > Can you please humor me and implement eglot-bytewise-column like th= at? >> >>=20 >> >> I would be glad to do that, but unfortunately I'd have to ask your >> >> advice as to how to make the corresponding adaptation of >> >> eglot-move-to-bytewise-column. >> ^^^^^^^ > > Sorry. Here: > > (defun eglot-move-to-bytewise-column (column) > "Move to COLUMN as computed using the LSP `utf-8' criterion." > (let* ((bol (line-beginning-position)) > (goal-byte (+ (position-bytes bol) column)) > (eol (line-end-position))) > (goto-char bol) > (while (and (< (position-bytes (point)) goal-byte) > (< (point) eol)) > (if (>=3D (char-after) #x3fff80) ; raw bytes take 2 bytes in the buffer > (setq goal-byte (1+ goal-byte))) > (forward-char 1)))) In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this function) we use a binary search instead of a linear search. I remember measuring a visible improvement. I'm not sure the conditions are exactly the same with this one. Could/should we do the same here? Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 17:13:51 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 22:13:51 +0000 Received: from localhost ([127.0.0.1]:41748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW2ne-00076W-Vo for submit@debbugs.gnu.org; Sat, 25 Feb 2023 17:13:51 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:35822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW2nd-00076D-23 for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 17:13:49 -0500 Received: by mail-wr1-f51.google.com with SMTP id q16so2630615wrw.2 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 14:13:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677363223; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1phlU+F2krX7v3KvR2FHu2PLO2s8BNjZUxfbzV+S7ec=; b=c8FO5VQaSb6m+vs9rHrhGx6l++3ZFR0osD6tzRotk8Tr6astIlq+2I0q2MA/g8Xwk8 aWRbbptPxrcYwI39EjzxAheEtfIKO8VguZO5yeaoTjC130o+vg2NGPjta59x568KApSF 0bQ1rkpTLifjXLnawmRKL/KDZUn+zC5jhbE5zEbFU4CGneXq3LLl1FHlaOn7aFOt0Lah J5JlxR+vP/xfBZ7n/XrU0zKIGbjXDj8c6ERn7lOm9qcdt8icu970Gzg7+1GY1K84rLKm zEYZLud83xiLNLLvLCqBv8I3ud3NioorA1HuhgsrgN51eTklOI7Gl7bY3xrDti4I1Jdl 3s5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677363223; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1phlU+F2krX7v3KvR2FHu2PLO2s8BNjZUxfbzV+S7ec=; b=do8Vr4KeLTHes90vJkzvJYw0tzLkJ4Eo4iie58qaduJw91jXP28yFphxpLdhrTE+ox Qil0bfNbX9Zv2O2t/B1DvMIa7lFi8tL4JGevnYg77RUDvh2ATchEV7JfKQgmGslzFfxd M/XBCjm7YVhld7sJPVNlACfalvCPBgSU/3/iEaNTW+hB5BDg8281mTGNV5tLy1J8qinf zJ2OSPZO8YkRlK4OUdhnwA3h+sYOylvE86mca/RRTQSIsHnw5y14JzUrqOS5Lsy/ufFy gAj+A+tvripfr7ZB6ejy/6TaqFwJNyLPyx2kkLvimuxEQY/I7ribo9r+j3cx6+UP0+7I +EwQ== X-Gm-Message-State: AO0yUKXCFOBBsURoalwu8MbPM6crfiBnSeltap3p9LOKV0Fi62QX8lwn Q54cs60eTAlwD9bN27v15rvFyfUfB5A= X-Google-Smtp-Source: AK7set8ZexgxuDQiQ+uMQ0zd7p7PcMvdotECJrjzP56TOak2UG6rAShVs3Lo5apX+fkEleIYIQ2/UQ== X-Received: by 2002:a5d:6c6c:0:b0:2c6:7861:ece9 with SMTP id r12-20020a5d6c6c000000b002c67861ece9mr3243339wrz.11.1677363223058; Sat, 25 Feb 2023 14:13:43 -0800 (PST) Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id be6-20020a05600c1e8600b003e89e3284fasm7735769wmb.36.2023.02.25.14.13.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 14:13:42 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Augusto Stoffel Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <875ybp1ur3.fsf@gmail.com> (Augusto Stoffel's message of "Sat, 25 Feb 2023 19:10:24 +0100") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <875ybp1ur3.fsf@gmail.com> Date: Sat, 25 Feb 2023 22:15:35 +0000 Message-ID: <87zg91xugo.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Augusto Stoffel writes: > Also, in a few years every serious server should support the > codepoint-based counting method anyway. Exactly why I wonder why we're going through all this bother to support an intermediately flawed alternative. So don't state this too often ;-) Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 17:34:13 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 22:34:13 +0000 Received: from localhost ([127.0.0.1]:41791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW37M-0001aM-Ph for submit@debbugs.gnu.org; Sat, 25 Feb 2023 17:34:13 -0500 Received: from mail-ed1-f45.google.com ([209.85.208.45]:37740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW37L-0001a9-AN for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 17:34:11 -0500 Received: by mail-ed1-f45.google.com with SMTP id d30so11349464eda.4 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 14:34:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=j4AZTpj249yqAza48NG4/2ezVrOY+UjjJSITdG1bv0s=; b=bbVZM0DY3Al/aORPeXNl+Np5V880egpa64PyATdnfGDczWja+Rixf/4U971oeuxbPW tJAN5ZA9mbrJMOy0h5wtH8BWEoUxP/lqRT+kCris9bI8ba9pcZpDdi82IYEO4/QwnZ0D 9M6cXRizGCHNV8oxyKjGQ9YoUY56xjr6OHt06Ws0Bg/KFHI+6vK8JpsSDkVqgeZTfhEM DN0ruAwf5dVL1/6V5H6MNM9FfA8SgBpGwXEtNIZl1BuCchsOJ4OvqFRpM3i0ktET/xWe iDHhSS1WUrAZ3tGnKrxKcYES5GdUw3YouKlpwwRF+kpFienGqs+ZoPPLrCBtIUp11AFL q1sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=j4AZTpj249yqAza48NG4/2ezVrOY+UjjJSITdG1bv0s=; b=naCUJBzt3GqWPwXhWHwuUVhqON7LLQ9cjD8Gc0GqjR8GZGIepxYSmqaaPpv6iSUdR9 WbA6/CphNg3qXyPnwZhi34/QeyhPdeXBEApZdWNWCssZfYCfahPF1mJuNRMADKfJobkw qqSH5ntbkJtPTPcQw9VOCC/R/YNZy0YNauJeIs9uAQRxAKN0hN/gu+oaB2k4KjcRhjWc jz0wd2JrrHXgRKKxSxPNtjaDaxlaxo3eskxP1f0Vntk+minCbR+AcpGCYe/rpoGCWFBp ZJF27D0JA/t4LUad/jqVA74gum2yFlbOvZspRXyp1lnVdcSrQx371Eq6937z4JnzC5L6 UXxQ== X-Gm-Message-State: AO0yUKVA9WDOtcQBYeKRYPKigwuRNDiK6niSXACWfS5XJFqMe82CLFCX jSULm6Budez5l4a/Rb2PY1Oyroid58B84A== X-Google-Smtp-Source: AK7set8/wRtDTogkhjfJDM5q/hHN9VbA8R4mqVuFY1Nx6ikjavgc0kJPsCH8r1fCk0h6O+BCbZmAIA== X-Received: by 2002:aa7:c604:0:b0:4ac:bd84:43d9 with SMTP id h4-20020aa7c604000000b004acbd8443d9mr17060340edq.2.1677364444849; Sat, 25 Feb 2023 14:34:04 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::8b3a]) by smtp.gmail.com with ESMTPSA id w30-20020a50d79e000000b004acb696a0f6sm1295658edi.91.2023.02.25.14.34.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 14:34:04 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <874jr9z94m.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Sat, 25 Feb 2023 22:13:29 +0000") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> Date: Sat, 25 Feb 2023 23:34:02 +0100 Message-ID: <87y1olv0h1.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 25 Feb 2023 at 22:13, Jo=C3=A3o T=C3=A1vora wrote: > In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this > function) we use a binary search instead of a linear search. I remember > measuring a visible improvement. I'm not sure the conditions are > exactly the same with this one. Could/should we do the same here? Funnily, in the quick tests I made, Eli's function seems twice as fast as "lsp-abiding". Specifically, I ran the following (for each of the 3 move-to functions) on a buffer where the first line is about 100 characters long: (benchmark-run-compiled 10000 (progn (goto-char (point-min)) (let ((len (- (pos-eol) (point)))) (dotimes (i len) (eglot-move-to-column (mod i len)))))) From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 18:15:04 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 23:15:04 +0000 Received: from localhost ([127.0.0.1]:41813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW3kt-0002cV-U4 for submit@debbugs.gnu.org; Sat, 25 Feb 2023 18:15:04 -0500 Received: from mail-ot1-f49.google.com ([209.85.210.49]:38674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW3kr-0002bj-MO for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 18:15:02 -0500 Received: by mail-ot1-f49.google.com with SMTP id t7-20020a9d7487000000b00693d565b852so1666599otk.5 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 15:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677366896; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=2W4VDZYR6CbggnTddWx6XkrfhoZbzw7kRoVuwkrkQaQ=; b=Y2UQFHvftfKh58Fw9g8a3vPKBVCrqUe8CHdMp9DEkOUrxY6CGR9c3wGC/nF+oooBkV Kvh4SeyUSbCVR+PATLBgFUD/C9nMvkLaRIdCRhH7UDrbx12eLt6/CTNl0lb525JyPV6E c1fpWm591EN2RnI+Zcnhvrpa61vdLd2NQGsKg2WhkWXzS65BmQajl0zr41kG42U5aJcf qbKRjHRN33O8mhlSLGTTyR4jwSKZVB5iUtBDonpNYqciYQebo9PHjqvN/ESFceh2ZlsE tjsRawlXWI0miFA1jVRaRHvbhDNgVRWCWx+H3Q1uatAC6gdaWr/V2KBm/fxYDXkIw+h5 PpSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677366896; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=2W4VDZYR6CbggnTddWx6XkrfhoZbzw7kRoVuwkrkQaQ=; b=R2Ds/ky0f8pt7iOGdTlIltokVAfTNiAKIcbUTc0EpHd8HBRWifUhvA7/4B8xyH5jVe Ma8iAPQqIedtMiDRTkv7LoEc0z9qXn+jVISganSvO7tdkipdXSFjQjWni9J7Or03xTWk TYdpIlUVzT7CDciBNS4aTAYnzlgARiVShNGwqeaYqf9LuwxIFUuKNgyv1kK8GaqSLFMv 3MoIFtsIAExGV4je/K+fiu6hw88ONOtFNaKXG+l13BcWMabNQjaBP6Xm9HRraF3Jd4eT h6+WUoL3xfQPJ7Xl1JNv2OeMeiLYCM7n5uqwXSAmFD6rWylJlWeH5gesqdV9DrezvIFY FuVQ== X-Gm-Message-State: AO0yUKWGEL/PZp/FU4x0cY2T8nc+50z4++beSO/u7MDNr6qzvfc4c8px cL3UxQ9Q/lQsr3cCeHFjjFI4yLu24dhyO6K0kvY= X-Google-Smtp-Source: AK7set9Yzv6hgtEj2N9qhjMsdi4T+SmJkoxDBkgeLqpWskFp4ei/LAJ3Vj/gdEo+GtNmnMrYVbY0LFpuiwDFWYQEmLo= X-Received: by 2002:a05:6830:308b:b0:688:cfcc:ddaf with SMTP id g11-20020a056830308b00b00688cfccddafmr2934131ots.3.1677366896145; Sat, 25 Feb 2023 15:14:56 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> In-Reply-To: <87y1olv0h1.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sat, 25 Feb 2023 23:16:38 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Augusto Stoffel Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Feb 25, 2023 at 10:34 PM Augusto Stoffel wrot= e: > > On Sat, 25 Feb 2023 at 22:13, Jo=C3=A3o T=C3=A1vora wrote: > > > In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this > > function) we use a binary search instead of a linear search. I remembe= r > > measuring a visible improvement. I'm not sure the conditions are > > exactly the same with this one. Could/should we do the same here? > > Funnily, in the quick tests I made, Eli's function seems twice as fast > as "lsp-abiding". That's understandable as lsp-abiding has to measure the length in bytes of a number of codepoints every time it does one of the iterations of the binary search. Position-bytes doesn't quite work there (I can't remember why). It's quite faster than it's linear search cousin. So comparing those two doesn't make sense. I meant comparing a linear version of the utf-8 function to a binary-searching version of the same utf-8 function. If that even makes sense here: I'm not sure it does because I haven't followed the details of the problem. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 25 18:57:53 2023 Received: (at 61726) by debbugs.gnu.org; 25 Feb 2023 23:57:53 +0000 Received: from localhost ([127.0.0.1]:41833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW4QK-0003gh-OQ for submit@debbugs.gnu.org; Sat, 25 Feb 2023 18:57:52 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:43927) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW4QJ-0003gU-HN for 61726@debbugs.gnu.org; Sat, 25 Feb 2023 18:57:51 -0500 Received: by mail-ed1-f53.google.com with SMTP id h16so11663312edz.10 for <61726@debbugs.gnu.org>; Sat, 25 Feb 2023 15:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=nU18dSdJfr3ixPGehOChUteSYb5DWR6Q4gK4pEg4RJI=; b=PJZVc6EyhZZA7YZ4948AB7my4bCsUv3BTdzl9vukgPMSVuBIlJPmeWLSgyYOnVsjr+ bgDDKhUGTrA2AYIDYhlrlF0HRn8U80y5Dnv3bHXpJkjC5ko810otJ6XYhc7oSMym6atw 6ip4+dJZozUDjMaqcVTgL5lrr0WWciUveMkN3NsbsJkmR5BXjF97uWxxSLhuLXm0rFfJ COPwN7+Gw+GT2G7XJqiQ1xAnqSqt0O+NVTfBDkYtjEYhg433wObJAcvN/Zz4lhyXQQrP kKnYuFCUrjuT6VnZZXqmlmTM5V2uWFkvrRySh2X5f1RDy1VyselhQ1VWwTNhgVPONsJA B0KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nU18dSdJfr3ixPGehOChUteSYb5DWR6Q4gK4pEg4RJI=; b=bNCatV2ANGjqAjDt+4076NISXqczCEoM1+bUJK6tukv5L/xPi/OLy7BPcyW+aYB0z/ MyQT4H5n6DwdcUXS35g1rsjcbNaKlBoIm2Qr9YzW/W683fB1Wde3ByxIE7u2QOB0Q3M8 dnUeEveg+R3ji/cnnxDmhQxGbe0n3X/P27kj9J5jsgHI1qxgZem1Zh4IiQRgn7O3sXHr jg9k3fmaBU7EwV6FydLYHkiw3SrmjOdiQ5lgEiJglJlM0kt52zp9EzNmzT82gNodSyTE qWHWOeNbtf46XFLT9L8xyLnstbZHihlqtd58yDsJtPjp+RpFdhF/Jx4R4LfC41KhHZFO vJgw== X-Gm-Message-State: AO0yUKWtgsJlcbHGcxRraU+4C5kRIRpHVW5S1FUoszRmJh2on6gTlpZQ b8mGJSCtmoTgV/wqvSyPvgws4oB8nA5u2w== X-Google-Smtp-Source: AK7set851PstqgfInveyT78UoVH7eTbUay8McrhRMgYAt+RI91I5ViZu4zEodVzPszXVDAZrGab0ZA== X-Received: by 2002:a17:907:8a03:b0:8e3:8543:8ebe with SMTP id sc3-20020a1709078a0300b008e385438ebemr21755097ejc.57.1677369464945; Sat, 25 Feb 2023 15:57:44 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::8b3a]) by smtp.gmail.com with ESMTPSA id t8-20020a170906178800b008dcf89a72d7sm1365647eje.147.2023.02.25.15.57.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Feb 2023 15:57:44 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Sat, 25 Feb 2023 23:16:38 +0000") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> Date: Sun, 26 Feb 2023 00:57:42 +0100 Message-ID: <87sfetgux5.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > That's understandable as lsp-abiding has to measure the length in > bytes of a number of codepoints every time it does one of > the iterations of the binary search. Position-bytes doesn't quite work > there (I can't remember why). It's quite faster than it's linear search > cousin. > > So comparing those two doesn't make sense. The linear cousin of "lsp-abiding" is very similar to the function that Eli wrote: (defun eglot-move-to-lsp-abiding-column-linearly (column) "Move to COLUMN as computed using the LSP `utf-16' criterion." (let* ((bol (line-beginning-position)) (goal-char (+ bol column)) (eol (line-end-position))) (goto-char bol) (while (and (< (point) goal-char) (< (point) eol)) (if (<= #x010000 (char-after) #x10ffff) (setq goal-char (1- goal-char))) (forward-char 1)))) It would be very hard to believe they have different performance characteristics. In fact, in some hastily done tests, I get the following relative running times: eglot-move-to-colum: 1.0 eglot-move-to-lsp-abiding-column-linearly: 8.4 eglot-move-to-bytewise-column: 8.0 eglot-move-to-lsp-abiding-column: 14.4 From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 00:31:48 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 05:31:48 +0000 Received: from localhost ([127.0.0.1]:42155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW9dU-0000CD-Br for submit@debbugs.gnu.org; Sun, 26 Feb 2023 00:31:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pW9dS-0000C0-PL for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 00:31:47 -0500 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 1pW9dN-0004Cd-Fz; Sun, 26 Feb 2023 00:31:41 -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=mCQugv6XteDRJeON1KEbl/Hnb2xneVCn3U6456yDgn0=; b=fN3KLEq0dDJKWAXmixB7 w5WjN33pPwwGuMO9a5OCI3+89mCfbrA0+FLG8BykXaM6OrMh+t0nPoyemTzKk+TfgczEk9SsUvuH1 6FgSYhN7KOGolWXTAVGnVzrFPVPIloRX1BTJY6+327uOdxfdpbdZUa9yWUeH3t5o7vnEF/l2eV61Y s8NMnKkWGbYEec7JCtRBtVcUsRDGCZYpmC1TNbdL5iRspOiu/2akXjN29QQFfjzZlrfzIsdJRo9em G3b9gF3w4VuPjm2uVFqolGN5qd1juNjWbm47++LRfmoyJnchgRcdCH7nszv38xvIvd2ACsd6feMxj TUb5VM9fFp0rpQ==; 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 1pW9dB-0006st-Nr; Sun, 26 Feb 2023 00:31:35 -0500 Date: Sun, 26 Feb 2023 07:31:34 +0200 Message-Id: <83r0udj8ll.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <874jr9z94m.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sat, 25 Feb 2023 22:13:29 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > Date: Sat, 25 Feb 2023 22:13:29 +0000 > > Eli Zaretskii writes: > > >> From: Augusto Stoffel > >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > >> Date: Sat, 25 Feb 2023 15:14:06 +0100 > >> > >> On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote: > >> > >> >> > Can you please humor me and implement eglot-bytewise-column like that? > >> >> > >> >> I would be glad to do that, but unfortunately I'd have to ask your > >> >> advice as to how to make the corresponding adaptation of > >> >> eglot-move-to-bytewise-column. > >> ^^^^^^^ > > > > Sorry. Here: > > > > (defun eglot-move-to-bytewise-column (column) > > "Move to COLUMN as computed using the LSP `utf-8' criterion." > > (let* ((bol (line-beginning-position)) > > (goal-byte (+ (position-bytes bol) column)) > > (eol (line-end-position))) > > (goto-char bol) > > (while (and (< (position-bytes (point)) goal-byte) > > (< (point) eol)) > > (if (>= (char-after) #x3fff80) ; raw bytes take 2 bytes in the buffer > > (setq goal-byte (1+ goal-byte))) > > (forward-char 1)))) > > In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this > function) we use a binary search instead of a linear search. I remember > measuring a visible improvement. I'm not sure the conditions are > exactly the same with this one. Could/should we do the same here? Fine by me, but optimizing a method that is not yet used sounds a bit premature, no? I won't object, though. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 01:03:22 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 06:03:22 +0000 Received: from localhost ([127.0.0.1]:42166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWA82-00010b-7D for submit@debbugs.gnu.org; Sun, 26 Feb 2023 01:03:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWA7z-00010L-Jc for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 01:03:20 -0500 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 1pWA7u-0005l2-DI; Sun, 26 Feb 2023 01:03:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ZNhvGlmeGAJrSp3EU5a0pwPENZnoBy0vkdpOjAIp3Zo=; b=YpBvYRn7IHz8 DQVinlPRinjXXGbQANkyxnECPgrV80/39HZgw3c7IrGHFFnrt/tcZOuWdOY7zqiaWYCUT6N4OVPB+ +UdorZ/3f5RLAoTccHEHigyIpvFCkk0zbnqoa2Ru2fsX7lGV/VZCqMtHW1+3tE6qo9f1lYsevEV6x mBv4zzMiPZKq3NhYtKZfbV9QOLvlyE1EI9/pofQH6AmQ245aTzNiHqnY0paOlfV8bOZO4Sry9S30w tpstuJVh/Su3eyYIN1sVa4x1jWOZGusGxbMzr7ugLL6/HhaGmqhSTKRFmZsCvaPgRoZPiDKWKXhX2 +Ptss8pehJIK4DV+UBK7Ag==; 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 1pWA7t-0003zj-GY; Sun, 26 Feb 2023 01:03:13 -0500 Date: Sun, 26 Feb 2023 08:03:17 +0200 Message-Id: <83pm9xj74q.fsf@gnu.org> From: Eli Zaretskii To: Augusto Stoffel In-Reply-To: <87sfetgux5.fsf@gmail.com> (message from Augusto Stoffel on Sun, 26 Feb 2023 00:57:42 +0100) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, joaotavora@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Augusto Stoffel > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > Date: Sun, 26 Feb 2023 00:57:42 +0100 > > The linear cousin of "lsp-abiding" is very similar to the > function that Eli wrote: > > (defun eglot-move-to-lsp-abiding-column-linearly (column) > "Move to COLUMN as computed using the LSP `utf-16' criterion." > (let* ((bol (line-beginning-position)) > (goal-char (+ bol column)) > (eol (line-end-position))) > (goto-char bol) > (while (and (< (point) goal-char) > (< (point) eol)) > (if (<= #x010000 (char-after) #x10ffff) > (setq goal-char (1- goal-char))) > (forward-char 1)))) > > It would be very hard to believe they have different performance > characteristics. In fact, in some hastily done tests, I get the > following relative running times: > > eglot-move-to-colum: 1.0 > eglot-move-to-lsp-abiding-column-linearly: 8.4 > eglot-move-to-bytewise-column: 8.0 > eglot-move-to-lsp-abiding-column: 14.4 The current version of eglot-move-to-lsp-abiding-column calls encode-coding-region in the loop, which I guess is the main reason for its being slower. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 05:32:05 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 10:32:05 +0000 Received: from localhost ([127.0.0.1]:42389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEK5-0000Hi-CH for submit@debbugs.gnu.org; Sun, 26 Feb 2023 05:32:05 -0500 Received: from mail-ot1-f51.google.com ([209.85.210.51]:38600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEK4-0000HD-7W for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 05:32:04 -0500 Received: by mail-ot1-f51.google.com with SMTP id t7-20020a9d7487000000b00693d565b852so2071763otk.5 for <61726@debbugs.gnu.org>; Sun, 26 Feb 2023 02:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677407518; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WpPD3rXUotJSjvqhDyrr4XI8WUUavJLbSXk5eNtTAgw=; b=AEM90dWa3bHJlmTz1zMNmthR6rfaaZEwf4dt64zTZpKT0gsI8Ku6vtFQEGT+G+SGG8 lRtnqmA7tSjNxveZvfqg7054MMHVIQc7ik2zuv9XEJriHqmFQWCl6qnZGXvPeJyupsES G5j8P5EfTXhGr79j7mXp3fQUBIlwQKjdaHHudNF9XH6c72suAQPxJmPfT1j8bPKg+7YZ iKuuHZxUluD4NFzCmaQyJF9MWrUBLZizG6TG6lYib7htCZof3jH5tydfinbIQZJPCRSy QC4HRwZS9tlvVRLmewVVoYd0YYXog85YcQQcS5Nh4VESDB+Xea11HqgMC4yyJNTLFOyj 8F6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677407518; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WpPD3rXUotJSjvqhDyrr4XI8WUUavJLbSXk5eNtTAgw=; b=vBsoEpSJlJ1QZCdRahyH2uKDOm/mOBfTr17NR7u/QcXpZib6QxPTDMzLbkd/jezA1/ lbYTmKliponpGKQeIqelwmGJ6ehOHonbDChyP1JXnJHIZibwcl3m+Dt7iyFZRjkC37l1 aA2JaHLhQAT8U+97RsGc6ZEFPfuAF2gL9ctEX2DLYeAkpWxzKNOAX4VEwCq6tAndZpm5 Pxo2RbwCPdQQ24+La4NUk9g6haYwZ+TTKSWj37HVRbMA0HSz9dGviCx2fojc/HJRfc4/ phQk/DogzDKjdTO8WlWHyu03IVtNAp9x7mx95Trp/WmzZhtjHQhbRqOGcS5nlZJzPW7f /Pmw== X-Gm-Message-State: AO0yUKV/8H+lVdL50Fn/sI91m9C0JZbk5uRzDyeHSPS6rYMwVOHNyFaf R2BFYmEfo0WeR1YezG0QjbsIB51ED3IExCGl6EA= X-Google-Smtp-Source: AK7set8ftOuBu8jXQTr1IN6VzrthkG2rWpwky69H+AYQierOlpAY+PNaAGZUAmxkNNm+A8UoZXuz0ARYe7SSJQaRxlk= X-Received: by 2002:a05:6830:308b:b0:688:cfcc:ddaf with SMTP id g11-20020a056830308b00b00688cfccddafmr3261411ots.3.1677407518512; Sun, 26 Feb 2023 02:31:58 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> In-Reply-To: <83pm9xj74q.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 26 Feb 2023 10:33:39 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Feb 26, 2023 at 6:03 AM Eli Zaretskii wrote: > > > From: Augusto Stoffel > > Cc: Eli Zaretskii , 61726@debbugs.gnu.org > > Date: Sun, 26 Feb 2023 00:57:42 +0100 > > > > The linear cousin of "lsp-abiding" is very similar to the > > function that Eli wrote: > > > > (defun eglot-move-to-lsp-abiding-column-linearly (column) > > "Move to COLUMN as computed using the LSP `utf-16' criterion." > > (let* ((bol (line-beginning-position)) > > (goal-char (+ bol column)) > > (eol (line-end-position))) > > (goto-char bol) > > (while (and (< (point) goal-char) > > (< (point) eol)) > > (if (<=3D #x010000 (char-after) #x10ffff) > > (setq goal-char (1- goal-char))) > > (forward-char 1)))) > > > > It would be very hard to believe they have different performance > > characteristics. In fact, in some hastily done tests, I get the > > following relative running times: > > > > eglot-move-to-colum: 1.0 > > eglot-move-to-lsp-abiding-column-linearly: 8.4 > > eglot-move-to-bytewise-column: 8.0 > > eglot-move-to-lsp-abiding-column: 14.4 > > The current version of eglot-move-to-lsp-abiding-column calls > encode-coding-region in the loop, which I guess is the main reason for > its being slower. Yup, here's a surprise. We don't need encode-coding-region after all and the binary search I implemented back in https://github.com/joaotavora/eglot/pull/125 is mostly useless. In that issue, noone thought of counting characters by examining the code point values and counting code units. So I pushed this much faster, simpler version to emacs-29. I credited Eli in the commit, as we wrote the code. Hope that's OK. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 05:37:07 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 10:37:07 +0000 Received: from localhost ([127.0.0.1]:42393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEOx-0000PV-5V for submit@debbugs.gnu.org; Sun, 26 Feb 2023 05:37:07 -0500 Received: from mail-ot1-f41.google.com ([209.85.210.41]:41710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWEOv-0000Ow-Gu for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 05:37:05 -0500 Received: by mail-ot1-f41.google.com with SMTP id f19-20020a9d5f13000000b00693ce5a2f3eso2067526oti.8 for <61726@debbugs.gnu.org>; Sun, 26 Feb 2023 02:37:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677407820; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=E4kW/rshxOAiYvi7Wtj1z4ZMxMnirILzr+vl6QwBUvA=; b=f+YxoJmsGgylKATJg+tR3as0tzyLoDYmeAyrU1jsbZy0qglS3Gp+zr0QnyBTO6gwat 4d4wJH1V8KmaPU3zEYLJsCp5m3Q0Q9g7I84CvZy19x8ZSAQTZceYdQdlleUW/41RMseE JBFL+7eLME1ESW1YXaG76BrXrDZ9WQLHeHbks53HuaXfEM76JLeYbtDWBmnhm78tlqwT Xzu4KUm8IReurki1heck47XYotTeRDy1CPD8Uo8AyZ37GJjybL45k/879KdKQNySHQRy +kE/lNdmxDVbkPhEi+xp8ul9aVz6sweIZs4idM9K7311+leAJ44xawJMEF8NLO6BjJ8o B+PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677407820; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=E4kW/rshxOAiYvi7Wtj1z4ZMxMnirILzr+vl6QwBUvA=; b=CTwYmsCq3JhewJBbZilOPhnM0NSYJD62eMXBJjgH/v7di3rVER5rRl+M1APCcQhuPT jUfb4QmKU7GimALoIX4Rov4dAu0f1xWq76cM+BQIFZAFVtiwmbUUGfuz6BPJlhZ+8nYc z88huQq++65X6pHBUHNwdQvX8jsawAbNMSjvlodxvQ9a3AueCuv/oA1lxqQIFgq2z0UM udvxZL8DMArndZywA7/194c7QlVaFokjf7cLUoNJN44XQ42ndJfjRFppMtxPa3V2cZaw 7j+3EfrTqot+MHiDuGwyP34ho3uaFd0PqG9Wvz8RYx0eAyoneyeTIkzxGPdm1h74uzkc 1GDw== X-Gm-Message-State: AO0yUKUCc/A8bN5Szdhe5yy6u9hymF6mJfTgxaGKjYeYx1zqRUS/50at l/JkS+Zt98IjhO7rkL2Tf7gW84ryadcL76f4UWc= X-Google-Smtp-Source: AK7set+AwKdGMojkqkUMGyt3u5kplxTzIuWDmMMTqZkgHPpCWPqdaOrLDA9gn9PtbgRbZFViPWDRGy0ls/XyXLG7vdM= X-Received: by 2002:a05:6830:39f1:b0:68b:ccee:5ead with SMTP id bt49-20020a05683039f100b0068bccee5eadmr3409418otb.3.1677407819994; Sun, 26 Feb 2023 02:36:59 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> <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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <83r0udj8ll.fsf@gnu.org> In-Reply-To: <83r0udj8ll.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 26 Feb 2023 10:38:40 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Feb 26, 2023 at 5:31 AM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > > Date: Sat, 25 Feb 2023 22:13:29 +0000 > > > > Eli Zaretskii writes: > > > > >> From: Augusto Stoffel > > >> Cc: joaotavora@gmail.com, 61726@debbugs.gnu.org > > >> Date: Sat, 25 Feb 2023 15:14:06 +0100 > > >> > > >> On Sat, 25 Feb 2023 at 15:47, Eli Zaretskii wrote: > > >> > > >> >> > Can you please humor me and implement eglot-bytewise-column lik= e that? > > >> >> > > >> >> I would be glad to do that, but unfortunately I'd have to ask you= r > > >> >> advice as to how to make the corresponding adaptation of > > >> >> eglot-move-to-bytewise-column. > > >> ^^^^^^^ > > > > > > Sorry. Here: > > > > > > (defun eglot-move-to-bytewise-column (column) > > > "Move to COLUMN as computed using the LSP `utf-8' criterion." > > > (let* ((bol (line-beginning-position)) > > > (goal-byte (+ (position-bytes bol) column)) > > > (eol (line-end-position))) > > > (goto-char bol) > > > (while (and (< (position-bytes (point)) goal-byte) > > > (< (point) eol)) > > > (if (>=3D (char-after) #x3fff80) ; raw bytes take 2 bytes in the= buffer > > > (setq goal-byte (1+ goal-byte))) > > > (forward-char 1)))) > > > > In eglot-move-to-lsp-abiding-column (the utf-16 sibling of this > > function) we use a binary search instead of a linear search. I remembe= r > > measuring a visible improvement. I'm not sure the conditions are > > exactly the same with this one. Could/should we do the same here? > > Fine by me, but optimizing a method that is not yet used sounds a bit > premature, no? I won't object, though. There's nothing to optimize there, there's no benefit to binary search. I think this type of function, which has some utf-8/16 knowledge directly in them, is the fastest option, much faster than using encode-coding-region like I was doing before. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 08:11:41 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 13:11:41 +0000 Received: from localhost ([127.0.0.1]:42555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWGoX-0007IK-8k for submit@debbugs.gnu.org; Sun, 26 Feb 2023 08:11:41 -0500 Received: from mail-oa1-f54.google.com ([209.85.160.54]:41852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWGoW-0007I7-DQ for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 08:11:40 -0500 Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-172334d5c8aso4886622fac.8 for <61726@debbugs.gnu.org>; Sun, 26 Feb 2023 05:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677417094; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l65oDxKZLl7CXfIpLYJ/xx7nOZjJD/B9DdVzPy9OHNo=; b=iP3XwfxoOeETjQNd6SfG6zURv4ZuuoygZJRonakyROFkv9Tra2E36vW5pcxGBQ2i+1 bLRR4T2rIuhowtZTc/Tuzm6JKyEdjv/Wziw94rDzGGGFlimhLM9A+N4Jitdt5eBEoZqB h2Vufd3mfL4hMuXK+HB75SvQ13EA0Ez4yCPZ+pDf2juhvR8ntMsQtItR0+Ebx8WKaKP5 yNnhRPfmEHCnSJXJ1LieE96Sm78c/1VTjIwDNs65ji+szWtU9CATqb5ani+FpemP55rW 1eEzFau1YyGBGGn3KAPoFBBg0yEdxnyFc3adT6CgEIxYcWrkZkqi1UAycz+yJ0To9TgF ynjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677417094; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=l65oDxKZLl7CXfIpLYJ/xx7nOZjJD/B9DdVzPy9OHNo=; b=VuSYK5Qiojz78aGt/VPoTxUe21IYXa7gc1EJsVA2XGE0UUMv3+XkUMMuAgobibh/hT 6zsogGAajaQUoxdUwnL5VLaWBhBsj/5SMojlroUNYcLksyGfg9EKPayTURNGVGwFPqcb da45dVcAmPu+txWgE1tB/nnA+JyYhUU7W/dSuBmC28oLAzS7ODxr07MAf13KuonOojx7 dw17Y/lBTFoGBnOH+dvrzIXsSX72+Bs/8v1obUPBvupk11moq60UjtjtbtzSrsA09FCk qWD0p9k+DGainzL65Q8l2EBnleLYehaWFO+p9hAFZm+SFA/JI5q14fTtZ1GBFwiQZWwF 6oSg== X-Gm-Message-State: AO0yUKWlmygyMILhRIAPdeNkci+MGpCc/9TypqgPMBew+CP5ZlVVVBpg 4k+GxHAwyGBMi4eoApYEZrPXKCabReRhPg8Ht1I= X-Google-Smtp-Source: AK7set+krXBAftaCkwgLOLM5GfNIfpJFQmCPk50AjhB8jNDz0dkf4sUhjnuCEv7cDSRJ4K/GoYDVe2CN2fVzD5Tc3UU= X-Received: by 2002:a05:6870:3a01:b0:171:8f59:3437 with SMTP id du1-20020a0568703a0100b001718f593437mr2702164oab.8.1677417094718; Sun, 26 Feb 2023 05:11:34 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> In-Reply-To: From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Sun, 26 Feb 2023 13:13:16 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Augusto Stoffel X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Feb 26, 2023 at 10:33 AM Jo=C3=A3o T=C3=A1vora wrote: > So I pushed this much faster, simpler version to emacs-29. > > I credited Eli in the commit, as we wrote the code. Hope > that's OK. Sorry, I meant to write "he wrote the code". But actually Augusto also wrote some of it. So fortunately I also added a "Co-authored-by" note. Anyway, I _also_ did some more stuff: * Pushed the latest patch by Augusto * Pushed a renaming/redocumenting obsoletion-establishing patch. Now Eglot talks of "linepos" instead of "column". * Tested this against actual LSP servers supporting and not supporting the positionEncodings capabilities (clangd, rust-analyzer, pylsp). Have a look and let me know if I missed something important. I think the only thing missing to close this bug is that `eglot--lbpos` ali= as that Augusto proposed. All in all, I'm happy to wrap up this long discussion where I re-learned some coding system stuff. I'm also quite happy to have doubled the performance of one of Eglot's hotspots thanks to a somewhat accidental discovery from both of you, so thank you very much. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 08:16:41 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 13:16:41 +0000 Received: from localhost ([127.0.0.1]:42573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWGtN-0007R4-1E for submit@debbugs.gnu.org; Sun, 26 Feb 2023 08:16:41 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWGtK-0007Qr-Ru for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 08:16:39 -0500 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 1pWGtF-0007HB-Ep; Sun, 26 Feb 2023 08:16:33 -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=6OaRBemx9hZJ78l7r/GfESNCN2Rjr9HEC5HZ64F3p+k=; b=ocf466bWe5OaaqcFO4Du 0Qtm5z/f3wLrQ4HEh1b0JamPCBOxTIeCQ9f2Y4f4wv6BtqsnTbfklOp428wYEXJ89zBxH8bHb7bHF wROTXDUFWa95JL810Ip8DU2FVSWle2IIlMhYOUr31o/ui+3gEFzQ2nhxnEsWtXeAH7Ef1/29YGSqB sATy5xx92YCP7sNTp90wiIFCb5Al59/4/o9+TjOeJQExIyXNIdspXEQovmiGa3egk2mJGanoS4XmJ eyuA45OViw1RyMJIsiVTrwyPBpcbHPwWQsjH7HnYP6fxX6lvGGz/m92mELzRqQBZsDpGQJ5taVCJt gN5aVBHt3X6kAQ==; 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 1pWGtE-0002pv-MX; Sun, 26 Feb 2023 08:16:33 -0500 Date: Sun, 26 Feb 2023 15:16:38 +0200 Message-Id: <83wn44in2h.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sun, 26 Feb 2023 13:13:16 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Sun, 26 Feb 2023 13:13:16 +0000 > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > > Anyway, I _also_ did some more stuff: > > * Pushed the latest patch by Augusto > > * Pushed a renaming/redocumenting obsoletion-establishing patch. Now > Eglot talks of "linepos" instead of "column". > > * Tested this against actual LSP servers supporting and not supporting > the positionEncodings capabilities (clangd, rust-analyzer, pylsp). Great, thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 08:25:22 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 13:25:22 +0000 Received: from localhost ([127.0.0.1]:42586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWH1l-0007ef-QO for submit@debbugs.gnu.org; Sun, 26 Feb 2023 08:25:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWH1k-0007eS-0c for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 08:25:20 -0500 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 1pWH1e-0001Ks-JG; Sun, 26 Feb 2023 08:25:14 -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=QrGSrq4ydGhMjSeebdnTUqh05h5CU3JpSuZT+Fi1lSI=; b=eGOCpimj9vd2L4OzGVUG VxQ8mBtGnuFQ9rMgbqSm0tVkXDAPJG4FX2n9YU1vuDvrbFBc7Q1d233f0dZHrih+7cOS4iFtIp/Xz algj4P5Pmt0oGBM+SmmAsuXkGLOeRBjA4pitpCrK8m3BKoaCIaRd3sF5lHtzXqSW9ZqtdGKWwGONr LxcHHHAGVfEEY5PjuwqiiMgOytmRT65Lmcl1dTB0gT1lYA2uPi/oIga5KBXj1QTenGbfRrr5fkB9L Ntv199VrLhMh/srf644YnuL/cBXVNe9uWnnAy5pZ5nu/z9sfqn+fFAmccZ9J5gauiscPVlKzU8Ot3 77nIca5MYgjm4Q==; 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 1pWH1W-00035l-5a; Sun, 26 Feb 2023 08:25:13 -0500 Date: Sun, 26 Feb 2023 15:25:10 +0200 Message-Id: <83v8joimo9.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Sun, 26 Feb 2023 13:13:16 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Sun, 26 Feb 2023 13:13:16 +0000 > Cc: Augusto Stoffel , 61726@debbugs.gnu.org > > * Pushed a renaming/redocumenting obsoletion-establishing patch. Now > Eglot talks of "linepos" instead of "column". I've corrected a few doc strings to use a more widely-familiar terminology. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 09:15:56 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 14:15:57 +0000 Received: from localhost ([127.0.0.1]:42789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWHoi-0000i0-Iz for submit@debbugs.gnu.org; Sun, 26 Feb 2023 09:15:56 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:42766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWHof-0000hc-3Y for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 09:15:55 -0500 Received: by mail-wr1-f45.google.com with SMTP id j2so3659026wrh.9 for <61726@debbugs.gnu.org>; Sun, 26 Feb 2023 06:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677420947; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=sB6EsleyjUbRyF8j4WAT//3gLhUa4C91S0L3G/IbMZs=; b=MmsXsD7bMQfOmwwZeAbC0AKw2FqDtoDP3z0OQIG5iFvXHE+Ie6eOqD9PAcMp9eDH4D FYxGLuAI+c8+O9Zw8n0Iv2HV6bD21JPC/sQpNCHldDmWWWCwy/UjEVY0ZAgvCJBwDpl2 ALOoxu+MDAe6lDtLb635epp2Wxi7xZJzXLiFh+nF/3RqQmde57KzezJ6oEThiN4njxBe 8ZvtsFi2EduqvvquTjLm9DPy+TW9lsAg3hfffnXvzNIE0PvOczm2pQqv2q8LDzvMbgkI TsuQsITPOXr/i6VWYZHyPtuUsDz7OUg+kAaPWCIQG/rDc42a2ZCHCMeSqSKNQ3ctppPf 6Ubg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677420947; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sB6EsleyjUbRyF8j4WAT//3gLhUa4C91S0L3G/IbMZs=; b=WZesaKZRwhYAE+4DO1jzs4iHnMstbNoMU5LgJOobQ6jKpYtMQ8cf87O7ark1Kzwk7y A3+abaFP0F+wMNQJSLuY2hhyvGu23xsbSKHyJLG60xQ8EsdcA4fsno2gPiznm3fmZz9C cxGZZNRXrdzYuhzWjB8jWhz+1tTCmfUK4gCnJr9JOxbCqkaBg+uvZSZTsqMA2d9bvhSd FE3zg1KuYyoIWAe863c1ziOoaRzfnKj+ioMzxqD/OGcuiQunb5lqwH6e9XGYmE2gi9AD u7PMkoz+LYFfsobHag+LcLGGN3uFd5HO9USfYerv7a+xO2jgwSI9QG4KZITA3tHHAzUq iTeQ== X-Gm-Message-State: AO0yUKWROJsh8iR+1few0Bxh9C3YHALasE5s0iW4Y22cJy+6IL6doRWj YUETTTtfe5pNv13P0OgimlcqE8yr+08= X-Google-Smtp-Source: AK7set8e07HUJqoMckKoE2/n7Mh8f2fEEfJDpFST17VdPQUPg8V1mQDEtvZ0ul4ohIhp3OOdxtRkcw== X-Received: by 2002:adf:dc09:0:b0:2ca:f86a:9643 with SMTP id t9-20020adfdc09000000b002caf86a9643mr1055420wri.0.1677420946769; Sun, 26 Feb 2023 06:15:46 -0800 (PST) Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id o8-20020a5d4a88000000b002c70c99db74sm4451691wrq.86.2023.02.26.06.15.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Feb 2023 06:15:45 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83v8joimo9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Feb 2023 15:25:10 +0200") References: <87a614g628.fsf@gmail.com> <83bkljnpck.fsf@gnu.org> <874jrb9l6d.fsf@gmail.com> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> <83v8joimo9.fsf@gnu.org> Date: Sun, 26 Feb 2023 14:17:39 +0000 Message-ID: <87r0ucpl30.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Date: Sun, 26 Feb 2023 13:13:16 +0000 >> Cc: Augusto Stoffel , 61726@debbugs.gnu.org >>=20 >> * Pushed a renaming/redocumenting obsoletion-establishing patch. Now >> Eglot talks of "linepos" instead of "column". > > I've corrected a few doc strings to use a more widely-familiar > terminology. Thanks, but at one of the corrections is mistaken, so I've fixed it like this. (defvar eglot-current-linepos-function #'eglot-utf-16-linepos - "Function calculating number of UTF-16 code units from line beginnin= g. + "Function calculating number of code units from line beginning. =20=20=20=20=20 This is the inverse operation of `eglot-move-to-linepos-function' (which see). It is a function of This variable is set by default to a function that indeed does UTF-16 calculations. But it can and will be set to one that does UTF-32 or UTF-8 codepoint calculations, depending on the server. I also have a few nits. In your patch: (defun eglot-utf-32-linepos () - "Calculate number of code units to line beginning using UTF-32." + "Calculate number of Unicode codepoints from line beginning." (- (point) (line-beginning-position))) This is strictly true, because in UTF-32 it's one code point per code unit. But the protocol of the variable 'eglot-current-linepos-function', where this function is to be plugged, a code-unit counting function is demanded. I would predict that encoding-challenged programmers (like this package's maintainer in about 2 week's time) might not know about that equivalence and will find it slightly confusing to plug this function into that variable. But as I said this is just a nit. Jo=C3=A3o From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 09:50:52 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 14:50:52 +0000 Received: from localhost ([127.0.0.1]:42902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIMW-0001jP-0d for submit@debbugs.gnu.org; Sun, 26 Feb 2023 09:50:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIMU-0001jD-7J for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 09:50:50 -0500 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 1pWIMO-0002Yf-W7; Sun, 26 Feb 2023 09:50:45 -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=nEa68+yRbG/gKfvKLXg8SWt2x7H6zIId7UHpEAcAujQ=; b=DjCY8b4LbILInxCR4n/F nmtLYGaLhXWEWfKaYTUAwQxVc33kjVjdR2KFG2oOXlBBb9/h8k5li79K7BQcrY+mu10PjYEjrJHBb wT2CT4TjGbv6wFvvoku5H1XEMrc2MHcgKlKUzZ978HObUdx6yMZYW4weqGvuxaTno2Mp3suRfolFQ sswTwUpVh5QjJwzB6HkbCZV93q9ylnuiy479seVjF0oc7lTponnjXjOh9NUWbsdooHWtJUzggQPPc fSe9Ikp1fM/k5Kb+ncm7YLGaCm5YqI92hXe5K3+Uo+dtgjWrRaHqbK/3+Lxj9NeeFJFwpjBla0raS p7Cf5B7bpGh5cA==; 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 1pWILu-0003Ei-Oq; Sun, 26 Feb 2023 09:50:29 -0500 Date: Sun, 26 Feb 2023 16:50:13 +0200 Message-Id: <83r0uciiqi.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87r0ucpl30.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 26 Feb 2023 14:17:39 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <83bkljnpck.fsf@gnu.org> <874jrb9l6d.fsf@gmail.com> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> <83v8joimo9.fsf@gnu.org> <87r0ucpl30.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: arstoffel@gmail.com, 61726@debbugs.gnu.org > Date: Sun, 26 Feb 2023 14:17:39 +0000 > > Eli Zaretskii writes: > > > I've corrected a few doc strings to use a more widely-familiar > > terminology. > > Thanks, but at one of the corrections is mistaken, so I've fixed it like > this. > > (defvar eglot-current-linepos-function #'eglot-utf-16-linepos > - "Function calculating number of UTF-16 code units from line beginning. > + "Function calculating number of code units from line beginning. > > This is the inverse operation of > `eglot-move-to-linepos-function' (which see). It is a function of > > This variable is set by default to a function that indeed does UTF-16 > calculations. But it can and will be set to one that does UTF-32 or > UTF-8 codepoint calculations, depending on the server. > > I also have a few nits. In your patch: > > (defun eglot-utf-32-linepos () > - "Calculate number of code units to line beginning using UTF-32." > + "Calculate number of Unicode codepoints from line beginning." > (- (point) (line-beginning-position))) > > This is strictly true, because in UTF-32 it's one code point per code > unit. But the protocol of the variable > 'eglot-current-linepos-function', where this function is to be plugged, > a code-unit counting function is demanded. I would predict that > encoding-challenged programmers (like this package's maintainer in about > 2 week's time) might not know about that equivalence and will find it > slightly confusing to plug this function into that variable. > > But as I said this is just a nit. I made one more fix. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 10:14:13 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 15:14:13 +0000 Received: from localhost ([127.0.0.1]:44818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIj6-0002nY-Ux for submit@debbugs.gnu.org; Sun, 26 Feb 2023 10:14:13 -0500 Received: from mail-wr1-f51.google.com ([209.85.221.51]:37537) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWIj4-0002nK-5l for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 10:14:12 -0500 Received: by mail-wr1-f51.google.com with SMTP id h14so3763429wru.4 for <61726@debbugs.gnu.org>; Sun, 26 Feb 2023 07:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677424444; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qc1YvCwCQKA1+lLoFwe3XjECgCHEm87vChgGn6RVEps=; b=mbnDe/rFJh+EuZv+bP/lEkMKJT0FAitvsHlF3p0ZjngIsuiWzhW+nn/CBastTBnShh K1fSRlrxucpaBMCp88891kr22c54hk5jHBAcbR5IEvRh8uXQLlkdDiUBNa7GT8tA66tb o40O2HV7GugsSlzgXVm1HDDHnk6bLfpc0BxXUzFP2c4NmxIeAl8hiy8DGnvXuJfhU749 gRTiM0ls9yCZy80NrFsU2cd57q3vFLem/NoevKIaOm6EEaA/bPW7N9RaMv6MkUV3X3mJ EbsRfd22CI68w6YvyUSdncMumSdotXNgUeKH+rZAhLx25FwudTdhQM3Hj/MWiXDuFDEE Kp9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677424444; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qc1YvCwCQKA1+lLoFwe3XjECgCHEm87vChgGn6RVEps=; b=qnocflsucDopSTOPr+3Vc0EcZxtlZVPqIa0PsJVvmRK77/V2cwbkkPqsPymfQ4Co0X QpBo7Ryb2AT7AckahacTk/sRrXS3Fwj/Dd96xO5o7SbWC/F8GVxnrZFG+WKJxLcvTT5t fPu8D4yX7xvUJBWRmfozSxI7hSIKhR0IFOPj9w1IYe/RDMs6xxRgjosBtWHdBSEohOIj OXwmwwAX47NA8/cOL0PVCR8nOf4qpRZdLfkfBak//pr8t8C4WW4BALhSHwiG+k8hGgeA Fj2tisoexXE6EVsozxD5dBZ12VN0rb99K09DbyambuLLes1gcaB1g9j9YUphcdxhuTP0 gLBQ== X-Gm-Message-State: AO0yUKUDPHESm22ISV8LWpnKrypVmVM5CLB2rPneyqi+29X6sOFvtZUM 4UAsgkwwNkBbARuLfuUFyDgbQA50UUo= X-Google-Smtp-Source: AK7set+MlDwuw4egrgjQ0Za5Ivt4ICKrfIih9M2vsXqpvZ5oZoz9+2FY6tYfe+sR6310tE6M61yZ7Q== X-Received: by 2002:adf:fa0a:0:b0:2c7:851:c0bf with SMTP id m10-20020adffa0a000000b002c70851c0bfmr13593643wrr.0.1677424443989; Sun, 26 Feb 2023 07:14:03 -0800 (PST) Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id ay26-20020a05600c1e1a00b003e21f20b646sm6274363wmb.21.2023.02.26.07.14.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 Feb 2023 07:14:03 -0800 (PST) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Eli Zaretskii Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: <83r0uciiqi.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Feb 2023 16:50:13 +0200") References: <87a614g628.fsf@gmail.com> <874jrb9l6d.fsf@gmail.com> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> <83v8joimo9.fsf@gnu.org> <87r0ucpl30.fsf@gmail.com> <83r0uciiqi.fsf@gnu.org> Date: Sun, 26 Feb 2023 15:15:57 +0000 Message-ID: <87zg90o3te.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> But as I said this is just a nit. > > I made one more fix. FTR, I think it's way worse now. The function variable has no clear protocol: it's very odd to state its return type as number of code units _or_ bytes _or_ code points. A good docstring for such a variable notes that, for any buffer position, a plugged-in function must return the same _type_ but may return a different _value_ to match the unit-counting strategy being used by the LSP server. I haven't reverted to avoid a commit war, and because I'm a bit weary of this bug. I leave a patch for consideration and for the record, feel free to ignore it. Jo=C3=A3o diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index dd84f545ed4..12fb72503aa 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -1453,11 +1453,20 @@ eglot--warn (defvar eglot-current-linepos-function #'eglot-utf-16-linepos "Function calculating position relative to line beginning. =20 -This is the inverse of `eglot-move-to-linepos-function' (which see). -It is a function of no arguments returning the number of code units -or bytes or codepoints corresponding to the current position of point, -relative to line beginning, as expected by the function that is the -value of `eglot-move-to-linepos-function'.") +This is the inverse operation of +`eglot-move-to-linepos-function' (which see). The value is a +nullary function that examines current `point' and computes the +number of code units relative to line beginning in such a way +that it matches how the LSP server also counts code units. For +example, if the LSP server is using UTF-16 encoding, and point is +on the \"b\" of a line containing just \"aXbc\" where \"X\" is a +funny looking character in the UTF-16 \"supplementary plane\", +this function has to return 3 code points instead of 2. If the +server is using UTF-32 encoding, this function should return 2 +code points. + +Since LSP 3.17 server and client may agree on an encoding and +Eglot will set this variable automatically.") =20 (defun eglot-utf-8-linepos () "Calculate number of UTF-8 bytes from line beginning." @@ -1496,11 +1505,11 @@ eglot-move-to-linepos-function "Function to move to a position within a line reported by the LSP server. =20 Per the LSP spec, character offsets in LSP Position objects count -UTF-16 code units, not actual code points. So when LSP says -position 3 of a line containing just \"aXbc\", where X is a funny -looking character in the UTF-16 \"supplementary plane\", it -actually means `b', not `c'. The default value -`eglot-move-to-utf-16-linepos' accounts for this. +code units, not actual code points. The default is to use UTF-16 +encoding, so when LSP says position 3 of a line containing just +\"aXbc\", where \"X\" is a funny looking character in the UTF-16 +\"supplementary plane\", it actually means \"b\", not \"c\". The +default value `eglot-move-to-utf-16-linepos' accounts for this. =20 This variable can also be set to `eglot-move-to-utf-8-linepos' or `eglot-move-to-utf-32-linepos' for servers not closely following From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 26 10:37:46 2023 Received: (at 61726) by debbugs.gnu.org; 26 Feb 2023 15:37:47 +0000 Received: from localhost ([127.0.0.1]:44847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWJ5u-0003Ov-IQ for submit@debbugs.gnu.org; Sun, 26 Feb 2023 10:37:46 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWJ5t-0003Oj-28 for 61726@debbugs.gnu.org; Sun, 26 Feb 2023 10:37:45 -0500 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 1pWJ5n-0005Yz-LC; Sun, 26 Feb 2023 10:37:39 -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=BVv7iTT5XY0tpPqX/gbpTETZ9saIryFkByqLFvXVAQQ=; b=LVk6sN762Ui+RNvvV4Ws c5dGsHJy8UgS8T+w9Unx6g8fiwdaoBjPks0uSA27GkiUzGQILXOSQuA25YKCqk1OMjrgyyVmHqrdS 88sAiY2A3ZUK/o4zty5wxYJVpEfVzgtuNc195ebVgKMu+Yo3lZ6TcNoOlskmKHErvs4bXpevyDYMW U5YEWtDykThpHut4nLjtyABPoW//YTr7jeyVgwMcKiKAOXlksL4n4+2le5wW7+3jtXpprqgOkPsWP lOJcnlRB+0MqU5UjT3ezEv6vM9UBRBI48al2EfnhrzASp049Bh8IyeFE+oybZNdunQkGoTM+WW7e1 pVYnI5uyDZ9cHw==; 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 1pWJ5l-0008UE-RZ; Sun, 26 Feb 2023 10:37:39 -0500 Date: Sun, 26 Feb 2023 17:37:42 +0200 Message-Id: <83mt50igjd.fsf@gnu.org> From: Eli Zaretskii To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= In-Reply-To: <87zg90o3te.fsf@gmail.com> (message from =?utf-8?B?Sm/Do28g?= =?utf-8?B?VMOhdm9yYQ==?= on Sun, 26 Feb 2023 15:15:57 +0000) Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <874jrb9l6d.fsf@gmail.com> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> <83v8joimo9.fsf@gnu.org> <87r0ucpl30.fsf@gmail.com> <83r0uciiqi.fsf@gnu.org> <87zg90o3te.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Cc: arstoffel@gmail.com, 61726@debbugs.gnu.org > Date: Sun, 26 Feb 2023 15:15:57 +0000 > > Eli Zaretskii writes: > > > >> But as I said this is just a nit. > > > > I made one more fix. > > FTR, I think it's way worse now. The function variable has no clear > protocol: it's very odd to state its return type as number of code units > _or_ bytes _or_ code points. A good docstring for such a variable notes > that, for any buffer position, a plugged-in function must return the > same _type_ but may return a different _value_ to match the > unit-counting strategy being used by the LSP server. It cannot return the same value,. it must return a value in the same units as its opposite. The doc string says: This is the inverse of `eglot-move-to-linepos-function' (which see). It is a function of no arguments returning the number of code units or bytes or codepoints corresponding to the current position of point, relative to line beginning, as expected by the function that is the value of `eglot-move-to-linepos-function'.") Note the last sentence. > I haven't reverted to avoid a commit war, and because I'm a bit weary of > this bug. I leave a patch for consideration and for the record, feel > free to ignore it. It's your package, so feel free to make any changes you like. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 05:11:14 2023 Received: (at 61726) by debbugs.gnu.org; 27 Feb 2023 10:11:14 +0000 Received: from localhost ([127.0.0.1]:46074 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWaTS-00072f-EI for submit@debbugs.gnu.org; Mon, 27 Feb 2023 05:11:14 -0500 Received: from mail-wr1-f41.google.com ([209.85.221.41]:33698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWaTR-00072S-AF for 61726@debbugs.gnu.org; Mon, 27 Feb 2023 05:11:13 -0500 Received: by mail-wr1-f41.google.com with SMTP id v16so2776404wrn.0 for <61726@debbugs.gnu.org>; Mon, 27 Feb 2023 02:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=uW0NF/lonJH2J2VbnJ+UOz5jt46Ijx3mnMTWgPPzPaQ=; b=gdCxeP+Uq2uMADx2vlrWJosVEF6TOZ6t/58tjHIGGDOOJZWkfec6tr8cPv0/1uqyOi UoinleOZC3fvU7ba2Ay5Ady9I/CaUMjNvefSXMgFfYYQWr1u0mH84JsnqWfgyftBV8KX KmpbJsZPNPDbE0ktj/U7bMjY/TWizZtZ7a8Yzrrt60e04ghjyTweJb8SOZFkzz93a+3/ D7MFV0xJOAytDrVpFH7q1+Bt55PmhNt4xnJyPZ2KUAY83UENaz4kHITEkHDEuqfV5DVx F1kPJnRnC3CKZf0V9u+n+oTHHiflD7f/2+GAxJVGiK9fNlMY4PCcA/syk2wim7vyN0Xr 1yOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:face:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uW0NF/lonJH2J2VbnJ+UOz5jt46Ijx3mnMTWgPPzPaQ=; b=Mo/XPkfAVJGbqfW4cFxHMvvhvQtimDokG6Lv4DF9OY3eLPNLmn/k47BYVLydkYSTMt UPYBuw43vd4RNd5h/asKGCOBR9wrbb0P/p+xDIsgjDjvsP9SIw8CdLv4WzLjYXf6mwdv jBGL5W1nTyc2E9jK/M635EsnE/dJggtTXuhpehXcfGmjjHT2irvSFygXbrlZ+tP/evuj ql2vHLCo3XfqdJgPaE/YXHVTu62sD81rjDohXXTxpLawtSzuUfwpllUkx17URUr6sJVl 6r4KL8OBpK+s0iy52lqG+/ZEImzClf737Wg+Pu6ibdcqvvFLUziDrSVit+xyNAAS5uyj r/3Q== X-Gm-Message-State: AO0yUKXFIWXlYR1iVKu6xTUgVkDmyz3OE2U9ViEN/zFdl/ugE/xHB9qG 7CbwXfLqYXk7WNSTCMtjjN0= X-Google-Smtp-Source: AK7set9EWF3drutrCuC3IlnA2k1jWtM6qW3iwK4b8ynmdHms2fbbe/nKRSxQTbIMJdlTCPA1zcCDfQ== X-Received: by 2002:adf:fc8b:0:b0:2c9:6562:232b with SMTP id g11-20020adffc8b000000b002c96562232bmr5297129wrr.2.1677492667413; Mon, 27 Feb 2023 02:11:07 -0800 (PST) Received: from betli.gmail.com (catv-86-101-66-128.catv.fixed.vodafone.hu. [86.101.66.128]) by smtp.gmail.com with ESMTPSA id fm26-20020a05600c0c1a00b003e6dcd562a6sm8868923wmb.28.2023.02.27.02.11.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Feb 2023 02:11:06 -0800 (PST) From: Felician Nemeth To: Augusto Stoffel Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability References: <87a614g628.fsf@gmail.com> <87y1oofh8w.fsf@betli.tmit.bme.hu> <87pma0dy0a.fsf@gmail.com> Date: Mon, 27 Feb 2023 11:11:06 +0100 In-Reply-To: <87pma0dy0a.fsf@gmail.com> (Augusto Stoffel's message of "Thu, 23 Feb 2023 19:42:29 +0100") Message-ID: <87wn43e7ut.fsf@betli.tmit.bme.hu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEX5+fmhoaEwMDD/ ///TMNVWAAAAAWJLR0QDEQxM8gAAAAlwSFlzAAAPEgAADxIBIZvyMwAAAAd0SU1FB+AICBUfHgLs gGoAAAGXSURBVCjPRdK/b5tAFAfw753gBEwM2ApMbuVIqf+Ko0qiyhOu4sj2xJBYMn/FUdX7UUUZ OjHgyvf+yj6IcW6Bjx53934ADEvs8bmEr8UVoTYTOyJO9KoYsVofN8kILdbeJ8Li6YpZWop4xOK0 VdfIoXmkHn5/5D7/Ts/8THacSqnkKTcMTxgUkVzFnEIRTKwwYYSCvzfg16f0i8YApW/XG/Pm8R49 dXjxKmRnxv3OwooQWcv4RUYem1fsNe/WU63uk7AmYxk78y32/ee2tZB4fO+WcZ7lnIGEolXW1EGw LfkSuQ0XTgRefgNlfNwRNV6QhBxJ8JNxTMUPyBqTd0bjaAP5G7NJRU39z80hLOZTjqB7K3tEEFSj aEsuQew6qBxxyhHjVUR7H7NpC9iHJZGLMCEuweqAqE1BHbfK2oRIz9EHYA/+wiFWru9smeVfuWNZ 2+NFtX80UA1TvJNdytM4DwO4kY7bJz8Qcd0G0ceslZGkkeoBsjUHwF1+jjM3XHaXEZ7mGLfwPFO+ RV9QLY2iEdmDo78D/gNPaXVYqd+pyQAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAxNi0wOC0wOFQyMzoz MDoyOCswMjowMGy/yHYAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMTYtMDgtMDhUMjM6MzA6MjgrMDI6 MDAd4nDKAAAAAElFTkSuQmCC MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: 61726@debbugs.gnu.org, Eli Zaretskii , =?utf-8?B?Sm8=?= =?utf-8?B?w6NvIFTDoXZvcmE=?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Augusto Stoffel writes: > This is intentional, so let's see if you agree with my rationale. You have mostly convinced me. I also see the patch developed further in the mean time. >> (In the long run, it might make sense to let the list of the offered >> encodings configurable.) > > I don't think I understand why. We would already be offering all 3 > positionEncoding options. The server can pick whatever they like and > we'll deal with it. Everything should "just work", no need for > configuration. When the eglot-{current-,move-to-}column-functions will be removed, the users won't be able to adjust the behavior of Eglot to cope with defective servers. However, this adds complexity for the sake of an unlikely hypothetical case. So now I agree with you that this is unnecessary. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 06:13:24 2023 Received: (at 61726-done) by debbugs.gnu.org; 27 Feb 2023 11:13:24 +0000 Received: from localhost ([127.0.0.1]:46226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWbRc-0002ir-4M for submit@debbugs.gnu.org; Mon, 27 Feb 2023 06:13:24 -0500 Received: from mail-oo1-f47.google.com ([209.85.161.47]:34554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWbRa-0002iU-V7 for 61726-done@debbugs.gnu.org; Mon, 27 Feb 2023 06:13:23 -0500 Received: by mail-oo1-f47.google.com with SMTP id p8-20020a4a3c48000000b0052527a9d5f0so932504oof.1 for <61726-done@debbugs.gnu.org>; Mon, 27 Feb 2023 03:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677496397; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jRVMCAWmJPQYX1o1li4jc9G1hZvLqYHdgvXg1rOZ1XE=; b=lstAb8TdBlea2xbyVqW0a1IlR9EfNzz6SjLpsrnaQSXDMg3wFdbdIjmf8uZjk0Ui+T nfDTttb/OQBR4/w4MesZkS2ElQ/Wud+0WXKfoL1uz1gFsLMHuJLRBHvVmT7RRXfUISFp c27D8FIlF2N3PBio5V+wLH+fcZ29soN5OtjcjT2BMv2oqEdchjjjXnwTOBMS0GvSla5a FIxWR7PSJbpRPl+UY2FRjZDZTgbvJ5gDBj/y84bqciKJ6yrk3j0LaX76FzrbLkKHuBrl Y9zgGyfYQagw9MLO2EJTBEUaBcu1Gt+GkQxc/NcOdvkinT4BVSf8vaLKOupffsVYpjpA p2bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677496397; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jRVMCAWmJPQYX1o1li4jc9G1hZvLqYHdgvXg1rOZ1XE=; b=eV9slHJn7G8SVldFB8Vgu2+VQ3Ui2C1nn2TOkKklBWBmBqRAvRf80Y11tV76sz8utu 9XDop+LK28F/Bps5oqiCEC4qqYcH4qz1hmUlK3tcHsLOMrxjFCSdOdePQV+Den+477x2 KK3RgI70ESrVRET84XdoRu4b31CCQhuapXw9JrvpY1LzmiWlXIsWe5OxZwNdXfkJmu1w q0Z8Gk3mEGkYH+FyWJFO/mxGh5BSGm6t/AS9HNxe++WoSJazFaMAxUkjS/2BYuOujLDc ir/wUCgt5pt2sS9qEVAzfNAkZrO1bYLTR6t1/3DaNydSTxq4SzD0Rbj7ScOOUAT4Ez0d WJiQ== X-Gm-Message-State: AO0yUKWdTb1BDZ+15w3U9u26IAbJODy8ewEhbUpcFJY1utLnziqQHOYV LrsTyXQ7U08Fd1juyZhFaZDOyHlfZH9Idm200VI= X-Google-Smtp-Source: AK7set8Q+WNecN7Fr78imcMZl2Aaw1hoN+616BPIwwBt4b+T8OVyyexUnSLPiQAxcVKUST7yJ2Fq0Pchz37T7ZR+IAk= X-Received: by 2002:a4a:11c1:0:b0:525:54b6:dac1 with SMTP id 184-20020a4a11c1000000b0052554b6dac1mr2090616ooc.1.1677496397315; Mon, 27 Feb 2023 03:13:17 -0800 (PST) MIME-Version: 1.0 References: <87a614g628.fsf@gmail.com> <874jrb9l6d.fsf@gmail.com> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> <83a612ko73.fsf@gnu.org> <87ttza3rwh.fsf@gmail.com> <83356tluvq.fsf@gnu.org> <87a61125ox.fsf@gmail.com> <83wn45k8yu.fsf@gnu.org> <874jr9z94m.fsf@gmail.com> <87y1olv0h1.fsf@gmail.com> <87sfetgux5.fsf@gmail.com> <83pm9xj74q.fsf@gnu.org> <83v8joimo9.fsf@gnu.org> <87r0ucpl30.fsf@gmail.com> <83r0uciiqi.fsf@gnu.org> <87zg90o3te.fsf@gmail.com> <83mt50igjd.fsf@gnu.org> In-Reply-To: <83mt50igjd.fsf@gnu.org> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Mon, 27 Feb 2023 11:15:00 +0000 Message-ID: Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability To: Eli Zaretskii , 61726-done@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 61726-done Cc: arstoffel@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Feb 26, 2023 at 3:37=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Cc: arstoffel@gmail.com, 61726@debbugs.gnu.org > > Date: Sun, 26 Feb 2023 15:15:57 +0000 > > > > Eli Zaretskii writes: > > > > > > >> But as I said this is just a nit. > > > > > > I made one more fix. > > > > FTR, I think it's way worse now. The function variable has no clear > > protocol: it's very odd to state its return type as number of code unit= s > > _or_ bytes _or_ code points. A good docstring for such a variable note= s > > that, for any buffer position, a plugged-in function must return the > > same _type_ but may return a different _value_ to match the > > unit-counting strategy being used by the LSP server. > > It cannot return the same value,. it must return a value in the same > units as its opposite. I wrote "return the same _type_ but may return a different _value_". The doc string says: > > This is the inverse of `eglot-move-to-linepos-function' (which see). > It is a function of no arguments returning the number of code units > or bytes or codepoints corresponding to the current position of point, > relative to line beginning, as expected by the function that is the > value of `eglot-move-to-linepos-function'.") > > Note the last sentence. Yes, I understand the intention. That's a good detail, to state that when that other function is fed the return value of this one, position should remain unaltered. I just did that. > It's your package, so feel free to make any changes you like. Done, and closing. We can deal with the `line-beginning-position` thing afterwards. It's only tangentially related to this encoding-supporting fea= ture. From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 05 05:26:14 2023 Received: (at 61726) by debbugs.gnu.org; 5 Mar 2023 10:26:14 +0000 Received: from localhost ([127.0.0.1]:38548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYlZG-0001Wv-26 for submit@debbugs.gnu.org; Sun, 05 Mar 2023 05:26:14 -0500 Received: from mail-ed1-f54.google.com ([209.85.208.54]:33622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pYlZE-0001Wh-0C for 61726@debbugs.gnu.org; Sun, 05 Mar 2023 05:26:12 -0500 Received: by mail-ed1-f54.google.com with SMTP id a25so27386658edb.0 for <61726@debbugs.gnu.org>; Sun, 05 Mar 2023 02:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678011965; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1xbs4nFuedOD+9mfIF8R7cFevOs2OjvWTqMuqfldTHI=; b=bhcTehoUHUt4HHAe6SxHZjH7MBMO/P4jhs7Y1YtGa6wCGyM8GUHAejTuORgGVEeQz0 jrwfOvvhSE7Cu8eGfdl+1CBreUYieRxpKyGZbQ7pHOOPIctR0RaLKGbZQ7o2w3ZtOq/Z psrBftdM8rs5a1wbh8C0C5bzptPuxbCpWrrSUPycx69DgSCPOIV1JHXPRujAd/hAFRWG DCeDVRcRiSVPRbZjsOerDgCEQS2+vrln7c91tbQUqRtqYnHGX4wNXktpobgXnnCX73Ot AuuINpB7YKLAhcIR1FZ52kdadGWeSPGLX/Mu6jvDjbP7O1kUkBb5ytPyZrMvGN8WupbQ c+qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678011965; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1xbs4nFuedOD+9mfIF8R7cFevOs2OjvWTqMuqfldTHI=; b=C/nqu0XEsyyq2hkJcYzbgodqrcMU/tubjb9O2zhEv6dlHrii9Ly73pNzy6LcNeNSsT nDwWOyvRpfG1RN+N3NpVGu0XiC/l4zLFqcw325H2zZfrgwx1C9c7ZjGlEN29Kczoecj8 crhb9gNAQCvvD0OI8G8n8soeOqnZb/0iT7uoyJBqSLRHYZZyWRESBTVxt7BwAMKepwKX otin4iEZk25ex6F/ncy9eMUgtLgOqWKQK04ZVyTJuJJkzc3xyat+CaXTFXLvWeTPp8oX kOVRIuQmFM4OrDAzqxdZibMxXDuLsPjYmCPjg9wvX7SnUuhm4FNuhcbYmvLJBTCD2y9J 3dvw== X-Gm-Message-State: AO0yUKWiqqaHqDSwPcR9ugEsO+Am7Como+QFX6C+VXA26fWgZWuqkboK A4xwIyY4ny6V2gCKWZxMxUDu71JH79uNcA== X-Google-Smtp-Source: AK7set8jI3kEO/aX1tGzGqBt1BkBtAKTRgj49uu7Sv8BFDabc+3L3JwKSLbxqaJ1lRX5A48OBDzdZQ== X-Received: by 2002:a17:906:c001:b0:8b2:d70c:34ae with SMTP id e1-20020a170906c00100b008b2d70c34aemr7679839ejz.71.1678011965446; Sun, 05 Mar 2023 02:26:05 -0800 (PST) Received: from ars3 ([2a02:8109:8ac0:56d0::8b3a]) by smtp.gmail.com with ESMTPSA id z92-20020a509e65000000b004bc11e5f8b9sm3482979ede.83.2023.03.05.02.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Mar 2023 02:26:04 -0800 (PST) From: Augusto Stoffel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#61726: [PATCH] Eglot: Support positionEncoding capability In-Reply-To: (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vora=22's?= message of "Fri, 24 Feb 2023 18:55:18 +0000") References: <87a614g628.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> <834jrbnlaf.fsf@gnu.org> <87v8jr83ic.fsf@gmail.com> <83v8jrm4r0.fsf@gnu.org> <87fsav7x81.fsf@gmail.com> Date: Sun, 05 Mar 2023 11:26:03 +0100 Message-ID: <877cvvh4uc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61726 Cc: Daniel Mendler , Eli Zaretskii , 61726@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 24 Feb 2023 at 18:55, Jo=C3=A3o T=C3=A1vora wrote: > On Fri, Feb 24, 2023 at 6:08 PM Augusto Stoffel wro= te: >> Lastly, I used 'line-beginning-position' naively in the 2 new function >> because there are at least 4 other pre-existing naive uses in eglot.el. >> This refinement deserves a patch of its own, probably using something on >> the lines of >> >> (defalias eglot--pos-bol (if (fboundp 'pos-bol) 'pos-bol ...)) > > This is also a good idea. Actually, it might be better to use the compat library. I'm copying Daniel to ask if that is possible/recommended for "core" packages. I imagine adding compat to the Package-Requires and calling (require 'compat nil 'no-error) would work? From unknown Mon Aug 18 02:38:52 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 02 Apr 2023 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator