From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Only signal package.el warnings when needed Date: Mon, 21 Jan 2019 14:45:36 -0800 Message-ID: References: <83k1j7dyu3.fsf@gnu.org> <8336ptet50.fsf@gnu.org> <83tvi9d8o8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a84c4e057fffa064" Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="222345"; mail-complaints-to="usenet@ciao.gmane.org" Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 21 23:46:36 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gliKt-000viV-JX for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 23:46:31 +0100 Original-Received: from localhost ([127.0.0.1]:35335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gliKs-0007gA-Lf for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 17:46:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gliKl-0007g1-Dp for emacs-devel@gnu.org; Mon, 21 Jan 2019 17:46:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gliKh-0003YH-89 for emacs-devel@gnu.org; Mon, 21 Jan 2019 17:46:21 -0500 Original-Received: from mail-vs1-xe41.google.com ([2607:f8b0:4864:20::e41]:43133) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gliKc-0003WF-2S; Mon, 21 Jan 2019 17:46:15 -0500 Original-Received: by mail-vs1-xe41.google.com with SMTP id x1so13553399vsc.10; Mon, 21 Jan 2019 14:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lBxTAPrzSP164GR9MJz9K4AxskGkXXAXPmAgj6QkrZg=; b=GjKTv/uUelZ3B89WcYgeO2V9PyUdi+NmlFNdxP3ZUpWk8OfRnThusLHbF4qGmDzDwP 1KB/b5tg9ghXQSGumd1hNde3J6dRjM/wlgM89vU37HJMtyL45PXJzlXfQPYgibuYN7tC 2BEbPhmxPM8SfG8LDaGd4ggjm4oYPb9oMV2vCzGjMjAkX+98Cee2B2Wk+e8/VJRoZ/i7 TKMU2UlembVb3TdN3kp4C5bp21tlBwWEbkBFYxU9mTj63pTPRFZOEOtlbbhn1MN2Y6LE oElWjr0hjRAjDdRbBIXmehx6UJTjhn3bI2JVzz7V44EAdAs9N5Rh48c72piHfkSaqXVf LcDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lBxTAPrzSP164GR9MJz9K4AxskGkXXAXPmAgj6QkrZg=; b=RHClA63kx8Mz3U2z1ELNaCEQRJtHg0v+y6QeU0X/ibu0T/JZiiFtOcU/NftSZP0kOB G+Yv0GiKxuzcuVi7m261EjgCNC+nf90pNABR2jQYV+2QVBGj6doNkEY+58Rbp8FhJJ9a a9MWW78u1EGk68t+LXHafWvRPaXcwVB7PnamV7nVtKJFTlRsvXPXUmag8DLLdKQsEtpc 4yFUPiWtI6t3DAxgSU28KsDLkxmluFc1GGulV8of6Se5ETreqysau7Zu8LWD7lz6vXVN DTsC+04zWbak1MUf2jFZ32O2+8s5+RJdAJk27IhSA9TqlFbRF3C8yQhY+2Z3Ecx7L54Z RySA== X-Gm-Message-State: AJcUukdO5PwgnnTtisIFobWTuLSrCwzS8FynCqWwbIkwFSny0Tymca5G v5UQN4lhJ3mDu9+L1S8MQW5t/1Clir1/tNXO0KvF0g== X-Google-Smtp-Source: ALg8bN6+FM4azFwKhb/oyRJoWuL9hmPJkXLlpVC6nu1xhG1KN4u33tkheQ0nxr4gf6xgixzZKgrLkRo+BEJNP9vNQrY= X-Received: by 2002:a67:c31d:: with SMTP id r29mr13140964vsj.130.1548110772324; Mon, 21 Jan 2019 14:46:12 -0800 (PST) In-Reply-To: <83tvi9d8o8.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::e41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232589 Archived-At: --000000000000a84c4e057fffa064 Content-Type: text/plain; charset="UTF-8" > That there's some fallout cannot be used as an ultimate argument in > favor or against some change. In that case, could you explain what /would/ be a good argument in favor or against the change I am proposing? As far as I can tell, it saves people time without any known disadvantages (and with very little additional complexity -- the patch being about 70 lines of code), but you don't seem to consider this a good enough argument. Have I misunderstood something? > From: Eli Zaretskii > Date: Jan 15, 2019, 11:26 AM > > > From: Radon Rosborough > > Date: Tue, 15 Jan 2019 11:43:39 -0700 > > > > > From: Eli Zaretskii > > > Date: Jan 15, 2019, 10:19 AM > > > > > > I'm saying that we should hear the complaints first and devise > > > the solution only after that. > > > > If we wait until Emacs 27.2 to fix the complaints, then it will > > already be too late to do anything useful. > > That was the situation before the recent changes, and we still made > those changes. I don't see why this would be an argument against the change I am proposing. The recent changes were useful, which is why we made them, but they would have been even /more/ useful if we had made them earlier (before everyone's init-files got changed). The situation is the same here. Maybe it would still be helpful to make these changes in Emacs 26.2, but they would be a lot /less/ helpful at that point in time. > So maybe the right solution is to make that variable public instead. Maybe. But this seems like a strictly inferior solution from the perspective of user experience, since it still results in users being shown superfluous warnings which waste their time and mental effort. Best, Radon --000000000000a84c4e057fffa064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> That there's some fallout cannot be used as = an ultimate argument in
> favor or against some change.
<= br>
In that case, could you explain what /would/ be a good argument in<= /div>
favor or against the change I am proposing? As far as I can tell,= it
saves people time without any known disadvantages (and with v= ery
little additional complexity -- the patch being about 70 line= s of
code), but you don't seem to consider this a good enough= argument.
Have I misunderstood something?

> Fro= m: Eli Zaretskii <eliz@gnu.org>
> Date: Jan 15, 2019, 11:26 AM
>
> &g= t; From: Radon Rosborough <radon= .neon@gmail.com>
> > Date: Tue, 15 Jan 2019 11:43:39= -0700
> >
> > > From: Eli Zaretskii &l= t;eliz@gnu.org>
> > = > Date: Jan 15, 2019, 10:19 AM
> > >
> &= gt; > I'm saying that we should hear the complaints first and devise=
> > > the solution only after that.
> >=
> > If we wait until Emacs 27.2 to fix the complaints, th= en it will
> > already be too late to do anything useful.
>
> That was the situation before the recent chang= es, and we still made
> those changes.

I don'= ;t see why this would be an argument against the change I am
prop= osing. The recent changes were useful, which is why we made them,
but they would have been even /more/ useful if we had made them
= earlier (before everyone's init-files got changed). The situation is
the same here. Maybe it would still be helpful to make these change= s
in Emacs 26.2, but they would be a lot /less/ helpful at that p= oint in
time.

> So maybe the right solution is t= o make that variable public instead.

Maybe. But this seems li= ke a strictly inferior solution from the
perspective of user expe= rience, since it still results in users being
shown superfluous w= arnings which waste their time and mental effort.

Best,
=
Radon

--000000000000a84c4e057fffa064--