From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Thu, 20 Apr 2023 02:49:45 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <35638c9d-e13f-fad8-5f95-ea03d65d4aa2@gmail.com> <87a5z3izst.fsf@web.de> <83v8hr7qk9.fsf@gnu.org> <83pm7z7nkc.fsf@gnu.org> <4b63ef62-5e1c-3dcf-ec7b-06b69e79133b@gutov.dev> <83o7nj7mfn.fsf@gnu.org> <556e0fbb-215e-c11d-0e8b-73e97441abbb@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="22829"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , arne_bab@web.de, jporterbugs@gmail.com, emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 03:50:43 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 1ppJRa-0005ho-Lm for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 03:50:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppJQw-00075h-Uj; Wed, 19 Apr 2023 21:50:02 -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 1ppJQu-00075K-Ug for emacs-devel@gnu.org; Wed, 19 Apr 2023 21:50:00 -0400 Original-Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppJQt-000156-1k; Wed, 19 Apr 2023 21:50:00 -0400 Original-Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-546da27b81cso132727eaf.0; Wed, 19 Apr 2023 18:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681955397; x=1684547397; 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=h7odf2CwPHEaJJO6Au/FsnsApxoFVMf6bpfrWhzOs2A=; b=hCssqirm6E5rkp70L/M6DP5IaDwHYUqPuZD5yuU5DmSvQQbgzElo7OwpCuSYYfdnLz C7dWU3QzNEZUuYr09XrVHfS0wVU3VdnATWF6A34QXesCmgci2OJocDe32YR6LHWzCjri yNTLnXLAfL1evUXGyoC+ShWPG4lV30kQSBM6OFM7o1pfJhFyNt7FsEqEr228t9ZomJNw ekXJOknX8NVKvNPA8DDpeZdKcwP3DxlMS9ro2RxAK18PkJsSbuM5JUiWTwQMkK7ocwyT IJEamqR9SquioZfibAms+CqKIJIMtAQJwF1c0wXg5QEZlYnSsX22Vf87RG6Qrmr32Eim vYfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681955397; x=1684547397; 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=h7odf2CwPHEaJJO6Au/FsnsApxoFVMf6bpfrWhzOs2A=; b=eoiNRhAHL/QG24Mjj43r+EeHnmu4f9WXQpPj0p4bwCnhH6AXDUBNizElaMnR7qxuPA LhJTzbDwJJR6qunIB4g+FfADQ/LYpWP98EYiXiCEQwUj5xSS1MyVUqxnmebhuU0zvJEv U9D7sXAkOEgolNDnZw4dTqIlnXxAcpdR60Sp+XUW3vwok0/xFfbxqGWs7b7HfHk6yfV0 syFQgxClCB5ca5AaKf+xvNN0FivPJtcXrx8n+MYwU90Y8jiS63Q0Y5Ls0Gw1stHhTofZ LANGeY25Bv64V6O5glymkdcEv/eaEO1++n64W0GkgwhewPQpYOcW2ols2A/bYAwcN2Zu PjXw== X-Gm-Message-State: AAQBX9dV03LpOae6U1sPbzW2x1LpsUQ2irPFf69grUQSN+Wj5QI9fQaT Ryvs5RL7UA+TdSCLkCsmJXvUX+ShIufjzoVEPyI= X-Google-Smtp-Source: AKy350avcScgFjznpbdplG0e4ptZEy6iDJw0G6smfOkFbS9icS/+q7qnBq7jTrwLQBsCDZlRZNPZVIFoz9FpCz988RU= X-Received: by 2002:a05:6808:1a26:b0:387:266e:1624 with SMTP id bk38-20020a0568081a2600b00387266e1624mr8865oib.39.1681955396451; Wed, 19 Apr 2023 18:49:56 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::c2e; envelope-from=joaotavora@gmail.com; helo=mail-oo1-xc2e.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, 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:305480 Archived-At: On Thu, Apr 20, 2023 at 2:13=E2=80=AFAM Dmitry Gutov wro= te: > >> because the package can't be installed (no connection). Should they > >> remove ":ensure t"? Perhaps. But the documentation says that that opti= on > >> checks that the package is "installed automatically if not already > >> present on your system". Seems legit, right? Why would startup fail wh= en > >> Eglot is already present on the system? > > > > Because we want it to do the same it did in Emacs 28? But I see what > > you mean. Maybe the :ensure for packages in that particular subclass > > should mean "try a bit harder to upgrade these, but don't blow up if > > you can't -- just try next time". > > ... maybe. I just looked in straight.el. I haven't actually tried it, but I noticed that the only place where it cares about if a package is built-in or not is in straight--convert-recipe. And to my (pleasant?) surprise, it is using it to decide whether to report an error or not if the package is not found. If it's builtin, the error it not thrown. > Maybe you'll put the recommended use-package form somewhere in the Eglot > manual, right? It will be published on the web as well. Will it contain > ":ensure t" or not? If not, the users of Emacs 28 might fail to get the > package installed. If it will, then the offline users might have > problems, as described previously. To be honest, I'm thinking of either not recommending a package manager at all, or just recommending a third-party one that I think rhymes with what Eglot users expect. Might very well be straight.el or elpaca.el. One things is for sure, my previous recommendation of "use package.el" is not good. > > to ElDoc and use it in Eglot in the same patch, etc. That part > > has worked fine. It wasn't impossible with Eglot in GitHub, but > > it was harder. Hopefully Eli is not asking for that bliss to end > > I understand hope he's asking to be circumspect in what > > is added, and not do gratuitous things like bump dependencies > > without reason. I already do that, so no problem. > > It seems like most of this could have worked out if Eglot moved to the > emacs.git repository, but was removed from the distro before packaging? > Just a thought, not that I advocate for doing that. Then emacs -Q bla.py -f eglot would not work. And major modes in Emacs could not use eglot.el as a library. > > Finally, if you're taking all this in the direction of "I told > > you so, don't you regret bringing Eglot into Emacs 29?", I don't > > blame you. But I have to say: no, not yet. I think having the > > beginnings of an LSP library in Emacs for major-modes to work > > with is excellent. I like the attention and the high-standards > > other seasoned developers hold my code up to. I like the Info > > manual and I like that emacs -Q bla.c -f eglot works just fine. > > I like my told-you-so's as much as the next guy (just kidding; > definitely more than the next guy), but that's not the point I was > making. Just that it's here now, and it seems odd to avoid using it and > hurry up to install the next version right away. I agree. I don't want users to hurry, but I don't want them to not hurry either :-). It depends on what they want. Eglot 1.12.29 in Emacs 29 is pretty good. > > This upgrade situation sucks, is true, and I should have foreseen > > it. Spent too much time in my emacs-master worktree I guess. > > > > Who knows, maybe this will all be OK after all?? Half the > > users are using "straight.el" anyway (and I really doubt > > it is hampered by these minutiae about dependencies, seeing > > as MELPA-land is teeming with way more "dependency hell"). > > I'm pretty sure the users on straight.el are straight-up illusion. It's > the latest fashion on reddit all right, but it has its own problems, and > the silent majority are still using the older methods. > > Not to say it's a bad project (I'll try to migrate my authored packages > to it one day, since it seems to make that natural), but for an average > user? I don't think so. I don't know. I see a lot of people using it, and have seen that for a long time. The average user googles things and lands on reddits hits. ChatGPT teaches you "straight.el" too (if you ask it). > > If nothing more happens on Emacs 29, which is the most likely > > outcome, I think I will just start recommending "straight.el" > > more, maybe learn it myself. I had problems with it in the > > past but it's probably matured now. > > I would suggest to start recommending ways to perform an upgrade > explicitly (somewhere in the README, in the manual, and so on). Like > 'M-x package-upgrade', if we manage to get it fixed in Emacs 29. That's a big if. My worry here is how to clearly control this messaging, especially when dealing with cleanly deterministic bug reports. I have to know exactly the version that he user is running. Recently, I've become adept at doing: HOME=3D`mktemp -d` emacs -l recipe.el It's a very good way to establish sanity. And until now recipe.el could have just `(package-install 'eglot)` and I would know exactly what packages the user has installed. The answer will now be different in Emacs 28 vs Emacs 29. Mind you, I will still know, of course, but the thing installed on Emacs 28 will be wildly different than the one installed on Emacs 29. And, as I said before and everybody understands, it will get worse with time. So what form to give users?? I suggested adding a 'eglot-update' function to eglot.el only -- the only code I normally have control over. A four-line long function that I would put it Emacs 29. It would have this property of being absolutely consistent in whatever Emacs you're on. But Eli called it "the worst of all worlds" and flatly refused it. Maybe he could reconsider, who knows, if all this writing that has happened since has provided some more perspective about the problems. > And, okay, having a separate section in README about Emacs 29 might suck > at first, but then the majority of the users move to it, and support > will get easier, more uniform. Yeah, I guess. BTW the tea leaves and some comments in the Philip-Eli interaction tell me that the behaviour is going to again be different in Emacs 30. That will suck for a longer time. > That's the only hard breakage I managed to come up with. The others are > of logical kind (functions and commands doing things somewhat against > their documented behavior), but that's also not so great because people > like their tools to make sense. > > To name an example: 'package-install' will upgrade Eglot even though > (package-installed-p 'eglot) already returns t. Even with today's patch in Emacs 29 that already happens if you tweak the new "heavy-handed" variable. So I guess that isn't a problem. Jo=C3=A3o