From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA Date: Wed, 12 Jan 2022 07:57:33 +1100 Message-ID: <87czkxzx6y.fsf@gmail.com> References: <87ee5kmm6t.fsf@gmail.com> <87a6g8m1n1.fsf@gmail.com> <871r1jm4hf.fsf@gmail.com> <8735lupwt1.fsf@gmail.com> <87h7aaz9gj.fsf@gmail.com> 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="29788"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.5; emacs 28.0.91 Cc: emacs-devel@gnu.org To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 12 00:11:58 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 1n7QJ4-0007ad-5u for ged-emacs-devel@m.gmane-mx.org; Wed, 12 Jan 2022 00:11:58 +0100 Original-Received: from localhost ([::1]:39464 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n7QJ2-00084D-Tc for ged-emacs-devel@m.gmane-mx.org; Tue, 11 Jan 2022 18:11:56 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:54658) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n7QGz-0007CF-H8 for emacs-devel@gnu.org; Tue, 11 Jan 2022 18:09:49 -0500 Original-Received: from [2607:f8b0:4864:20::630] (port=46892 helo=mail-pl1-x630.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n7QGx-0002UZ-BG for emacs-devel@gnu.org; Tue, 11 Jan 2022 18:09:49 -0500 Original-Received: by mail-pl1-x630.google.com with SMTP id w7so1103260plp.13 for ; Tue, 11 Jan 2022 15:09:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=v1gS9OLoayA/hEntyNvpehsDYKP5WWmXMAfDvqQeqXg=; b=bSZC8n9Fx8aWGb3k9bV8vUZoqyJOI0q1pUIRzkxUl1EL9lVJtg4rbvUHl3McHa+fZk fN4wphH0zlraavUeNN6/zMXJ3cAbZyQeQfftVpxaS8g4qz5sBJSPA+KaZab2rGWK0PDV sYENlU6rpoHOmAdswR9RnYQ9O92IJdZDu32pbzTSHpIdsQhtrEeiP3Fx2atxgNAViD7V VNdaGcTv2fGUaDpoiIbcMofbO5g3UbevgLA/vp7t9PLO7n4tKyGaEsQB3Wf4A8r5pA1X GBcwz3NKIA/zPuKZQ49hRRUFEB51IFVQvmoNVp3ZbiQ1PoSdl9xCiioQMhbOYStof3b8 EYsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=v1gS9OLoayA/hEntyNvpehsDYKP5WWmXMAfDvqQeqXg=; b=Y7mZ7SRRCviJvambXfNdUZ8rPN9KWGWeGmI823QfKb6hVGoITJRBy5QEIr8HrU86Py X4UAoyLAlSG01RcHFE1KOpsKf515KmovPRhN9gwpAmdjZNlyUFV1/6/1BQh5qZzT7Pmf 68cfzzU2Az9MyCrux+m1ipP4wibHyk6i5FPNOmgfaDcEtSRmS/2uLHhPK3PJZWQMEZ1C yGLOSCHxW/ZvmifCNGEGs6BIakAcfGAPezTBZSZkDllMHWgrd+SjLm2gFbRGN09S+QfS J2ZvKWmiCzFlkbNFJgWOOhTXB8MTDM/qSJLeUF8LlOs5bPYTm/sZ7VLGn7rA3oD0T61b Z/CA== X-Gm-Message-State: AOAM532WkLqxJt+taGZbegDFcspKHErRc+xBC6Tmej8Go9hDzYzH2kr4 L6oGlkuNY/IVZWzBr7QKQ5DHDMdaxM8= X-Google-Smtp-Source: ABdhPJwvx79K7l20906tEztiF4GHtnh/51yRqYyrW59jYeUmpUN5JoODKQqquy+GWYSkvYn2laae+w== X-Received: by 2002:a05:6a00:1386:b0:4ba:b454:70bc with SMTP id t6-20020a056a00138600b004bab45470bcmr6707182pfg.19.1641942585169; Tue, 11 Jan 2022 15:09:45 -0800 (PST) Original-Received: from dingbat ([124.149.107.194]) by smtp.gmail.com with ESMTPSA id p18sm8698180pfq.174.2022.01.11.15.09.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jan 2022 15:09:44 -0800 (PST) In-reply-to: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::630 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::630; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x630.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:284628 Archived-At: xenodasein@tutanota.de writes: > Quoting: https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg00821.= html >> ... >> > 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 fr= om >> > 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 justificati= on >> 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 th= e 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. > It is this vagary which needs to be clarified. Exactly what is this "bad" behaviour and how does it impact users? So far, the only justification seems to be that some users feel it is bad practice to have both user configuration code and auto generated code (from custom) in the same file. This seems to be more a personal preference rather than anything else. There is little actual evidence of problems being caused by custom writing to the init file - no repeating bug reports and posts to forums where this behaviour turned out to be the source of some issue seem extremely rare. This behaviour has been in place for decades and it seems reasonable to expect that if it was causing problems, we would be seeing bug reports and frequent messages about issues where the resolution was related to the custom section being in the user's init file. If this was the case, the conversation would be very different and I suspect we would have clear change proposals which would be accepted more readily as they would be changes addressing real problems being experienced by users.=20 For those who don't like custom writing to their init file, there is a perfectly workable solution. It has been suggested this solution should be encouraged for all users as it is "better". However, it only seems better if you are someone in the camp who believes writing the custom section to the init file is bad practice. I suspect many users don't even give it a thought. There are even arguments in favour of the current behaviour which are as valid. It isn't at all clear that changing the default behaviour is sufficiently 'better' than the current behaviour.=20 >> > 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. > I'm not sure that statement can be justified. The big issue straight.el had was with the package-initialise statement being written to the init file. That has nothing to do with custom. Even the original post regarding these issues from the straight.el author stated that custom was not an issue because the user was asked if they wanted to save the datga to their init file before it was saved. The straight.el github page says that package.el saving data via custom into your init file is 'uncouth'. Again, this is really just a philosophical preference, not evidence of the behaviour being problematic.=20 >> > 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 Go= od > 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. > and here we get to the crux of the matter. Maybe many do think the change is justified, but it would seem many don't and I suspect many more don't actually have an opinion. What is being proposed is a change to long standing behaviour where there is little evidence the existing behaviour is causing problems and the main justification is down to some people think it would be better. If the change were to have absolutely no impact on existing users, there would be little opposition. If the proposed change could demonstrate concrete improvements for users, there would likely be less opposition. It does neither. In its weakest form, the proposed change is for emacs to encourage the use of a separate file for custom. However, there is little argument to support why Emacs should adopt any position in this area. There is existing support for those who don't want to have custom store data in their init file and discovering that feature is not hard. Those who want the different behaviour can have it with little effort. There is no need for Emcs to adopt any stance here.=20 >> 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 find that a very flawed argument. Each change, breaking or otherwise, needs to be evaluated on its own merits. How we handle once change has little baring on a different change. >From my experience with Emacs, there is little problem with changes, even breaking changes, if the change has sufficient justification. More often than not, change proposals which fail to gain traction have a common theme - they lack sufficient, clearly articulated justification or lack people actually willing to implement the change.=20 My lack of support for this change is not fundamentally because it is a breaking change, but because there is a lack of justification. It is change being justified by an opinion that having custom write data to the init file is a bad idea. There are other opinions which suggest having custom write to the init file has advantages over using a separate file and probably even more users who really don't have an opinion at all. If we had any evidence that the current behaviour was causing actual problems, we would be able to focus on how to address those problems. The solution might be to separate custom from the init file or it may be something completely different. It would all depend on exactly what the problem is which needs to be addressed. Instead, what we really have is just an opinion it is a bad idea and the suggestion that opinion is sufficient to warrant changing an established behaviour which has been in place for decades. Some might feel such an opinion is sufficient, I don't. Furthermore, some of the more 'advanced' aspects of the proposed change I find problematic because it would add additional complexity and to some extent muddies the water with respect to Emacs initialisation and how custom fits into the process.=20