From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#59149: [SPAM UNSURE] Re: bug#59149: Feature Request: Report progress of long requests in Eglot Date: Thu, 24 Nov 2022 14:16:18 +0000 Message-ID: <87o7swv3nx.fsf@gmail.com> References: <87educqkar.fsf@dfreeman.email> <86cz9jmg9r.fsf@stephe-leake.org> <87k03qvmla.fsf@dfreeman.email> <86fseckwvb.fsf@stephe-leake.org> <87tu2pohub.fsf@dfreeman.email> <86ilj5k0sn.fsf@stephe-leake.org> <87wn7l316m.fsf@dfreeman.email> <86edtsk3xi.fsf@stephe-leake.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6890"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 59149@debbugs.gnu.org, danny@dfreeman.email To: Stephen Leake Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 24 15:16:25 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyD1d-0001Yu-4j for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Nov 2022 15:16:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyD1P-0000iO-5M; Thu, 24 Nov 2022 09:16:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyD1K-0000hR-Ow for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2022 09:16:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyD1G-00080b-9y for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2022 09:16:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oyD1G-00062G-4x for bug-gnu-emacs@gnu.org; Thu, 24 Nov 2022 09:16:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Nov 2022 14:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59149 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: 59149@debbugs.gnu.org, bug-gnu-emacs@gnu.org, Danny Freeman Original-Received: via spool by 59149-submit@debbugs.gnu.org id=B59149.166929932123136 (code B ref 59149); Thu, 24 Nov 2022 14:16:02 +0000 Original-Received: (at 59149) by debbugs.gnu.org; 24 Nov 2022 14:15:21 +0000 Original-Received: from localhost ([127.0.0.1]:57774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyD0a-000614-K3 for submit@debbugs.gnu.org; Thu, 24 Nov 2022 09:15:21 -0500 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:36716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyD0P-00060R-PL for 59149@debbugs.gnu.org; Thu, 24 Nov 2022 09:15:10 -0500 Original-Received: by mail-wr1-f45.google.com with SMTP id z4so2677256wrr.3 for <59149@debbugs.gnu.org>; Thu, 24 Nov 2022 06:15:09 -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=+Vc4gycU16jeMoKRqlKXHoBluA7lhkKyt5FtZpFjFSI=; b=dt/kUOsWhgl3Eduzt9I0Wzvj426drNbIOnOsQOJd09HuVpRuhtJghcA7byZu9YmbIf ubwe5P4mbc3efpKceD9ZgoM0IgX+1nrbKDRjob2NVRziBxfkmizfl19ZfBmBd5ZUY0Au uwlQd5PFElaiSEMTJFsmqZwopkML6FxQzo0Ha/ojkBnoe6XpQnUZ+jjquBLeWP9Dg7eM lmgLPwdMwAYDqZIrbCuNVeFY/WYsmWrQhvPMEuhyCpns7jJHDYdpNuag7sEiXMQvt7XC AcNBflZWu4TWqfToRa8TAokt1FFVrxK5gwKd9jZNczW8NHQxqFwwZRle50Cj3aBDkFRM dmaw== 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=+Vc4gycU16jeMoKRqlKXHoBluA7lhkKyt5FtZpFjFSI=; b=Eyk3LmlS53Y/tRBtlPmqOetvYFnuYbUTEFJJ/wgJPu/+imrijLccVBbfgxCdafpKbM E9mjRZYLbIBjyOJGW11qtHiX0R7ueR4Yi5ssW+hnYtefM0IfbHW0s5CX6mmAPaPCiWln iw9orZh00yD4PiqJGo/ZX6y4esn+vyurZEwmBEIv1gbEe9x2p2i5lT5UhJl12qrSLwxN 00Jch59mwoFtiUv0C6wH3ryuhq+qizbB9v8tLW9nFHgoBLvdnJ+Z1bEVnO8l773xhawI 5ceQUBHKR35hao6gd5H61s1aS/rdI8TYxct+pymSELGy9rqT/9897HtTxNCFlgD36Ssz G1xA== X-Gm-Message-State: ANoB5pkxYUvUzMTpOq+x7fe9L+Bp5F/h2MuqjzHTDO8MUZhnm6u/KWKb byksnY4miUk5fZbp0H2bUNE= X-Google-Smtp-Source: AA0mqf6d23iu3Dwpq71k+25xmBN9AOK/FQLd0A9Zy65UgGdKEbN955SJObQmcCe2BIuLpEniS47k6g== X-Received: by 2002:a5d:46c2:0:b0:242:145:3b7a with SMTP id g2-20020a5d46c2000000b0024201453b7amr1041350wrs.331.1669299303803; Thu, 24 Nov 2022 06:15:03 -0800 (PST) Original-Received: from krug ([87.196.72.177]) by smtp.gmail.com with ESMTPSA id p1-20020a1c5441000000b003b4cba4ef71sm5637709wmi.41.2022.11.24.06.15.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Nov 2022 06:15:03 -0800 (PST) In-Reply-To: <86edtsk3xi.fsf@stephe-leake.org> (Stephen Leake's message of "Thu, 24 Nov 2022 03:06:01 -0800") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248866 Archived-At: Stephen Leake writes: > Jo=C3=A3o T=C3=A1vora writes: > >> On Wed, Nov 23, 2022 at 7:45 PM Danny Freeman wro= te: >>> >>> >>> Stephen Leake writes: >>> >>> I am copying him on this email, as I realize he wasn't on this branch of >>> the email chain. Jo=C3=A3o, please see the previous emails in the threa= d for >>> more context! Here is a link for convenience: >>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-11/msg01619.html >> >> Yep this is all news to me, but no problem, I just read through the chai= n. >> >> If, like Stephen says, $progress is part of the base protocol, then ther= e's >> no capability associated indeed, but I think we should just make up one >> like `:$progress`, and use change eglot--server-capable-p to be able >> to respond unequivocally 't' to those special built in capabilities, but >> only after checking if they're not in the eglot-ignored-server-capabilit= ies >> list. > > One way to do that is to simply add (:$progresss t) in eglot--connect > where eglot--capabilities is set. Yes that would probably do it as an implementation trick. > But apply-text-edits creates a progress reporter that is not driven by > messages from the lsp server; it's just processing a local list of > edits. And I would like to be able to turn that off, but keep (at least > some of) the lsp progress messages. > > LSP capabilities handle this by adding items in categories, so we could > add (:$progress (:apply-edit t)) to eglot--capabilities, and then I > could add :apply-edit to eglot-ignored-server-capabilities. We'd have to > do the same for any other progress message somebody wants to turn off. > > Except that would also turn off apply-edit itself, not just the progress > messages for it; it seems we need to allow > eglot-ignored-server-capabilities to contain (:$progress :apply-edit). > Or use :apply-edit-progress instead. At this point, I'm not sure the eglot-ignored-server-capabilities is the right tool for the job. In fact, even my original suggestion is a bit sketchy, because it is creating these pseudo-capabilities that don't really exist. Abusing it even further is probably not good. So, here three possible things we can do: 1. Get rid of the :apply-edit progress reporter entirely. To be honest, I don't think it's doing much. We could just as well have a call to message there, or nothing at all. 2. Do my original "sketchy" suggestion, where :$progress is considered a built-in ignorable capability (and checked with eglot--server-capable in the new code that Danny is proposing). Stephen's eglot-connect trick is an acceptable technique. 3. Add a boolean user varible eglot-report-progress. I don't like to add user variables unless they represent things directly related to the fundamental LSP logic, and not its customization or evolution. Since this seems to be of those fundamental things, I think it's acceptable. The alternatives are: a: 1+2 b: 1+3 c: 2 d: 3 Stephen, you request to shoosh that particular apply-edits progress reporter is another separate request, we shouldn't let it block Danny's effort to support $progress messages. So I think we should do either 'c' or 'd' for now, and we can always address your request later. Jo=C3=A3o