From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Only signal package.el warnings when needed Date: Tue, 22 Jan 2019 19:29:57 +0200 Message-ID: <83tvi08usq.fsf@gnu.org> References: <83k1j7dyu3.fsf@gnu.org> <8336ptet50.fsf@gnu.org> <83tvi9d8o8.fsf@gnu.org> Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="2514"; mail-complaints-to="usenet@ciao.gmane.org" Cc: emacs-devel@gnu.org To: Radon Rosborough Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 22 19:38:04 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 1gm0vw-0000Ry-Bh for ged-emacs-devel@m.gmane.org; Tue, 22 Jan 2019 19:38:00 +0100 Original-Received: from localhost ([127.0.0.1]:46960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gm0vv-0004Lo-8D for ged-emacs-devel@m.gmane.org; Tue, 22 Jan 2019 13:37:59 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gm0ux-0004Ih-1y for emacs-devel@gnu.org; Tue, 22 Jan 2019 13:37:00 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gm0uw-0007pJ-SC; Tue, 22 Jan 2019 13:36:58 -0500 Original-Received: from [176.228.60.248] (port=3295 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1glzsG-0000aa-3c; Tue, 22 Jan 2019 12:30:08 -0500 In-reply-to: (message from Radon Rosborough on Mon, 21 Jan 2019 14:45:36 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:232602 Archived-At: > From: Radon Rosborough > Date: Mon, 21 Jan 2019 14:45:36 -0800 > Cc: emacs-devel > > > 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. There's no argument between us about the advantages of the proposed change. The argument seems to be about the disadvantages, and specifically about the risks of unintended consequences of changes in this area. The size and the complexity of the patch is therefore not the important indicator, what's important is the complexity of the code which it changes, and the associated risk of unintentionally breaking some important use case out there, of which there are quite a few. I realize that you don't necessarily agree with this POV, but we have different perspectives on this. > > > 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. It isn't. It is an argument against the haste of making changes because it might be "too late" afterwards. I'm saying that we are not afraid of making changes afterwards, and I provided an example of that, one that you should be familiar with. > 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). Fixing problems sooner rather than later is always an advantage. But it should be weighed against any disadvantages, and in this case it seems to me that we might not yet have enough experience with the current code to design a solution whose risks are low enough. > > 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. It might be a stopgap, but if it improves the situation while running lower risks, it could be a good interim measure.