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 01:13:46 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <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> <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="7483"; 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 02:14:51 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 1ppHwo-0001nS-GR for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 02:14:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppHw2-00025w-FB; Wed, 19 Apr 2023 20:14: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 1ppHw1-00025o-DU for emacs-devel@gnu.org; Wed, 19 Apr 2023 20:14:01 -0400 Original-Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppHvz-00036d-9A; Wed, 19 Apr 2023 20:14:00 -0400 Original-Received: by mail-oi1-x22e.google.com with SMTP id 5614622812f47-38e04d1b2b4so246581b6e.3; Wed, 19 Apr 2023 17:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681949637; x=1684541637; 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=kcaahXyXgwROodGrpYva0glI94IvqAg06Yih4vhCsMU=; b=ObgFhwJMrvPdpadTKRG1bljtT8D0NDA/6lvT7TFULmqFcZ6YAcJhfB43z1b9oNAV96 DwMcaFI5FtuxvirplB4HcGoip9+wtlH20xZt+3tjo91QQGvG6HMsxL2o7qdl2axjwqHN N7S9zqRbWkRhM4LN+zh36oakNVn2SKn0uejz0CwEoUHBKWoe9d8KMQHwuRxcSo7X146N enJ/XkL3EjJpMcuNvbgXyq3GxPbTRj8L0mMpwcTkPB5L33AXK4PWX7KGcMMjwVFWv5QJ uiH9r945jJcOKwoB/8LIApprtuF4FYOnBGMmIjjT9fROZNGa3D3Mv+dTN5C+GVF9L15f TUtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681949637; x=1684541637; 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=kcaahXyXgwROodGrpYva0glI94IvqAg06Yih4vhCsMU=; b=ONWT8FlS1u1IqOVgutqP3cutGldHt/ARHv9eK1g6Y1GXg+qCRoWM7UhJ0YJTLkh+zI qwgzsmSFpI6GRZNff7yX0TLWhjcxaSJ9g8FeI1ZKj3frXi0jb2RE+vIUnWHPDRLuzdz8 1wO0VzgEGVQZVIkfB1XXNl9C1HudmGwv4bV4QY7liG547Wdq1el+75kVJvb2WxwhEj+K pwEac20vxa+28wFda8ny037gQ/ofygMwwz2oiqVK7bCmhVukDLjyyr9RbFzEt7xPDYSZ SXh+ubUdmuDrdcDBeOCwGtjgMJDQ+XNotZ/RbnMKeSX6lnJFAbkKcp4zvkwoIBEE5TmI QtBA== X-Gm-Message-State: AAQBX9esTJ1m2Poh72jYIEo7G98O49On9DKk2sKaDtHVme8jyEOjVHnE Ibkump3mTd+ONxalJLYVZf4/NhFhHatCInXh6QE= X-Google-Smtp-Source: AKy350YS0O3vDraFW98BcEdw6XriXK5A0oTiPBje9Ful+vUxWbrahl+Twn0yzXFDz4Wo8EF0PbmVmPgGExHoU7moe6g= X-Received: by 2002:a05:6808:28a:b0:38d:f4dd:ac69 with SMTP id z10-20020a056808028a00b0038df4ddac69mr3596231oic.42.1681949637569; Wed, 19 Apr 2023 17:13:57 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::22e; envelope-from=joaotavora@gmail.com; helo=mail-oi1-x22e.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:305478 Archived-At: On Thu, Apr 20, 2023 at 12:25=E2=80=AFAM Dmitry Gutov wr= ote: > > > Anyway, adding it back and replying with a full quote. Thanks, I also didn't notice emacs-devel was lost there. > On 20/04/2023 01:49, Jo=C3=A3o T=C3=A1vora wrote: > What kind of semantics do we get with it? The closest possible to Emacs 28 for _all_ users (Eglot users and the Emacs users that are vulnerable to furtive upgrades and which Eli is thinking of) > 1. (use-package eglot :ensure t) considers select builtin packages to be > "not installed" for the purposes of ":ensure t". > 2. 'M-x package-install' allows installing them. It doesn't allow > installing any other package for which (package-installed-p 'xxx) > returns t, but allows installing (essentially upgrading) these ones > (either just eglot, or both eglot and use-package). > 3. 'M-x package-update RET eglot RET' still doesn't work unless eglot > has been "upgraded" at least once via other means. > > Is that logical? Is even just 1+2 logical? Neither is. IMO we have to think in terms of expectations for each package, not in terms of a heavy handed blunt class o packages like "builtin". Because Eglot wasn't a builtin and now is. So this is why my patch includes that predicate `package--safely-upgradeable-builtin` The name is not good, I admit. It should be `package--hitherto-casually-upgradeable-builtin` maybe. > because the package can't be installed (no connection). Should they > remove ":ensure t"? Perhaps. But the documentation says that that option > checks that the package is "installed automatically if not already > present on your system". Seems legit, right? Why would startup fail when > 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". > Or, to put it another way, why did we decide to bundle Eglot with Emacs > if the first thing we're going to do is to try to download it anyway? Who is "we"? I know for a fact some people are. The enthusiasts are, the feature seekers, are immediately. Others will experiment, I assume. Very often one experimentation that happens is you just save all your .emacs.d to the side safely and let er rip with whatever init.el someone (trustworthy presumably) gave you. ( What, you're going to say you've never tried the spacemacs or doom emacs or nano emacs just to see what all the hype is about??? :-) ) But others, like me from time to time when working on VMs via ssh machines, will be very happy with sudo apt install emacs in said machines (if not done so already) and use a vanilla configurationless emacs. And if you add a "clangd" to that invocation and Emacs happens to be 29 you'll have nice LSP for the first time in many years. Personally, for _my_ quick hacks in those situations, I don't bother with M-x package-install latest-and-greatest, just as I don't bother bringing my heavy config via ssh to that machine. I can't really, I'm frequently tmate'ing with other people there, we have to settle on Emacs -Q (+ electric-pair-mode and a few obvious others). But your question also has a completely different answer: A very good reason I wanted Eglot to be bundled with Emacs is now actually being put into question in this very thread. I wanted to simplify Eglot's development as it advances with other :core packages. For example, I wanted to split off its external completion style easily into a separate core package, as I did with Stefan earlier this year. I want to be able to add a feature 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. 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. 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"). 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. > So... I understand the problem, but I think we shouldn't change the > functions in a way that makes them conflict with documentation or with > each other. Does the latest patch introduce any such conflict besides the "no internet" case you mentioned? Not that it's really a conflict IMO: it's just what Emacs 28 did with Eglot AFAICT. Jo=C3=A3o