From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: xenodasein--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA Date: Tue, 11 Jan 2022 16:05:50 +0100 (CET) Message-ID: References: <87ee5kmm6t.fsf@gmail.com> <87a6g8m1n1.fsf@gmail.com> <871r1jm4hf.fsf@gmail.com> <8735lupwt1.fsf@gmail.com> <87h7aaz9gj.fsf@gmail.com> Reply-To: xenodasein@tutanota.de 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="21174"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: theophilusx@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 11 16:09:05 2022 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 1n7Ilk-0005HZ-4S for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Jan 2022 16:09:04 +0100 Original-Received: from localhost ([::1]:55274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7Ili-0003v9-Tx for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Jan 2022 10:09:02 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58792) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7Iij-0001aN-AA for emacs-devel@gnu.org; Tue, 11 Jan 2022 10:05:57 -0500 Original-Received: from w4.tutanota.de ([81.3.6.165]:40240) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7Iih-0004Jw-3e for emacs-devel@gnu.org; Tue, 11 Jan 2022 10:05:56 -0500 Original-Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 655D51060277; Tue, 11 Jan 2022 15:05:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641913550; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=ZcbtqByKzeLguP9eeKyRCsO+UHZec9Kw0qwJmtGQvlI=; b=Bp8RjwWEfFrHnAonZapjVbKwt7AYvtI9FanNkrjjwDm2tpGd20jhcYRZbve6rM40 lxvypEYOKBeuxSykcQqDJ7R2C68JRl1noPtjS3AiPv7u0HlPR6iPGiZJiQwoVUdGBJS IZwP32htKr1E2AXPXZhRBHTyI4Fxn/dQcJtglgnlwIrk6ufePmGjJn6afONzHW1Y9Hg caPa8LjUUHbg2jvTBaiv2WYmUPSH4tV/0a7GahSQ8NL2S7S2/4BfXuGmvOagHgTMFgU bgA4CbN1FzNaLJxewpI5x/INWdBzsqzMCWEZHe9grWQ7iLELb58bk4ZIuqfBZKxMVDa La61HRxgxQ== In-Reply-To: <87h7aaz9gj.fsf@gmail.com> Received-SPF: pass client-ip=81.3.6.165; envelope-from=xenodasein@tutanota.de; helo=w4.tutanota.de 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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" Xref: news.gmane.io gmane.emacs.devel:284609 Archived-At: Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00821.ht= ml > ... > > All arguments against Drew's proposals so far converge at "it is better > > to do nothing." > > No, that is not what is being said. I'm saying "There is nothing needing > to be done." It is an unnecessary change with little, if any, real > benefit for users and which will have unnecessary/unwanted impact on > some existing users. > > > Why not propose something even better? > > Better than what? Exactly what problem will this change address and how > does this problem impact users and how does the proposed change mitigate > that impact? Well, I think we are getting there on this thread. > > Throwing "where > > is your evidence?" around is easy, but one must consider we are far fro= m > > the domain of scientific method here, or of law. > > IF you propose a change, it has to be backed up with justification. Just > saying it would be better is insufficient.=C2=A0 So far, the justificatio= n > seems to be it is better from a philosophical/theoretical standpoint not > to mix user generated and auto-generated code in the same file, > it could reduce accidental errors by the user editing the settings or the= user > finds it > confusing and the warning scares them. > > > Is existence of people > > on Emacs related forums suggesting setting custom-file to /dev/null as = a > > good solution evidence enough? > > I think all that is evidence of is bad advice. Why would you set your > custom file to /dev/null? If you don't like custom, don't use it. If you > do use it, that advice will likely just totally confuse you as now, if > when you do use custom, it won't work. Yes, but such advice is then also evidence to that some users are annoyed enough with the current (bad) behavior to do/talk about things like that. > > How about split of early-init/creation > > of straight.el? > > iWhat about it? How is it relevant to this proposed change? Suffice it to say that Customize and package.el modifying init.el was used as a driving factor in creating some popular alternative package managers. > > What you call "belief/ideology" is known as intuition, > > and it is the primary force behind any successful software. > > Or any > > kind of invention, really. > > What is being proposed here is an impacting change to existing > behaviour. Trying to claim such a change is 'innovative' or can be > justified by intuition is simply insufficient. If it is a good change, > then it should not be difficult to provide sufficient justification. > Intuition can be both good and bad. There has to be some way to assess > whether intuition (or an idea) is a good one - just saying it is > intuition is not enough.=C2=A0 > > In over 30 years of working on software projects, some successful, some > less so, I can say with confidence, those projects which failed were > frequently those projects which did not manage change and were > constantly making changes based on little else other than intuition. The > projects which succeeded were the ones which correctly assessed which > changes to do and which ones not to. Intuition seldom comes into it, but > when it does, it is backed up with sufficient justification to offset > any of the negative consequences. Apart from miscommunication, we actually think the same on this.=C2=A0 Good intuition and changes lead to success, bad to failure.=C2=A0 I doubt "ones which correctly assessed" used rigorous formal methods to arrive at their decisions, I presume they did what we do on this list, talk over it. > > If only concern is the cost of change, why > > not produce arguments for how to reduce that cost or to find a way > > forward? > > Well that is easy. Don't perform change which has not been justified. But it is justified for many, AFAICT. > When the change involved has impact to existing users, that impact needs > to be justified. When the change modifies long standing behaviour, that > modification needs to be justified. > > I also think it is poor form to basically tell me to come up with a > better solution because I don't agree with the need for the change. Time > would be better spent coming up with justification for the change rather > than criticise me for not agreeing with you. What I find problematic here is that this is change would be a simplest breaking change as possible, and we should try to get better at handling these as there will be bigger ones, and we can't avoid them all the time. I didn't intend to adress you directly if that is how it came out, but this is a pattern I see a lot and wanted to express my opinion on it. Thanks for giving a detailed response.