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#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Wed, 19 Apr 2023 15:04:30 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <875y9yfxrr.fsf@gmail.com> <87y1muefks.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <06d29dbd-0b33-8698-bcb8-c89368612f54@gutov.dev> <252e77fb-9657-a5be-2e86-234f7b05d162@gutov.dev> <83edog84cm.fsf@gnu.org> <834jpc805p.fsf@gnu.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="8786"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, dmitry@gutov.dev, monnier@iro.umontreal.ca, larsi@gnus.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 19 16:05:50 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pp8RR-000230-T8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Apr 2023 16:05:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pp8Qr-0008ES-5R; Wed, 19 Apr 2023 10:05:13 -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 1pp8Qh-0008DX-7W for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 10:05:04 -0400 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 1pp8Qg-0008J1-DT for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 10:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pp8Qf-0005Lm-QH for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 10:05:01 -0400 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: Wed, 19 Apr 2023 14:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.168191309220545 (code B ref 62720); Wed, 19 Apr 2023 14:05:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 19 Apr 2023 14:04:52 +0000 Original-Received: from localhost ([127.0.0.1]:35485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pp8QV-0005LI-Qf for submit@debbugs.gnu.org; Wed, 19 Apr 2023 10:04:52 -0400 Original-Received: from mail-oa1-f47.google.com ([209.85.160.47]:62616) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pp8QT-0005L2-5H for 62720@debbugs.gnu.org; Wed, 19 Apr 2023 10:04:49 -0400 Original-Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-187b70ab997so9826711fac.0 for <62720@debbugs.gnu.org>; Wed, 19 Apr 2023 07:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681913082; x=1684505082; 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=VulU9Fw3gQ1UC8kVdN8nOGBuhPmHQGdCwVnvF5uY2R0=; b=Lh8PYwofzxhqZXZhs+0jvPh8ldOlrpq8jaAnXi4IWjwmQ9LaP8wB/Ax5YsbHfQ8ls3 5RwGncCgNMOyxxMX6vU86rR/JmxwFNNCFbPqfpboYeklD/bRngX7Ef1gRYkvJyUwa6Vr cKsOGthLzOZ4XL6jhxdXXVUI2DnACtZPUdLc2tk6sstudslKz5JLMyoS7Cw49jhVd26b 0hB5DV15tjitK5R1KCS2ACBsE+W8q4e827/IsYfL1MxYugvbJuYzP/Am7OmX3RqV4XSL xrNmUdFob+0RgpyhJZ79FbnNF3x0nFJfc/QRS6e1NXY0QpI/as0RAKkbV+lPA0iIdT4n 12IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681913082; x=1684505082; 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=VulU9Fw3gQ1UC8kVdN8nOGBuhPmHQGdCwVnvF5uY2R0=; b=e5RHW91z1uJzFw2cPpTBD/AC5PWbeF22nwKD1uGwdZT6AK8RxkY/LsFTdlfVDHGOXq ZZYA0U0DxC7rJicJogC+z4ZSHRvNKjspM9pdXaakefvyxrsaPnMTw1tGARh1hY7F9A7M E0n7Q3TUrqGj8l5c15tRwH1ET5NQHRHQlNJ2itkkT2vBKirhbfSZz39rxCxNUIwvFMDm hbpXK9JuvAdeULUPKLD9Utn/2EphBdGmMAFSYiwccnAgMVFIffHogzHsnhS7SqD/IxuU 0wUsmM450Ycs9UHsG/2prGV+I5PNgh/TITnYXHv4kz9x8cwHEWhy9zFqFpGULCK7SXWm 0Ysw== X-Gm-Message-State: AAQBX9dzJny4duxSeOyEcF7aQ1NvdDzsAE1mSJULdC3s1IgHaCl8mheV fECRuarSLwQX6HgDWYZCMLSYPnlD9UW22QXqPDQ= X-Google-Smtp-Source: AKy350YR5K4JgzBbWSu2ZuPo7N+bHzeOfcbG3q4YXzGkiFnmzWflcZ8pPxlnbvflxtUc1dVaWu47CLP5ZdoDQmbyZeM= X-Received: by 2002:a05:6870:b152:b0:188:1b8:33ee with SMTP id a18-20020a056870b15200b0018801b833eemr1456085oal.21.1681913082227; Wed, 19 Apr 2023 07:04:42 -0700 (PDT) In-Reply-To: <834jpc805p.fsf@gnu.org> 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:260271 Archived-At: On Wed, Apr 19, 2023 at 2:35=E2=80=AFPM Eli Zaretskii wrote: > What I want in Emacs 29.1 (and any future release of Emacs) is the > latest version of Eglot that you, as Eglot developer, consider stable > enough to recommend to users of a stable Emacs. Which version is that > is your decision. But to make sense to me, the decision you make > should be consistent: if a version X.Y of Eglot is "stable enough" for > you to recommend that users of Emacs 29.n upgrade to it, then that > version X.Y can be part of Emacs 29.n. (Of course, if you decided > that X.Y is stable enough _after_ Emacs 29.n was released, then X.Y > will be able to become part of Emacs only in Emacs 29.n+1 and later.) OK. Then I will tell you that "stable enough", for, me means "as stable as possible", because I like things to be as stable as possible. And, to me (and I would think to most people), the most stable version of a program is the one which has seen the most testing. So, I see no reason to give Eglot a shorter pretest period than the rest of Emacs gets. Thus Eglot 1.12.29 it is. > I hope I clarified my position in this regard. OK, it seems you're giving the call to me. Then I hope I've also clarified my decision and the criteria I used in reaching it. > > 1. Bundle Eglot 1.1x with Emacs 29 and all its up-to-date dependencies,= so > > that, right at the moment of the Emacs 29 release, Eglot would function > > exactly the same on Emacs 28 + package-install. > > That is probably not acceptable, although I'd need to know exactly > which versions of what other packages need to be imported into the > emacs-29 branch, to give a definitive answer. I could teach you how to figure that out (it's very simple), but since I don't want this either, and you just gave the call to me, there's probably no point. > > 2. Bundle a "Frankenglot" with Emacs 29 that has all the > > lisp/progmodes/eglot.el code of the future Eglot version, advertises > > itself as Eglot 1.1x, probably doesn't break, but does _not_ provide > > the same experience as Emacs 28 + package-install > > > > Both options are bad, IMO, but 2 is worse. > > I don't see why option 2 would be bad, let alone worse. See below. > > > The first reason that both options are bad is that you're discarding > > whatever value the pretest phase brings to the stability of Eglot's cod= e. > > Eglot itself isn't my problem. My problem is the other packages that > upgrading Eglot, per option 1 above, will require to update: those > other packages usually affect much more than just Eglot, and therefore > bringing their potentially less stable code into emacs-29 might break > much more than just Eglot. Yes, as I said option 1 is bad. Option 2 is worse, but 1 is pretty bad too, partly for the reasons you state (yes you're totally right "it's much more than Eglot"). > > Eglot, being a part of Emacs the Emacs code base, benefits from the sam= e > > testing all its code does. You're discarding that value, and I think > > it's bad, because the pretest is supposedly there for a good reason. A = bug in > > Eglot 1.1x will just escape us and there's no time to fix it. > > Please leave this consideration to me, it is exactly the kind of > judgment call I make every several days when someone asks whether a > particular change is OK for the release branch. And in the case of > Eglot I already said that IMO we should include in Emacs 29.1 the > latest stable version of Eglot, thus my decision about that was > already made in favor of upgrading Eglot on emacs-29. But I won't > insist if you are uncomfortable with that. There is no one "stable". You yourself are talking about stability gradation. Eglot 1.12.29 is "stablest". Eglot 1.14 is "stable". Eglot in master has recently gone two days with a semi-serious live bug (now fixed) Let's call it "unstable" anyway. Before I release 1.15, I will try to make sure it is as stable as 1.14 (or more). By the way, the ElDoc change about the non-blinking is "safe for the release branch" IMHO. Just in case you didn't get my opinion on that part of ElDoc of which I am the author and the maintainer since 2018. > > The second reason only applies to option 2. It would completely confuse > > users. A user running Emacs 28 would see a much better 1.1x than > > the 1.1x bundled in Emacs 29. > > No, users of Emacs 28 who installed the latest stable Eglot from ELPA > should see almost the same version of Eglot as users of Emacs 29.1 if > that will come with the same stable Eglot. Unless you intend to > somehow degenerate important parts of Eglot in what you call > "Frankenglot", whatever that means. Frankenglot 1.1x is just Eglot without the resources that 1.1x would have in Emacs 28. Don't you understand? The "good" Eglot experience requires things that are not in lisp/progmodes/eglot.el. It requires, for example, :echo support in ElDoc's eldoc-documentation-functions so that echo areas aren't flooded by some LSP servers. eglot.el can function without it, but users would be surprised. They would ask: hey didn't you fix this echo area flooding, back in Eglot 1.14??? And I would have to explain: this is not really Eglot 1.1x, this is Frankenglot 1.1x: the content of the eglot.el file is the same but it's missing a lot of stuff. And then I wouldn't even know how to teach them to upgrade. In so many software packages I know outside of Emacs, bugs and features are fixed and added just by bumping a dependency. Surely you must have seen this, too. > My interpretation of option 2 is that we get a newer Eglot (1.14 or > 1.15, whichever you decide is stable enough) with various minor > fallbacks intended to work around the fact that dependency packages > are not necessarily at their versions for which Eglot 1.14/1.15 was > designed to work, if the versions of those dependencies in Emacs 29.1 > are older. Why put ourselves (mostly myself) through these chores?? Just so that two weeks later after whatever Emacs 29 is officially released a more recent, "stable" version is already available? And pay the price of discarding the value of the pretest period? Just because Eglot is now much harder to upgrade? Then just make it easy to upgrade: it's in your control. There there are 0 downsides, as far as I can tell. As far as anyone who has commented that patch can tell. I've seen 0 contestation of the patch I proposed before, which I've grown almost tired of linking to. That patch was engineered to answer precisely your objections to previous patches. It was engineered to make _you_ happy and make me happy, and make Eglot users happy. And you're ignoring it. That is, 1.14/1.15 without the mandatory requirement o > upgrade any other package already in Emacs. If that is not what you > mean, then perhaps consider this as option 3 No, you're just describing option 2, as far as I can see. But probably no "various minor fallbacks" would be needed, because I am careful with the interfaces. --=20 Jo=C3=A3o T=C3=A1vora