From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Reconsider make-backup-files default value Date: Mon, 16 Sep 2024 15:02:01 +0300 Message-ID: <86o74ndcxy.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15214"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: James Ipswich Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 16 14:03:24 2024 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 1sqARw-0003iJ-FJ for ged-emacs-devel@m.gmane-mx.org; Mon, 16 Sep 2024 14:03:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sqAR5-0002rA-1m; Mon, 16 Sep 2024 08:02:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqAQg-0002i9-Am for emacs-devel@gnu.org; Mon, 16 Sep 2024 08:02:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sqAQf-00079l-T8; Mon, 16 Sep 2024 08:02:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=C/Z1AVqp456TB8LoA5ZXo1+CuVR67K7d4vRpamV0D5U=; b=h+x1i06GspSR 3INWu2ielOXiVGmr+admUNA3ncSyNwTUKqm6lqQTDCul9Ha8I3+2xBc6Jsc+4H13LDIwL4HE47Kpa aXFYH+IIplVop0ueqzWOFlf++r/PKfSRXPKPI46gfcVy89IYqqWGryM28eG8oZ7dYqmUKdNH25AZN U2PMPPkBKd5mibxeroZWRg0OxC5WrJ1q98EYegqS9F6GlEOlVhSrLYNnP89E3GB/aJjgRhIEYGINS YMNvp9InvF91uDZimy8Wwahz4Y5XktemrTP0iBht0VgZStqsRLiEoAVZ7/MM9dxrhM6uicqf7zgLs HwClE1Sx/AF/eAaB/Bw3nQ==; In-Reply-To: (message from James Ipswich on Sun, 15 Sep 2024 22:19:42 +0000) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:323661 Archived-At: > Date: Sun, 15 Sep 2024 22:19:42 +0000 > From: James Ipswich > > Emacs has traditionally kept all defaults very minimal, and most > functionality needs to be explicitly enabled by the user. For example, > out of the box minibuffer and CAPF completion is quite plain. That's not accurate, but I don't think it's worth our while to side-track into a semi-philosophical argument about this. Let's focus on the actual issue at hand instead. > However, make-backup-files default value is t, which I think goes > against this philosophy. If I open stock Emacs, with no configuration, > it pollutes all directories with backup files whenever I edit something. > This is a bit intrusive as I have never enabled such a functionality. > > I understand this default is old, and comes from a time when machines > were less reliable and version control systems were not widely used. I > also understand some current users enjoy this functionality as an extra > safety net. > > Personally, I think make-backup-files should default to nil or some > other less intrusive configuration, which would be better aligned with > the rest of Emacs defaults and how other software behaves. > > Any thoughts? I would hesitate to change such long-time defaults. I'm guessing many people have good use of these backup files (I do) and expect to have them (I do); changing the default means they all will need to customize Emacs, and that's _after_ they find out the behavior changed and curse us, silently or otherwise. If someone dislikes these backup files and doesn't need them, customizing that away is so easy that I wonder why we need to argue about changing these long-time defaults. It almost never makes a good use of everyone's time. Arguing for changes in defaults of user options is only useful when the existing default makes absolutely no sense in any reasonable use case.