From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Settings Date: Thu, 15 Aug 2019 14:52:23 -0700 Message-ID: <87y2zuumeg.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="108983"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 15 23:52:41 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hyNfl-000SFZ-FP for ged-emacs-devel@m.gmane.org; Thu, 15 Aug 2019 23:52:41 +0200 Original-Received: from localhost ([::1]:47500 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyNfk-0007GK-2k for ged-emacs-devel@m.gmane.org; Thu, 15 Aug 2019 17:52:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34157) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1hyNfb-0007C9-Pk for emacs-devel@gnu.org; Thu, 15 Aug 2019 17:52:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hyNfa-0005Ni-ET for emacs-devel@gnu.org; Thu, 15 Aug 2019 17:52:31 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:42368) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hyNfa-0005N9-8A for emacs-devel@gnu.org; Thu, 15 Aug 2019 17:52:30 -0400 Original-Received: from [50.225.213.182] (helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hyNfV-0007OV-Ht for emacs-devel@gnu.org; Thu, 15 Aug 2019 23:52:28 +0200 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239386 Archived-At: Reading some bug reports about problems with saving Customize settings (for instance, running two Emacs instances and customising different variables and saving them will overwrite each other; they're not written to the .emacs file atomically so an error will make the .emacs file invalid) reminded me of something that was discussed in the NSM context years ago, but never acted upon, which is: Emacs should have one way to save settings. Currently, there way settings are saved are in three classes: 1) Older stuff: (put 'narrow-to-region 'disabled nil) saved to ~/.emacs (or whatever the init file is called). 2) Post-Customize stuff saved to ~/.emacs: (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(load-home-init-file t t) ...) 3) Ad-hoc methods for saving key/values in different files (~/url/cookies, ~/.emacs.d/network-security.data) I think Emacs can do better. As a first principle, I think Emacs should not mess, at all, with the ~/.emacs file. That's for users to put their lovingly hand-crafted setqs in. Second of all, Emacs should allow listing, with one command, all settings that Emacs has saved on your behalf, and that allows you to remove anything you don't want to have saved. And finally, Emacs should save some metadata about the setting, like when it was done and from what Emacs version it was done. This is where somebody will say "let's use sqlite3!", and sure, a real database would be nice. If someone were to come up with a fast, query-based solution, that'd be great. We could also just use an append-mostly data-base-log like approach, which would go something like this: There's a file ~/.emacs.d/settings, and whenever we want to register a command as not disabled, or save a Customize setting, or store an NSM exception, we just append a form to that file. It could be, like, [:type variable :variable load-home-init-file :value t :time "2019-08-15T14:43:37" :version "27.1"] [:type plist :symbol narrow-to-region :property disabled :value nil :time "2019-08-15T14:43:37" :version "27.1"] [:type key/value :realm "NSM" :key "sha1:5b77fdefcb11074b38d23d182a7fb414b0d8be24" :value "sha1:a7:e2:85:c8:59:2a:e9:06:98:ad:86:ee:ff:ea:39:34:04:6f:e0:c6" :time "2019-08-15T14:43:37" :version "27.1"] and when Emacs starts up, then it reads the file and the final value wins. (We'd have a compacting function to get rid of redundant entries.) Of course the syntax should be a whole lot less verbose -- the file doesn't have to be very human-readable. There's a compat issue, though -- if you start, say, Emacs 28, and it converts your old-timey settings into new-style settings, then if you shift back to Emacs 27, you may not have settings any more. But the converter could leave the forms in place in .emacs and add helpful comments about them not actually being used any more in Emacs 28, so I don't think that's an insurmountable problem. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no