From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Emacs default bindings Date: Sun, 05 Sep 2021 23:05:05 -0400 Message-ID: References: <87h7fcnmq0.fsf@posteo.net> <83tujbqg4j.fsf@gnu.org> <46353190-1190-495f-b15e-22980159b3ab@yandex.ru> <83y28mp0rb.fsf@gnu.org> <51a363db-fde7-791d-cf8d-98ac601d62ee@yandex.ru> <57ca4d78-2339-201d-edce-678c9b003a99@yandex.ru> <01341bd6-b94b-4f94-1461-405e723142ad@yandex.ru> <8735qmjklm.fsf@localhost> <87ilzi86h7.fsf@posteo.net> <875yvh9anq.fsf@posteo.net> <83o899yjh2.fsf@gnu.org> <83k0jxyhbn.fsf@gnu.org> <05217332-4d76-83a6-06a6-3ddae942dd12@yandex.ru> <83czppygiv.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11348"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, danflscr@gmail.com, lokedhs@gmail.com, yantar92@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, eliz@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 06 05:09:15 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 1mN50V-0002lR-CG for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Sep 2021 05:09:15 +0200 Original-Received: from localhost ([::1]:52810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mN50U-0006rF-5p for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Sep 2021 23:09:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mN4wU-0000Eo-Oa for emacs-devel@gnu.org; Sun, 05 Sep 2021 23:05:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:51882) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mN4wT-0003ZK-I1; Sun, 05 Sep 2021 23:05:05 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1mN4wT-00028P-Bt; Sun, 05 Sep 2021 23:05:05 -0400 In-Reply-To: (message from Dmitry Gutov on Fri, 3 Sep 2021 16:26:41 +0300) 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:274053 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > And to avoid the problems with Emacs's default moving forward, we > introduce a profile called "Good Old Days" which the folks who prefer > things to generally stay the same, would enable, just once. Going > forward, every time we change some default, we would consider adding the > previous value to that profile. Or even do that automatically. If each profile can cover many unrelated changes, I think that we can't expect it to work, in general, to enable two different profiles simultaneously. In general, they will conflict. Therefore, I think we should instead define ways to enable specific interface options which are independent. However, for the special case of selecting the defaults of a previous Emacs version, the issue of conflicts will not arise, because they are mutually exclusive. So the idea of broad profiles could make sense, for this. The command to select the Emacs 20 defaults can start by calling the command to select the Emacs 21 defaults, then make the changes to go from Emacs 21 to Emacs 20. We could release Emacs 28 with a no-op command to select the Emacs 28 defaults. In Emacs 29, that command would cease to be a no-op. It can't be just that, because we will also want commands to switch to more recent defaults. But they do not need to be written in detail. The commands to switch to an older default could build up a sort of settings undo list, recording changes they make, and switching to a more recent default could work by undoing entries off that list. Specifying a particular version of defaults could look at the current version setting to decide whether to go forward or backward. Would someone like to give this a try? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)