From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA Date: Mon, 10 Jan 2022 22:01:08 +0000 Message-ID: References: <740A136F-8710-4F4C-BFC1-A3DB418447F4@gmail.com> <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> <87ee5kmm6t.fsf@gmail.com> <87a6g8m1n1.fsf@gmail.com> <871r1jm4hf.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3280"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "emacs-devel@gnu.org" To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 10 23:02:27 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 1n72kE-0000fS-OQ for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Jan 2022 23:02:27 +0100 Original-Received: from localhost ([::1]:37576 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n72kD-0002Ia-DJ for ged-emacs-devel@m.gmane-mx.org; Mon, 10 Jan 2022 17:02:25 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53008) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n72j8-0001b6-3a for emacs-devel@gnu.org; Mon, 10 Jan 2022 17:01:18 -0500 Original-Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:14248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n72j5-0004Ov-1J for emacs-devel@gnu.org; Mon, 10 Jan 2022 17:01:17 -0500 Original-Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 20AJleTS026231; Mon, 10 Jan 2022 22:01:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2021-07-09; bh=EmcKuLNyPSC88ZoiKquDPp81TFBO2vnBSprXH1jUP+c=; b=H10y4QJsFqWmHkcPNWPO92T9WBs/Y+V4qPxGSieoxqc13iGTH4Kkrv9Feson01pxEtlk ptCB2AHuUfC2gib48fbFtygBf6Id24015vQAvEVltOpWouGB9ErJYYf+8C8y9dFB+Gn9 gxLBI6ZB33lHvO+HBd1nKWCe67H9zhmYpfxNHKf5FWSYV3oN9ryYjegg7KbOseVJDOck dVUWMFgZ6lUrIgX8C1PQKdMBs4LnA+LBmqsjAfCAkwks+tuouuD5epPQKhJgGw/a3ugj 1CWFtRASG6Nyo1J1JcQPghwnud1O3jD3awgUHof+KaKI/FXU6DFjkCw2EkyTcLFjnS63 ug== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by mx0b-00069f02.pphosted.com with ESMTP id 3dgjtg9skj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Jan 2022 22:01:12 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 20ALtZ3Y062920; Mon, 10 Jan 2022 22:01:11 GMT Original-Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2171.outbound.protection.outlook.com [104.47.57.171]) by userp3020.oracle.com with ESMTP id 3df42kn8ya-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 10 Jan 2022 22:01:11 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ihg+4uIh9CAFXbNnRqEvxOnN9NVgOUGok1ygGWfDZVlkZJvdBjNZxDY4R8dv0BIWUfU8LTyq/2QEEq6siCLCIFoC6AlkXFhwRv/3PKYB8AVbx1JOV2rpmlG4PhdPu8kMeOil/BcAbaov2Ji21tTnESq9H9r2GaPV1zaAVuGrEOzpLXjc/bLVUN3vCokAIhs8RSH6INrP72PlWCoPwX/Uzt/Xjp73TXvr6G4PB3lU1USYSC+ErTV8+SXbnXWN50iV9JwxEkDI/6V6nrg1Ma5KU38PdaYkTTbnt6ausYGr0CB2MpskboWmhx14st2jTXh8iV68boJOp6CggaVyRWP7AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=EmcKuLNyPSC88ZoiKquDPp81TFBO2vnBSprXH1jUP+c=; b=YTDydJ4sumE/FgG4yjO2/6dMR/YRfc0aTSmmePcHAd5/6xtIryQS/KsaNyfMEtf4dXTD6k+vhmwtqqwOb8z/7UjsWBQlW7Vb2Ygt8VYlQfzOtexDQq0TUCw+uyiCVHwKiay3nSPZibKIfCyAjzLis0lTr7IUAENs1LmALXQToTsOG/lNCNCbCVkt7CgA8343Fm3yYRiAg3HBTvqV9z0+UJ1wbLK5lJCZ2AApahNgrr/FNiBx1nlqy1l1bXk7qf2mzfPW640siOaGVzYLNikW+TuLLPN6pa9Ygitdf0Q+ms6yJ4mOjFTlR5ZJKOLCIZoX2a2eYcNaDO+z3WGNLKkyuQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EmcKuLNyPSC88ZoiKquDPp81TFBO2vnBSprXH1jUP+c=; b=fY3Z7eT4VTSQL54KigjEOINKaxC0OL2bKUxTuRlMV8PEvcYK10S5hP0CKDZektPKIFmlgpoepKMl9z6IKgnj9w5O2frntBr6Rd8KvP16wiqjhqLXacb9nTlHRx6F31hxb0wBLlcvn1OBgDVmS5PPW6KzrqvbWYK5lhEazFoHBNU= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BYAPR10MB2711.namprd10.prod.outlook.com (2603:10b6:a02:ba::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4867.9; Mon, 10 Jan 2022 22:01:09 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3%7]) with mapi id 15.20.4867.012; Mon, 10 Jan 2022 22:01:09 +0000 Thread-Topic: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA Thread-Index: AQHYBCa+yRg93iqmYUuTMoi36bkxtaxcwc+Q In-Reply-To: <871r1jm4hf.fsf@gmail.com> Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f61b8d6-e45f-4eba-0328-08d9d484b53c x-ms-traffictypediagnostic: BYAPR10MB2711:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rh511WiF9a1dMfJdRyIMUcT+BuqKybTt/dZj7m835F0c/IQOIgSJ/1tTZMWw23FNga4YrnIcpiwkAFuvYssvP8uV2Rw1Qo+4LAiExrVh1Lv+b/25ldbiNtC1gDFw1CmB+vyYHwF2Ht/7bPrKNfwe5aLkh9WQG9O2Dhit0JcJd1gBR/INiFy4Irgj1KynlWl6GtN1dydhPZ0LjYw0hfP0MzaAy/bD9eTjJkcvyNDumaTrSDYhlIeRDr5VARLE7u6Y9HaEoLsmdGPAgFHyStSJuHbkdXY2NcHLhYmhZ1PIp2LelAX9kApM/Yj3qMxSjRfM1NLqVX2mimBfAPLrwxmQtHGj9zmGX+BrmU+dsllpqjxLKSdEOeGFSIXpEovGvPEhVPToyODBBrIOpGIu1RsqB2JT8V12sPWO6huqJnssZ7C6xGbsjVnSJzqPX5KPGIzNXWDgr8YyKX6NXp7fdwUN7Aw7Ah8gA6xH8zOcYC5XPnhRJSZ5xYkUjPZhoDH2uc3i94k3p4XClwBOZnP2oEaiTdTk7Gd52AnJdvde20R2M4N7ICwUVG5Tw6fyOSvsI4BsuoPTKVqfoMEa6aMbc8l7hPzuRWQYSICv++p74IeckIghl6RHUW+A7nKeeZQn/kgJbivHSXr23XDb20ZRhv3wY5rIvDahYu5oqTtFbu5rvSGQlIjflPxong9fQty5ZD8QLzPU7M98uKdFY1zcAY7uQQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66556008)(6916009)(66446008)(66476007)(122000001)(64756008)(52536014)(66946007)(55016003)(86362001)(44832011)(4326008)(8936002)(76116006)(8676002)(5660300002)(83380400001)(38070700005)(2906002)(38100700002)(9686003)(33656002)(186003)(316002)(30864003)(71200400001)(6506007)(7696005)(508600001)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?0DJYecGNa6gQRVgMIwP4tv9kb95ngact6TBlaEDv7SBETkEkmdTpvZKeZpZH?= =?us-ascii?Q?QZvg/MJXnwa8/3KEaWSd6SgW1iXuT1lKxHU7s+mtcdZRsiQNvRHsT0rgeLtp?= =?us-ascii?Q?Atfo9DQp/kGq4lokZvDewIntsYin7rY8fER2rXri89r8mWCu4KLAv9Jw9Zxw?= =?us-ascii?Q?S/4Kkoiy29pGGrcm6cZ/TkJEl1+jFxpC5lPZ/2m/B1ab0Ubg5fJa/maVoD+H?= =?us-ascii?Q?cA3kuvXOegZQf+guUcfokv6SuunpcVkMA5JoYPzJhuaQYgth/PH2C/p/o3xe?= =?us-ascii?Q?aMaE/p5YTOYhZdBu3l18B3sPxCbvO+DazrSWijW1quTTN/T+F+HRyn81fqv0?= =?us-ascii?Q?5D5ZpZqH4ofirOHBhmMfwKgKjWsIOEvuoNTereeSpaaXbcdJsZ5kAN3QUqUa?= =?us-ascii?Q?4Du2UpOO9e62zmOLj866wEvuuc/tR0Sltb7ZNaPeSX3Vxmf65lk5exrPNRWn?= =?us-ascii?Q?KjujhKCMmjYAUfgFX6PXpgAdORAblL0vdzJYxxPSg9yHcSGjghcvImjedwsh?= =?us-ascii?Q?P5l4NpDtKmZN0dV8+Wbff3x3HvcgSE6KagBMRqeQb2bIgpl9AqKz0vWKnd6S?= =?us-ascii?Q?2hnnffgwc6/P30sV59FSFLPPkUoFtpWHGNQwng2ZXpG0R9q+0czS+7NPJo7e?= =?us-ascii?Q?uL X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f61b8d6-e45f-4eba-0328-08d9d484b53c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2022 22:01:08.6173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wsK2oz4BlKzeHM3h3vt0f7w00zWVB7I382zWLva8ZhX5tQ44pFuo71YbpDRrYL0ve6QULtFyXbYMprUupYPecQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2711 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10223 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 phishscore=0 mlxlogscore=999 spamscore=0 bulkscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2201100144 X-Proofpoint-GUID: NWS2JHEUjifXxgu443cqKYVbABLzjoOe X-Proofpoint-ORIG-GUID: NWS2JHEUjifXxgu443cqKYVbABLzjoOe Received-SPF: pass client-ip=205.220.177.32; envelope-from=drew.adams@oracle.com; helo=mx0b-00069f02.pphosted.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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:284554 Archived-At: [Quoting most of this so it can be referred to in my reply. Readers can skip over the long first quoted part, and come back to parts of it, if needed, when they're referred to. To do that, skip to "------------".] > > Automatically loading `custom-file', if it isn't > > loaded by the init file (and any code that file > > loads etc.), is not a hard requirement. > > > > It's something that could easily be done, but it's > > not _required_ to advance the aim of getting more > > users aware of and using `custom-file'. > > > >> This means either the timing of loading that file would then > >> be up to Emacs or we would have to add some other switch to disable > >> automatic loading to restore user control over loading that file. > > > > Yes. But I think that can be as simple as what > > I suggested: > > > > 1. Automatically load `custom-file' (provided it's > > not the same as the init file) immediately after > > the init file is loaded. > > > > (We already automatically load other files if > > they exist - site-lisp.el etc.) > > > > 2. Provide users with a way to inhibit automatic > > loading if they need/want to do that. > > > > (Those users who want to do everything in their > > init file are not involved in this - they'd > > just set `custom-file' to their init file.) > > > >> So already the 'simple' change proposal has added=20 > >> additional complexity (albeit small). > > > > As I say, automatic loading isn't a requirement. > > It's a feature. And with #2 it's optional. > > > > (One way to realize #2 would be with a user > > option. We could discuss its default value.) > > > >> There could be other corner cases I've not thought of as > >> well, especially once we add a new 'toggle' for the loading behaviour. > > > > If we're really worried about that, then we > > just don't provide any such automatic loading. > > > > I don't expect problems, but automatic loading > > isn't a requirement. Nothing in the general > > aim and proposed solutions requires it. > > > > Without it, users would just be responsible for > > loading `custom-file' - like now. Not a big > > deal, but I think it might help users to provide > > it (new users especially). > > > >> The change management aspects I referred to are perhaps a little subtl= e > >> and are certainly hard to quantify. However, it is often way too easy = to > >> underestimate the impact of such change and identify what needs to be > >> done to mitigate it. This impact can be especially hard to recognise > >> when you are invested in the change. > > > > I don't disagree with that general point. > > > > I don't foresee any complications, but I'm > > _not_ really invested in Emacs providing the > > ability to automatically load `custom-file'. > > > >> Things which need to be considered > >> (some of which have been mentioned) include > >> > >> - dealing with impact on existing users > >> - updating documentation, including manuals, howtos, faqs etc > >> - managing the confusion that will arise due to the amount of existing > >> and easily found information out there (stack overflow, reddit, wikk= i, > >> blogs, books etc) which will be out of date and will likely cause mo= re > >> confusion. > > > > Sure. > > > >> Just dealing with the first one will likely result in the final soluti= on > >> being more complex than simply setting a default custom file value, > >> which in turn will make the other points more substantial to deal with= . > > > > I don't think so, but I can't prove you're wrong. > > > > Suppose we don't offer automatic loading. > > If you don't load `custom-file' (from your > > init file or in some other way) then it doesn't > > get loaded. End of story. > > > > Or suppose we offer it, but by way of a user > > option that by default is off (no autoload). > > > > IOW, no change from what we do now, in this > > respect (no autoloading of `custom-file'). > > > > In that case, the change is just to default > > `custom-file' to a standard location, not to > > nil. Now reread your paragraph of things that > > need to be considered. Not a big deal in this > > case, right? > > > > I wouldn't be completely happy with that > > solution, but it would still be an improvement. > > > > As I said, it would even be a (small) > > improvement if Emacs would just come out and > > recommend to users to use `custom-file', > > instead of just warning them, in the init-file > > template-comment, not to edit the inserted > > generated code. > > > > I'd hope that we go further than that, but > > even that would help. > > > >> The above are some of the reasons I think it may be misleading to > >> characterise the proposal as something simple. > > > > "The proposal" is really a set/hierarchy of > > proposals, from trivially simple, with little > > effect (and I hope little controversy), to > > something that includes possibly automatically > > loading `custom-file'. > > > > I hope you'll agree that the mere change to > > defaulting `custom-file' to a file name isn't > > complicated in its implications, and it should > > not be controversial. > > > > All of what would happen in that case already > > happens, if a user sets `custom-file' to a > > file name. If no one loads that file, or if > > that file remains nonexistent or empty, we're > > in no-op land. > > > > Even users who only want to use their init > > file for customizations wouldn't be impacted. > > No-op. > > > >> However, I would be in support if I thought > >> this was an actual problem needing to be addressed. > > > > Maybe think of it as what we have now: offering > > `custom-file', but just making use of it a bit > > more visible and likely. Instead of thinking > > "problem" and "solution", maybe just think that > > it might help more users to take advantage of > > `custom-file'. > > > >> TO me, it really does feel more like a solution in search of a problem > >> or at the very least, a change which will result in non-trivial effort > >> (at various levels) when there is little evidence it is really require= d. > > > > I understand that you feel that. I think your > > fears are unnecessary. Take out the "automatic > > loading" feature from your consideration, and > > see how fearful you still are. ------------ > we seem to be mis-communicating here or I'm just not being clear enough. > One last attempt and then I'll leave it alone. >=20 > My understanding of your suggestion is to set custom-file to some > default location rather than nil e.g. .emacs.d/custom.el. You suggest > that is all which is required and that no automatic loading would need > to be added. For some definition of "required". See the rest of what I wrote (which you quote above). I certainly favor automatic loading, with an option to prevent it (#1 and #2 above). > I reject this as automatic loading would be absolutely > necessary to retain existing behaviour. Depends on what is meant by "absolutely necessary". As I said: Without it, users would just be responsible for loading `custom-file' - like now. Not a big deal, but I think it might help users to provide it (new users especially). By "absolutely necessary" you appear to mean without any users having to make any changes. So yes, if _no user will make any changes_ then something like automatic loading would be necessary. Otherwise, saved customizations wouldn't get loaded. (Is it necessary that they get loaded? Certainly desirable/expected.) > If all we do is set custom-file to a default location, custom will stop > working between sessions because nothing will load those settings. This > significantly changes behaviour. Indeed. Hence the proposal to automatically load `custom-file', if it hasn't been loaded and it's not empty. > To keep the same behaviour, either all > users who now just use custom with custom-file set to nil would need to > add a load statement OR emacs will have to automatically load that file. Or they would need to start using `custom-file' (which should be encouraged, without obligation to do so). Yes, that's it. (Except that we could perhaps let an _explicit_ setting of `custom-file' to nil act like setting it to the init file.) > Requiring users add a load statement to their initialisation file to > ensure custom settings work across sessions is a bad design and would > impact too many existing users. There would be no such requirement. You prefaced your (incomplete) statement with "To keep the same behaviour". Clearly, if we change default behavior then we're not keeping the same behavior by default. We would be _allowing_ the same behavior to be realized. And with very minimal effort. And no, users who really want to keep the same=20 behavior would not need to add a load statement anywhere. It's enough to set `custom-file' to the init file (or perhaps even to nil). > If we change the default setting of custom-file from nil to a > default file location, there will need to be code added to Emacs to load > that file at some point in the initialisation step. Yes. (But load it only if it hasn't been loaded.) > If we then also want > to retain the user's ability to control when this file is loaded, we > will also require a toggle to turn off that loading and allow the user > to do it. 1. See previous - it would be loaded only if not loaded during the load of the init file. 2. Users can load it anytime during the init file load. They can even load it multiple times. 3. Users can prevent loading it automatically (I suggested a user option or this, as well as perhaps a command-line switch.)=20 > Claiming that all you are proposing is a change to the default value for > custom-file is inaccurate if you also want to claim no change in > behaviour. 1. That's _not_ all I proposed. That's all that's strictly necessary. But in that case, users have a bit more responsibility. 2. I never claimed that there would be no change in behavior. Obviously, if we change the default behavior we change the behavior. What I claimed is that (a) in many cases there will be no change in behavior and (b) in any case users can easily get whatever behavior they like, including the behavior that's the default now. To restore the behavior to what is now the default, a user would set `custom-file' to the init file.