From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: emacs-29 44ebd9cbd56 2/2: Eglot: explain how to update Eglot in manual (bug#62720) Date: Sat, 29 Apr 2023 09:08:22 +0000 Message-ID: <87v8hfm4xl.fsf@posteo.net> References: <168263878553.23108.4718240877999827191@vcs2.savannah.gnu.org> <20230427233949.44D31C22A13@vcs2.savannah.gnu.org> <20f53b0a-d6ff-8ec0-2f8c-e0e22b2d49dc@gutov.dev> <83bkj8sjv4.fsf@gnu.org> <87cz3oaxsq.fsf@posteo.net> <8bbac559-396d-531e-e282-ed6b319cd99b@gutov.dev> <87jzxvg9kx.fsf@posteo.net> <4624e69a-6b29-e807-328d-e0b36259de9e@gutov.dev> 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="12074"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, joaotavora@gmail.com To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 29 11:08:39 2023 Return-path: Envelope-to: ged-emacs-devel@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 1psgZK-0002x2-FA for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Apr 2023 11:08:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1psgYf-0004VM-1z; Sat, 29 Apr 2023 05:07:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psgYd-0004V8-A7 for emacs-devel@gnu.org; Sat, 29 Apr 2023 05:07:55 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1psgYa-0000Zh-WC for emacs-devel@gnu.org; Sat, 29 Apr 2023 05:07:55 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A4549240252 for ; Sat, 29 Apr 2023 11:07:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1682759270; bh=oI+L0boyL+rv5OgCung79x0x8VG9sCciDh7WQx/2oWM=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=hRUVShocs17xAWm3BzBVb7Jy6n4VbCdr9bgbNlklwrj+pJp6cwMm4uA3fhDo+4qEZ R7ol7S2NalS+uXjHCBjq0/V5oyK2nPuWS8H4GaO2s0H28uP/+nvF686O/7iAGgU6XZ ZVyRDdWilty6LotM+qzkrcseb/4ZAL3FLjq9wreqD+xY5gpZqG0PRfZrgP7yItHb1Q QH6mNjmMQn6P45U6zYFOwlFz8blG6V11T5Lt5I0xBbFh3cRfiCCGELLJvgQa8oGIIr Auq0teqjcffjAvZtEuzS/7nW9JCjs6UUy97k+G931Y2i+ki7DHH9Q/QMotN5pvnmB0 s8UrzDFbuTFsg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Q7kC94fbSz6tvt; Sat, 29 Apr 2023 11:07:49 +0200 (CEST) In-Reply-To: <4624e69a-6b29-e807-328d-e0b36259de9e@gutov.dev> (Dmitry Gutov's message of "Sat, 29 Apr 2023 03:52:48 +0300") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305710 Archived-At: Dmitry Gutov writes: > On 28/04/2023 21:12, Philip Kaludercic wrote: >> Dmitry Gutov writes: >>=20 >>> On 28/04/2023 17:25, Philip Kaludercic wrote: >>>> Eli Zaretskii writes: >>>> >>>>>> Date: Fri, 28 Apr 2023 02:52:56 +0300 >>>>>> From: Dmitry Gutov >>>>>> >>>>>> Hi! >>>>>> >>>>>> On 28/04/2023 02:39, Jo=C3=A3o T=C3=A1vora wrote: >>>>>>> * lisp/progmodes/eglot.el (eglot-update): New command. >>>>>> Should it be called eglot-upgrade now as well? >>>>> No, it should be removed. >>>> 1+ >>> >>> This doesn't sound very constructive at this point. >> It is difficult to be constructive here. I believe that the >> long-term >> complications/confusion of introducing this kind of a command instead of >> instructing users on Emacs 29 to update a package like Eglot manually is >> not worth it, while others do. These matters are difficult to quantify, >> so we cannot reach a consensus by pointing to some objective reality, >> and instead of have to fall back on personal impressions and >> experiences. I have a hunch that Jo=C3=A3o as the maintainer of Eglot is >> over-exposed to people who are interested in having the absolutely >> newest version so they can make use of the absolutely newest features, >> while most people I know, personally or online, that make use of Eglot >> barley bother to configure it at all (I consider that to be one of the >> major setting points for the package, btw). Comparing other >> configurations I have seen online, I actually think that what I have in >> my init.el is a lot: >> --8<---------------cut here---------------start------------->8--- >> (setup eglot >> (setopt eglot-autoshutdown t >> eglot-extend-to-xref t >> eldoc-echo-area-use-multiline-p nil >> eldoc-idle-delay 0.1) >> (:bind "C-c a" #'eglot-code-actions >> "C-c z" #'eglot-format >> "C-c r" #'eglot-rename) >> (:unbind [remap display-local-help])) >> --8<---------------cut here---------------end--------------->8--- > > But that's the thing: upgrading to a recent version of Eglot is not > only for the more advanced user. Those can easily go the 'M-x > list-packages C-s eglot i x' route. > > It is those who do the minimum customization and/or are just > introduced to Emacs, can miss out with more likelihood the longer the > steps to upgrade Eglot are going to be. Perhaps, but I don't think that eglot-update/upgrade is a necessary improvement from that perspective. > The newest version of Eglot is not just the latest shiny, it's also > the most recent mapping of modes to language servers, for example. Or > mapping of Emacs features to LSP capabilities.=20 I am afraid I don't get what you mean here? Could you give an example? > And Emacs 29 will > continue to be installed and used 3-5-7 years after its release, where > some of this stuff will definitely get outdated. If we fixed > package-upgrade, that could be easy enough, but 'M-x eglot-upgrade' > can be a comparable alternative. What do you think about the approach of adding package.el to ELPA, and then being able to fix the issue of package-upgrade/install that way? On a related-topic: Shouldn't major modes modify `eglot-server-programs' instead of centralising all the information in eglot.el? If that were the common practice, then it would be a lot easier to propagate new information about the best language servers to use. >> Just thinking about introducing a command that we right-now plan to >> deprecate by the next release is not something I look forward to. > > It would probably be deprecated only several major versions later. Not to my knowledge? >> Even >> just promoting the concept of having a package-specific upgrade command >> is something I am a afraid of (it took for ages for third-party packages >> to stop adding pointless `foo-version' commands). And I might have >> missed something here, but none of this would tackle the "central" issue >> of use-package not installing the newest version of a package if the >> package is already built-in, but hasn't yet been installed before. > > I don't know if it's "central": according to the docs, (use-package > eglot :ensure t) is only meant to ensure that Eglot is > installed. Whether that means the very latest version at the time the > configuration is first run, or not, seems a matter of opinion. In that case we agree. I believe Jo=C3=A3o held a different opinion, but as I was not able to follow the discussion over the last week in detail I might have missed something.