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: Tue, 18 Apr 2023 22:15:07 +0100 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <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> 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="35029"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, monnier@iro.umontreal.ca, Eli Zaretskii , larsi@gnus.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 18 23:14:27 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 1poseg-0008uR-WA for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Apr 2023 23:14:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poseK-00029E-Je; Tue, 18 Apr 2023 17:14:04 -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 1poseJ-000295-GW for bug-gnu-emacs@gnu.org; Tue, 18 Apr 2023 17:14:03 -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 1poseI-0008UO-UE for bug-gnu-emacs@gnu.org; Tue, 18 Apr 2023 17:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1poseI-0008BS-59 for bug-gnu-emacs@gnu.org; Tue, 18 Apr 2023 17:14:02 -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: Tue, 18 Apr 2023 21:14:02 +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.168185240231402 (code B ref 62720); Tue, 18 Apr 2023 21:14:02 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 18 Apr 2023 21:13:22 +0000 Original-Received: from localhost ([127.0.0.1]:60563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1posde-0008AQ-DN for submit@debbugs.gnu.org; Tue, 18 Apr 2023 17:13:22 -0400 Original-Received: from mail-oo1-f45.google.com ([209.85.161.45]:45624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1posda-0008AA-QZ for 62720@debbugs.gnu.org; Tue, 18 Apr 2023 17:13:20 -0400 Original-Received: by mail-oo1-f45.google.com with SMTP id bg38-20020a056820082600b005421db6ed5bso2654199oob.12 for <62720@debbugs.gnu.org>; Tue, 18 Apr 2023 14:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681852393; x=1684444393; 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=ZRdE/I7jEmRYkUFfVVaxzCbURGVhmK66Q/hmdCwkOmg=; b=hxlrht35iVK5bb/NTqqqcIp3oZLejJqRMF4MBzUCk+hzD5nO31ki3x1pxe3J2OEXI5 gU5SqlHPC9Y4D8BI68pF8+nzBZHsOyQcgHxOpzWEDbwPiDyqe9t8J15Y6L0owRhfMFKq TMYxmTWd1615Zz5988Smam0Nr0xQA+QREWQapwe4I76tgM4pGi0ayruAwNdr/PAekZwg S3oLR+Z+mqb2roNCymTf727mbmMtN7o5Bb/S6+nbllVJy+fsp8J3Byje7vaLZRlJ/6r6 JRbVc2GPuKD9Rt+gh/kCZOF9khCfYVB8cgqgCzHpTc6qVb9+oe7ZWu+CaqUTkxhenFj2 1LMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681852393; x=1684444393; 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=ZRdE/I7jEmRYkUFfVVaxzCbURGVhmK66Q/hmdCwkOmg=; b=B7Dj1Ri34qWyYKH6El59CJ4REww1W/41O1R7CNmyQ27Va18CFfdtyERrp7+FYJsWdH sypEtaJRBEah/I+allE/qtROwlsjfjnITU2qn2WZdlFZG1L/H/U7Bv8x+oms//5RsX2e ODGYwPHVZR36GuyjFPaZhldUKSZy8WWGIi8+l/6Wy4KbmrTGdKhXlBbps5uyf2lG8MKp 1ITBp3MQR/QVguh43ThenCP0HlpPq5v1Y0OznaMEc898qoufFC2X1/QJMqB8f68EiwCq VwuP29LNRxtbtp+36myLbgJZ9gacdTG2lMlJE1ZsB4GtBkFEFJWMZ03VwVzic7Tvp2MK tZZw== X-Gm-Message-State: AAQBX9fCwF5ZNMKs1xNY+wVLPHIJdlUujzK7ClTZSg7xyEoSoIkYTo/c FZvMscGNiZ/m+SmqWMa2yu/pE4MxzGlQXgbcyAs= X-Google-Smtp-Source: AKy350YPHxszAfIlSuKbyYmVfqhqUe4ZOe9k5k3y9sriX5Db4i/15YonaO+Xama/9GoiycWn2w6oSLvlPq3T48JouGI= X-Received: by 2002:a4a:45c5:0:b0:546:9aa2:1da2 with SMTP id y188-20020a4a45c5000000b005469aa21da2mr3751621ooa.1.1681852392861; Tue, 18 Apr 2023 14:13:12 -0700 (PDT) In-Reply-To: <06d29dbd-0b33-8698-bcb8-c89368612f54@gutov.dev> 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:260241 Archived-At: On Tue, Apr 18, 2023 at 10:06=E2=80=AFPM Dmitry Gutov wr= ote: > > On 18/04/2023 23:56, Jo=C3=A3o T=C3=A1vora wrote: > > On Tue, Apr 18, 2023 at 9:38=E2=80=AFPM Dmitry Gutov = wrote: > > > >> This particular one didn't have to, but it's a problem very > >> characteristic of joining a strongly centralized project with ultimate= ly > >> one person having the last word in all major decisions. And it's not > >> like Eli is being unreasonable: we do need a stability cutoff, and we'= re > >> really long past it. These one-more-change kind of arguments repeat ye= ar > >> over year, with reasonable, well-intentioned people on both sides. > > > > Yes. And here both people sides "one more change". The change that _di= d_ > > make it in is more aggressive and more unstable than the one that didn'= t. > > Well, not really. It's by definition more conservative one. Problem is, > it violates a practice established by third-party community outside of > Emacs. Hence, more unstable. There aren't watertight borders here. These users in the "third-party" community are using nothing but Emacs and GNU ELPA Eglot, those are the users that we're hurting while to protect the non Eglot users. But why on earth can't we protect the non-Eglot users and not screw the Eglot users. We can, with a simpler change. > >> Sure, and I agree, but I don't really see how to present that in terms > >> Eli would feel suitable to accept. One "trick" that worked in the past > >> was to somehow enumerate all potential execution flows (functions > >> involved, etc) that would be affected by the change. > > > > Right. And IMO it's not a "trick", it's how it should be. It's hard t= o prove a > > negative, but at least it should be attempted. Well, the patch I prese= nted > > (the one you +1'ed) makes it so that package-install keeps exactly its = previous > > behaviour unless its argument is one of (eglot use-package), which are = arguments > > that could not have ever been passed to that function as :core packages > > in Emacs 28. M-x package-install RET seq or (package-install 'xref) kee= p EXACTLY > > the same behaviour. It's very clear to see from the minimal patch. > > Perhaps a more structured/verbose outline of the same would help. It's 7 lines of code. Elisp should be trivial to read. Eli read much more complicated code in this thread. > > Of course I think the current behaviour is better. But it's also diffe= rent so > > I don't think we should backport that particular one. Even if so far t= he > > only feedback we have had has been positive, it could well be that some > > people _liked_ the half-the-window-height thing (after all their custom= ization > > options reflected that wish, even if by default). > > > > And by the way, not really half-the-window. I used this for a long tim= e > > without being much bothered by it. > > I guess it depends on the number of overloads for the function around poi= nt. I'm using C++ ;-) > >> Perhaps the second issue affects only a minority of servers, and I'm > >> wrong to be worried. Because otherwise, I really don't understand why = it > >> hasn't been reported and fixed until recently. Not blaming you, just t= o > >> be clear. > > > > It was reported a long time ago. By you and others. But there wasn't > > the means -- or rather the energy from my part -- to fix it. I couldn'= t > > just have truncated that information. So I enhanced ElDoc instead with > > the :echo option. > > Aha, so the :echo thingy made it possible. Gotcha. Right, which is also the reason it makes even _less_ sense to bring Eglot 1.15 into Emacs 29 _without_ ElDoc (I hope that plan is now completely off the table). Jo=C3=A3o