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: Fri, 07 Jan 2022 09:33:34 +1100 Message-ID: <87ee5kmm6t.fsf@gmail.com> References: <740A136F-8710-4F4C-BFC1-A3DB418447F4@gmail.com> <83iluzbqcr.fsf@gnu.org> <87r19nxx7x.fsf@gmail.com> <878rvv9esx.fsf@yahoo.com> <87fsq28x4l.fsf@yahoo.com> <87bl0q8vfa.fsf@yahoo.com> <83pmp69vsu.fsf@gnu.org> <8735m17l8c.fsf@yahoo.com> <875yqx5nub.fsf@yahoo.com> <83lezt8cm6.fsf@gnu.org> <871r1k38ym.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10792"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.7.5; emacs 28.0.90 Cc: "emacs-devel@gnu.org" To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 07 01:22:11 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 1n5d1H-0002eu-Cj for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jan 2022 01:22:11 +0100 Original-Received: from localhost ([::1]:41850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5d1G-0003m0-CJ for ged-emacs-devel@m.gmane-mx.org; Thu, 06 Jan 2022 19:22:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44222) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5czC-0000j3-BK for emacs-devel@gnu.org; Thu, 06 Jan 2022 19:20:02 -0500 Original-Received: from [2607:f8b0:4864:20::536] (port=41969 helo=mail-pg1-x536.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n5czA-0004GS-AT for emacs-devel@gnu.org; Thu, 06 Jan 2022 19:20:02 -0500 Original-Received: by mail-pg1-x536.google.com with SMTP id f8so3996681pgf.8 for ; Thu, 06 Jan 2022 16:19:59 -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; bh=xOsbFRmAvQPP4LZ46M7APTIH9nIFw0/3zcVvq0oHujw=; b=eGb/Bk7ieM1SshgRTLe1jQZ0c1WeaXXZcahYU+AZcuD6kH9zx8PqjuU4sTfPp6L9uk +YXQNDbf0hcFeFyG8e/E88Bn7E5iwINv37zamcC+sxXiqBW0A29q8c910zrR7yopxpYK TM0A90wiPxjsuR/mnrA75c5yMAClqWDsRJ/5pjB/GzLmKoh0Q4qxYYsBrp/nAZdCBsue 7bA6lKVIULVsS8sLvr3tg+3he6Y8La1q+aHTpGeTCmEeI78NOv+bZ0f7ZV969VTrGsfl xUtvDyrXFazbakkfBU48tumCdNtsledrg7S925+od2q95QuhSpVtKqcGTpfPGmV8VRo+ tNFQ== 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; bh=xOsbFRmAvQPP4LZ46M7APTIH9nIFw0/3zcVvq0oHujw=; b=XOcpxz6s5O998OFGttCY6k60CoTqZEL/waTsMJQiQ9ffeftMoYp/ah+vv+H6696OVO d2DRvOOpEt1WPn8048vOhhC2EueqErb0ezGUJuBlj/ylXdK6iILfLuzaNIdJyti+1k/D rIKma80MCM6+NJpyCtgi3/tCXM/hlQbbIjbkv3cuj3BP0/HzhMfGSCwupupIJA0/9TtM rBtG7AE4repHSGlWeIwMKgRckPQYORFwWtA6wUaTcz0gW18gn+iCcCRMYYESVunRxfpK d2S8cEnIzAac6kVuTjDW+9E45PASvqDziRwnp58tHhE9+bbteNx7F62gMV+gURbdHiyQ 2ZJA== X-Gm-Message-State: AOAM531mCx6jeFiVjkag4RPHMJmi6H/PblLVYEn/vBoB5b8rsaYLvuwJ XqJrATkz9Hx8nVGtti/0wP1u8cCNuhY= X-Google-Smtp-Source: ABdhPJyFHv1mhOBqRLgrKN/mw7nwBwhDwmGL0XxbPfCOldjIilxOIkSOQqJ088FGqx8xdIA38pOdQA== X-Received: by 2002:a63:354f:: with SMTP id c76mr50232913pga.193.1641514798769; Thu, 06 Jan 2022 16:19:58 -0800 (PST) Original-Received: from dingbat ([124.149.107.194]) by smtp.gmail.com with ESMTPSA id v17sm3304453pjr.21.2022.01.06.16.19.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Jan 2022 16:19:58 -0800 (PST) In-reply-to: X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::536 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::536; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x536.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:284350 Archived-At: Drew Adams writes: > I have a suspicion that what you're wary of, or > objecting to, is perhaps really the automatic > loading of `custom-file' if it isn't already > loaded. That's the only "complexity" I can > imagine you think you see. (I don't see that > just giving `custom-file' a default value adds > complexity.) > Yes, my main concern was certainly related to various suggestions regarding automated detection and other proposals which appear to be focused on minimising change impact on existing users etc. However, having said that, I'm still not convinced this is a real problem. I would agree that if I was implementing this feature now, I don't think I would have the custom data written to the init file and would probably write it to a custom specific file. However, we are not implementing it now and it has been implemented in this way for over 20 years and I've seen few problem reports. I have seen a few people comment that they think it was a bad decision and/or they don't like it, but few actual problems. > If not - if you have a problem also with the > aim of getting more users to use `custom-file', > so as to separate Custom automatic editing of > init files (when it saves) - then what is your > critique of that aim? > I guess my main critique is two-fold. Firstly, it feels like work for works sake which is largely being justified by an argument that essentially boils down to "it isn't best practice". Such an argument might have some weight if there was nothing the user could do, but that isn't the case. This is my second critique - for those who don't like having their custom variables in their init file, they can easily change it. I'm sure some will argue that it isn't easy to change for novices, but I find such an argument weak as novices are unlikely to even know/care that the custom variable section is written to their init file and those that do will likely find the standard solution pretty quickly. > (If you agree with that aim, but not with any > of the proposals to move toward it, please > make that clear too.) > If the *only* change we are talking about is setting a default value for custom-file, I probably wouldn't have any concerns. However, I think it is a mis-characterisation to claim that is all that will change. There has also been mention of adding new command line switches (like -Q and -q) to turn off loading of custom file, questions around when the custom file will be loaded and ability of the user to control that timing, automated prompting of custom-file name/location etc. > To be clear, the aim is not at all "to make > the Emacs startup process 'smarter'", and not > at all to provide some kind of "optimization" > (premature or otherwise). And I don't think > anything proposed so far does that. > Well, I guess we will disagree on that point. My response in this thread was specifically triggered by proposals relating to auto-detection of whether users have set a custom-file name, discussions regarding adding additional command line switches and various other suggestions relating to contgrol of when the custom-file is loaded (or not). > The problem to try to solve - particularly > for new users or users unsure of Emacs Lisp > - is to prevent users (accidentally or with > good intentions) from messing with generated > code, and (less likely) to prevent Customize > from messing with user code. That's all. > > Is that a purely "theoretical" problem? > OK, theoretical was probably a bad choice of words. Perhaps contrived problem would be a better description. In 25 years of using Emacs, I have never seen Emacs customize messing with user code. I think that one is purely theoretical. With respect to users, especially new users, intentionally or unintentionally messing with generated code, I think that is just part of the normal learning process. There is a very clear warning and if they choose to disregard it, that is their choice. If we are going to go down the protect users from themselves road, then we should remove the init file completely and only allow them to configure the system using customize. A better question is whether this is a significant enough problem to justify the change, change management that will be required and additional complexity (even if only small) it will add. I don't see this as a significant issue and personally, prefer having the control to set a custom file and load it when I see fit for my own configuration. In a nutshell, the potential negatives seem to outweigh the benefits. If we were seeing large numbers of reports from users having errors or problems because of the current behaviour, my position would likely be different. There is also a positive side to having the custom variables stored in your init file - one which is probably even more relevant for new users. The benefit is that ALL configuration related settings are in the one file. The new user does not need to know that in addition to their init file, there is this other 'custom' file which will also impact on their configuration. Right now, if, for example, I was having issues getting some configuration relating to 'x' to work, I can search for 'x' in the init file and there is a good chance I will find it even if it is being set via a custom setting I had forgotten about. > As I asked earlier: > > The default behavior of Emacs now is to have > a single file that mixes user coding and > Custom coding. Why is that a great idea? > ^^^^^^^^^^^^^^^^^^^^^^^^ I think that is an irrelevant question. Perhaps it wasn't a great idea or perhaps it was a great idea at the time it was made. However, that is irrelevant. The better question is whether it was a bad enough idea to need change and I don't think it is. It is probably also worth noting that the extremely popular VS Code editor actually does a very similar thing. That editor is configured via JSON and has two interfaces - one which provides a sort of graphical interface similar in flavor to customize and one where the user writes/edits JSON directly. It is all stored in the same file (though you can also have additional config files). The Emacs approach is IMO a better solution because the two are clearly separated while in VS Code, the user can screw up the manual code which will also screw up the GUI interface to the config. > > No one has answered that. Forget, for a > second (and no, I'm not saying this isn't > important), that there is habit & legacy. > > Just imagine that you are designing from > scratch. Would you really want Customize > (or any other code generation) to write > to a file that users code also? > Well, if I was designing from scratch, I probably wouldn't have customize in its current form either. But if we are going down that road, I also would do font locking differently, use different key bindings, use different terminology for many Emacs features, have real namespaces, etc, etc, ... > We don't do that for any other generated > Elisp code. We write all such code to > dedicated, separate files - not files > that users code in. (We don't _prevent_ > users from editing such files, of course.) > > Why do we do that? Premature optimization? > Paranoid theoretical problem-worrying? > > ___ > > In order of decreasing priority (to me): > > 1. Let's agree on the problem, potential at > least. > Sorry, but no I cannot. I would characterise it as a contrived rather than potential problem. This solution has been there for a long time - if the problem had real potential, it would have been realised in significant numbers by now. > 2. Given the problem, let's agree that, in > some way, we want to prevent mixing user > coding with automatic coding. > Given I cannot agree there is a real problem, obviously I cannot agree we need to do anything. If we were all out of work to do and all other issues were resolved, then this might be worth considering. > 3. Given that aim, let's agree that Customize > should - by default - save to a different > file from a user init file. Cannot just agree to that either as I don't think it is that simple. At the moment, I have full control over doing this and full control over whether that custom file is loaded or not loaded and when. To maintain that level of full control and automate it for new users, the startup process will need to become more complex. I don't see how this additional complexity is justified. > > 4. Given that goal, how do we get there? > ___ > > On the road from 1 to 4, how far do you get? > I guess zero :-) > Personally, I get as far as #4. I proposed > some concrete changes as solution, but #4 is > an open question. > > Possible solutions include: > > a. At a minimum (I think) explicitly encourage > users - particularly new users - to define > `custom-file', and load it to get their > saved settings. This seems to be in conflict with one of the justifications underpinning this argument i.e. dealing with elisp code is hard for new users. > > b. What I proposed, which I won't repeat but I > can summarize as `custom-file'-default-value. > > Please note that even poor (a) has never been > done: we don't encourage use of `custom-file'. > > I don't think doing nothing is good (see 1-3). > And I don't think that (a) alone (recommending > use of `custom-file') is sufficient. I guess that is the big stumbling point. I'm still unconvinced that we need to do anything or that it is potentially as simple as just setting a default value for custom file. This isn't an issue I will die in the gutter over. If sufficient numbers agree the change is needed, then it will happen. My only real request is that whatever change is put in place, ensure that I can still set the name and location of my custom settings file and have full control over when in the init process it is loaded. This includes setting and loading the custom file in files outside of the main user init file (i.e. in files loaded by my init file).