From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-29 9b775ddc057 1/2: ; * etc/EGLOT-NEWS: Fix wording of last change. Date: Sun, 07 May 2023 08:51:09 +0300 Message-ID: <83v8h4elki.fsf@gnu.org> References: <168335548287.8529.4912240840977468283@vcs2.savannah.gnu.org> <20230506064443.56C75C22F15@vcs2.savannah.gnu.org> <59835735-faa0-4096-e491-35ec92964b7a@gutov.dev> <831qjthhm8.fsf@gnu.org> <715cdac6-83f6-6907-2ff8-3b33381f3487@gutov.dev> <83zg6hg29c.fsf@gnu.org> <83ttwpfvcr.fsf@gnu.org> <83h6spfose.fsf@gnu.org> <35df1362-fd92-9424-97d0-df3479414677@gutov.dev> <83edntfm6e.fsf@gnu.org> <667d5cc1-4a3c-5cd4-21c0-adff89cea769@gutov.dev> <834jopfdwz.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25997"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: philipk@posteo.net, Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 07 07:51:03 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 1pvXIV-0006Zc-1i for ged-emacs-devel@m.gmane-mx.org; Sun, 07 May 2023 07:51:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvXHm-0001gI-NK; Sun, 07 May 2023 01:50:18 -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 1pvXHk-0001fw-Uh for emacs-devel@gnu.org; Sun, 07 May 2023 01:50:16 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvXHj-0001i3-Lk; Sun, 07 May 2023 01:50:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=smGAnp+6PPT3aUaApSywUw5xmFzbcIHUWX8flVf65ww=; b=Ua8E43Lp3l9a 7dTvvWZHkrhlA89OwoDzrUlhghoFVLv0RLusN2R28cp9EC1Unu2kaoRYTuCDYJF1wV8DroJegJrdo JbmNx/DeSZ1ZHdETh/RI9K7dUHuI8L1KafoNkwSc1cOHMZ2sb3Cyl776UUIv54JkCt6QNjYaAo7EY SXuIQbqTpD9mJwreKcid4SrUIHDSNV4eODVh2sqgsUaiReAE/dydVeis02ugZDtzv67p6cQzL78/v n0UoS0f/VRdpxL2H/aQguDDxFhf3yKt5293jOnZnDfuUWaF7NUQR5Nvi2hHXYvZMeOxw4GtFFpGS9 wVpowBRd7AaCkInOU1w16Q==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvXHf-0005NN-Ei; Sun, 07 May 2023 01:50:13 -0400 In-Reply-To: (message from Dmitry Gutov on Sat, 6 May 2023 23:31:31 +0300) 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:305940 Archived-At: > Date: Sat, 6 May 2023 23:31:31 +0300 > Cc: philipk@posteo.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Dmitry Gutov > > On 06/05/2023 22:38, Eli Zaretskii wrote: > >> package-menu-mark-upgrades ('U') is not affected by > >> package-install-upgrade-built-in. It won't. > > > > Shouldn't it? > > Maybe, maybe not. I think it better did, because using "U" would upgrade Eglot and use-package in Emacs 28 and before. So we should give users who want that the capability of keeping that workflow in Emacs 29, if only as opt-in behavior. Also, "/ u" should ideally show built-in packages as well, when package-install-upgrade-built-in is non-nil. Philip, can these two changes be implemented safely for Emacs 29? > A user that customized that option to have (package-install 'eglot) > ensure that a version from ELPA is installed might not want or expect > for it to affect package-menu-mark-upgrades and/or package-upgrade-all. That is true, but denying them the possibility of upgrading would be worse, I think. And since this is opt-in behavior, the user is less likely to be tripped by that without realizing it. > Or anticipate the full consequences anyway. Documentation should solve this aspect. > >>> If package-upgrade was not in Emacs 28, how did users upgrade > >>> installed packages in Emacs 28 and before? > >> > >> Using package-menu-mark-upgrades ('U'). > > > > So we should allow that, at least as an optional behavior in Emacs 29, > > right? > > I don't believe in "optionality" here. > > If the user has to hunt for the option to toggle, they might as well > find the "one little trick" that does the thing they want. > > Most people will only have to do that once (per config), if at all: > after Eglot is upgraded this way, it's smooth sailing from then on. I think allowing such an optional behavior and documenting it in NEWS and in the manual should go a long way towards eliminating at least some of your fears. > >> We should probably focus on getting Emacs 29 out soon > > > > Why do you think this is not what happens? > > I'm just saying we've spent enough time on this particular issue. We can > improve the docs the best we can and move on. This is not the only issue that holds the next pretest. So nothing is lost by spending some more time on this, especially since it's now clear the original longish discussion was at least partially based on some kind of Rashomon effect.