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: [PATCH] When deleting in bookmark menu, prompt for confirmation. Date: Mon, 03 May 2021 21:44:55 +0300 Message-ID: <83sg3364ig.fsf@gnu.org> References: <87a6pcqy7s.fsf@red-bean.com> <83czu86o46.fsf@gnu.org> <835z006jpl.fsf@gnu.org> <87im3z3f8f.fsf@red-bean.com> <83zgxb67g2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5994"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jim Porter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 03 20:54:55 2021 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 1lddiX-0001Rt-Bb for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 20:54:53 +0200 Original-Received: from localhost ([::1]:43466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lddiW-000254-GA for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 14:54:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40906) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lddZC-00029I-5o for emacs-devel@gnu.org; Mon, 03 May 2021 14:45:14 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60090) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lddZB-0004cc-UG; Mon, 03 May 2021 14:45:13 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1905 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lddZA-0008EU-V5; Mon, 03 May 2021 14:45:13 -0400 In-Reply-To: (message from Jim Porter on Mon, 3 May 2021 11:28:12 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:268834 Archived-At: > From: Jim Porter > Date: Mon, 3 May 2021 11:28:12 -0700 > > Just a random musing: would there be any sense in adding a global option > like `prefer-conservative-defaults' to Emacs 28 and mentioning it in the > NEWS so that, come Emacs 29, developers could make modestly > backwards-incompatible changes like this while keeping the old behavior > for people with `prefer-conservative-defaults' set to t (which they > hopefully set upon the release of Emacs 28)? That requires that those users know about that option and turn it on the moment they install the new Emacs. I'm not sure I understand why we should assume such an option will be known. > One downside I see right off the bat is that > `prefer-conservative-defaults' == t would roughly mean "keep Emacs like > it was in version 28", but a decade from now, someone might prefer Emacs > 38 and want conservative defaults starting then. I suppose > `prefer-conservative-defaults' could specify a preferred version, and > `defcustom' could allow for multiple default values defined by > particular version ranges. You make it sound as if defaults never change in Emacs. That is definitely not true: we do change them, after we receive feedback from users who opt in to the new behavior. Also, a behavior can be incompatible only where existing features are considered. New features cannot by definition behave incompatibly, because there's nothing to compare them to. So compatible behavior does not mean that Emacs 38 will be the same as Emacs 28: it will have many new features and packages that 28 never had. > Either of these solutions would increase the maintenance burden somewhat > for those variables (the second especially), but no one is *required* to > make backwards-incompatible changes, so I'd hope this is only done when > a developer truly believes that the new behavior is better, and is > worried that existing users won't want to change. I don't think I agree with that assessment. Incompatible behaviors are also introduced because each one of us has personal preferences. So "truly believes" is many times in the eyes of the beholder.